[經驗] 職涯、英語，寫，美式履歷表，語氣
之前在 studyabroad 板有試著把我寫的關於求職的文章整理出來 [1] ，但那些
舊文都是在「討論」，所以比較零碎、發散。是故，開始試著有系統地整理一些觀
念，集合成單篇的文章。
有任何意見、建議、問題，請不吝指教，謝謝 :)
* 網頁版
http://www.30abysses.com/TWY/2017/01/26/resume-tone.html
* GitHub Issue 版
https://github.com/teach-and-learn/write-resume/issues/2
[1]: https://www.ptt.cc/bbs/studyabroad/M.1478510359.A.EFF.html
#1O84SNx_ (studyabroad)
========================================================================
# 職涯、英語，寫，美式履歷表，語氣
有作過功課的人大概都知道「[美式履歷表][1]」 與臺、日常見的履歷表（格）
不一樣。美式履歷表從一張白紙開始，雖然有由經驗歸納出的常見樣版，但並沒有
嚴格統一規格，多半由求職者自由發揮。
[1]: https://en.wikipedia.org/wiki/R%C3%A9sum%C3%A9
關於「美式履歷表寫作」，網路上有許多英語資料，但中文（公開）資料仍偏少，
且多半只限於講解美式履歷表的基本格式，少有對寫作風格多作著墨（尤其是寫作
語氣的案例解析），是故，在此整理我這幾年來發佈的文章，以作參考。這篇從最
重要的「語氣」談起。
**聲明：我的經驗來自於我對北美軟體科技業的認識，不見得適用於所有行業。**
# 所謂「語氣」為何？
履歷表是求職申請的敲門磚，最常見的錯誤語氣，就是把它當作
「[起居注][2] 、流水帳」來寫，也就是錯誤地把焦點放在：
> 在某時某地，我以某方法作了某事，句點。
[2]: https://zh.wikipedia.org/zh-tw/%E8%B5%B7%E5%B1%85%E6%B3%A8
這種寫作語氣的錯誤在於：這就像是把 iPhone 秤斤論兩，照著金屬原料、物料的
單位價格來賣，而無視 iPhone 的整體價值。
易言之，比較以下兩句話：
1. 我以Ｎ牛頓的力量施加於該質量Ｍ的小孩產生Ａ的加速度讓他在Ｔ時間作出
Ｓ距離的位移。
2. 我奮不顧身將該小孩從失控的卡車前拉開，使他免成車下亡魂。
`(1)` 與 `(2)` 說的是同一件事；雖然 `(1)` 在技術上完全正確，但 `(2)`
才能突顯「救了一條人命的價值」。
這就是所謂的「語氣」；並不只是從網路上的 "action verb" 清單裡挑動詞
填填看，而是要從讀者的角度去想，如何堅守誠信但又清楚展示你的價值。
# 三段連續技：成果 → 實例 → 細節
所謂三段連續技，即是成果(result)、實例(example)、細節(specifics)。先從一
實際案例來看（以下所有案例皆有略為修改，以保護當事人隱私）：
> Created Bash scripts and custom Eclipse plugins in Java for automatic
> code generation
>
> 建立 Bash 腳本、以 Java 客製化 Eclipse 插件來自動產生源碼。
這給出了實例與細節，但後繼無力；是故，稍作修改訂正，變成：
> Automated _X%_ _component_ code generation with Bash scripts and
> custom Eclipse plugins (Java).
>
> 以 Bash 腳本、 Java 客製 Eclipse 插件，將 _某元件_ _X%_ 的源碼生成
> 自動化。
這就是由「成果」起手（ "X%" ）、說明實例（ "automated code generation"
），點出價值（由自動化節省人工，而人工就是成本），最後補充細節（
"Bash scripts", "Eclipse plugins (Java)" ）。
除了點出你創造的價值，也為接下來的對話佈局，不管是由讀者發問，或是自己
導入以下這類這些話題都可以，例如
* 這個 _X%_ 是怎麼算出來的？這種算法有多精確？
* 為什麼 _component_ 需要 automated code generation ？
* 若能重來，會如何改進這個作法？
易言之，先以連續技作出有效打擊，再掌握節奏，進可攻，退可守，會比原本的
被動語氣（只丟實例與細節，等待讀者來猜測、推敲你做的事的價值）來得有利（
因為你的讀者很少會願意花那時間來解讀你的「言外之意」、也多半沒那個心力來
為你探索你自己都說不明白的成果價值）。
---
另一個案例
> Implemented automation E2E tests with xUnit and Moq from scratch;
> integrated with CI to send test report.
>
> 從頭以 xUnit 及 Moq 實作自動 E2E 測試，並與 CI 整合、送出測試報告。
與該履歷表作者溝通之後，了解到該團隊之前完全沒有自動測試，是故這東西作
出來後，是從頂頭上司到 CTO 都點讚的大功，是故，重點在那句
"from scratch" ；訂正之後拆成三句：
> Reduced average testing efforts per build from _X_ man minutes to _Y_
> machine minutes.
>
> 100% automated CI E2E tests plus test result reporting, analysis,
> visualization.
>
> Designed and implemented full CI E2E test suite from scratch with
> xUnit and Moq.
>
> 將平均測試成本從 _X_ 分鐘（手動）降至 _Y_ 分鐘（自動）。
>
> 100% 完全自動化 CI E2E 測試，且自動化匯報測試結果、分析、並以視覺化
> 圖表呈現。
>
> 從零開始設計整個 CI E2E 測試庫；以 xUnit, Moq 實作。
同樣一件事，換個說法就鏗鏘有力擲地有聲；可惜該履歷表作者手上沒有
code coverage, branch coverage 等資料，不然這一段的打擊火力可以更強大。
# 「成果」的重要性
「成果」是整個連續技的開始，以格鬥遊戲來比喻的話，這三段連續技就是：
> 浮空 → 連擊 → 追打
（概念影片支援： [https://youtu.be/qcnrq7G6nag?t=36s][3]
對應到成果、實例、細節就是：
> 成果（浮空） → 實例（連擊） → 細節（追打）
「成果」代表你創造出來的價值，同時展現你作事的態度（你如何量化你的成果？
如何導入最基本的 [Build-Measure-Learn][4] ？）；「成果」不一定要是什麼
豐功偉業，只要把你的職務作到 *卓越* ，就一定有拿得上檯面的「成果」。有了
成果，就能抓住履歷表讀者／雇主的注意力，掌握節奏，主控（面試）場面。
[4]: https://en.wikipedia.org/wiki/Lean_startup#Build.E2.80.93Measure.E2.80.93Learn
# 結論
如果是沒有特定目的而寫的履歷表（例如，就放一份在自己網站上，給獵頭人參考
用的），那稍微偏向流水帳的語氣是無妨（工作經歷、學歷、證照、技能）。如果
是為了特定職位而寫的，就要以 sales pitch 的心態去寫，也就是這整篇文章
一直強調的「成果、價值」。
「實例、細節」與左手一樣，只是輔助；如果一味糾結於「實例、細節」而忘了
「成果、價值」，那就像是把 iPhone 如廢五金秤斤論兩賣，本末倒置。
--
個人 雜談、學習、英語、軟體
https://www.facebook.com/tw.yang.30 https://www.facebook.com/30abysses/
https://twitter.com/twy30 http://www.30abysses.com/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 72.211.194.61
※ 文章網址: https://www.ptt.cc/bbs/Oversea_Job/M.1485568512.A.37B.html
※ AmosYang:轉錄至看板 Soft_Job 01/28 09:55
推
01/28 10:25, , 1F
01/28 10:25, 1F
→
01/28 10:25, , 2F
01/28 10:25, 2F
這很難用是否題的方式來回答 :) 我在上面原文中提出這個主張：
> 「成果」不一定要是什麼豐功偉業，只要把你的職務作到 *卓越* ，就一定有拿
> 得上檯面的「成果」
例如網路前陣子在刷的「因為自動飲料機而延畢的那一年」 [1] 系列文。
[1]: http://opass.logdown.com/posts/1273243-the-story-of-auto-beverage-machine-1
以「商轉」論成敗的話，最後是失敗的，但其中還是可以挖出很多成果與價值，尤
其是「解決問題」的過程；放杯、加冰、加水、加糖…都是從無到有，作出解決方
案。從這個角度切入去寫的話，仍可以顯出作者的毅力與研究能力。
有的時候，的確會發生當局者迷、旁觀者清的現象；有些事當事人會覺得不值一提
，但旁人聽了會聽出其中可用之處。
例如，今天下午才與一位網友討論他的履歷，他列出來一條，大意是
> 維護既有產品，修正臭蟲
與他聊了聊才發現，他所謂「維護既有產品」時，為了增設一個新功能，必須開發
框架裡本來沒有的功能，才讓這新功能得以運作。
那這就可以寫成
> 研發擴充商轉產品關鍵技術： _某技術_
原本聽起來無特別之處的「維護既有產品」，換個角度，還是可以挖出價值。易言
之，在遵守誠信的前提下，嘴炮不犯法，不炮白不炮 :D
結論: 在下「沒有那麼吸引人」的定論前，最好與人討論一下，看看能否從不同的
角度切入；在不違反誠信的原則下，突顯你的價值。
如果捫心自問有好好把事作好的話，通常很難會真的沒有東西可以挖出來寫 :)
推
01/28 11:22, , 3F
01/28 11:22, 3F
推
01/28 12:27, , 4F
01/28 12:27, 4F
→
01/28 12:27, , 5F
01/28 12:27, 5F
→
01/28 12:28, , 6F
01/28 12:28, 6F
※ 編輯: AmosYang (72.211.194.61), 01/28/2017 12:41:58
→
01/28 12:29, , 7F
01/28 12:29, 7F
→
01/28 12:29, , 8F
01/28 12:29, 8F
這也是無法以是非題來回答 :D
是我的話，我還是會放上去，但重點自然就不是「相關專業技能」，而是作事基本
態度。例如學生參加社團就是一個例子，社團不見得與專業技能直接相關，但若是
擔任幹部作出實績，也是可以寫。去擔任社區義工也是一個例子，例如，想出什麼
辦法讓義工隊伍作事流程改善，都是「作事能力」。
如上面的討論一樣，只要捫心自問有「把事作好」，那就應該一定有東西可以挖出
來寫（因為，要「把事作好」，不外乎就是認真負責仔細，懂得思考輕重緩急，有
執行力、統率領導能力；是故，一定有某個角度可以看到你的成果與價值）
反過來想，這也是檢視自己行事處世態度的機會，如果真的完全找不到好事來寫，
那就得想想是為什麼。 :)
※ 編輯: AmosYang (72.211.194.61), 01/28/2017 12:58:43
推
01/28 13:39, , 9F
01/28 13:39, 9F
若滿足以下條件
1. 北美軟體業（其他產業我不熟，不敢妄言）
2. 時間上能配合
3. 很明顯有作過功課
我多半會幫忙看；收費就 pay-it-forward 就好，以後看到有別人很明顯有作過功
課但差臨門一腳的，就去踹他一腳 XD 把這一腳傳下去 :D
反之，則無興趣；網路上另有許多收費承包這類潤筆業務的商家，可找他們 :)
※ 編輯: AmosYang (72.211.194.61), 01/28/2017 14:25:46
推
01/28 14:50, , 10F
01/28 14:50, 10F
→
01/28 14:50, , 11F
01/28 14:50, 11F
:)
如果覺得這是有幫助、經得起考證的正理，就幫忙散佈吧 :)
推
01/28 19:35, , 12F
01/28 19:35, 12F
→
01/28 19:36, , 13F
01/28 19:36, 13F
→
01/28 19:36, , 14F
01/28 19:36, 14F
→
01/28 19:37, , 15F
01/28 19:37, 15F
好問題 :)
其實履歷表寫作與一般寫作並沒有差很多，就是從大量的思緒粗料中萃取出意念的
精華。易言之，可從「自由寫作」開始，不管三七二十一就寫下任何你能想到關於
該 course project 的任何事，用寫的，用畫的，都無所謂，重點是搜集材料。例
如:
* 最後拿了幾分／哪裡被扣分／同學們平均表現如何
* 哪裡覺得不太確定，後來證實是錯的／對的／無關緊要的
* 哪裡花了特別多的時間／試了好幾次
* 遇到了什麼樣的難關／如何解開
* 與人合作時發生的事情／溝通上的問題／行事效率
......
有了這些材料後，可以幫助自己看到，有哪些方向、特點是對你來說特別有趣、值
得回憶，特別有成就感（就像多隆對韋大人的景仰，有如滔滔江水連綿不絕），再
試著從那些角度切入。
反過來說，如果該 course project 完全讓你「沒感覺」（例如，就只是作了交差
了事），那…神仙難救 XD （你自己都無法相信、投入的事，在不違背誠信原則的
前提下，要如何令別人相信／感受到你的熱情／作事能力／動力？ :D ）
Ref: wikipedia 上對「自由寫作」的說明
* https://zh.wikipedia.org/zh-tw/%E8%87%AA%E7%94%B1%E5%AF%AB%E4%BD%9C
* https://en.wikipedia.org/wiki/Free_writing
推
01/28 23:07, , 16F
01/28 23:07, 16F
:) 新年快樂 :D
※ 編輯: AmosYang (72.211.194.61), 01/29/2017 00:35:50
推
01/29 01:33, , 17F
01/29 01:33, 17F
→
01/29 01:34, , 18F
01/29 01:34, 18F
→
01/29 01:35, , 19F
01/29 01:35, 19F
→
01/29 01:35, , 20F
01/29 01:35, 20F
→
01/29 01:35, , 21F
01/29 01:35, 21F
是有聽過有人主張不要寫 summary, objective ，但我個人還是會寫，但寫的內容
會是求職信(cover letter)的兩行濃縮版，而不是履歷摘要。也就是用一、兩行話
解釋為什麼我是最適合這職缺的人（我的價值），而不是我的技能細節。
如上面原文裡主張的，美式履歷表比較像是一齣紙上的舞台劇，是有一些「基本規
距」，但給作者很大的發揮空間，最後看你覺得要如何突顯自己(self-promotion)
，你就照著你想要呈現出的戲劇效果去編劇，訴說你的故事。反過來說，臺、日的
履歷表「格」就像是食品成份表，講究標準化；視文化、產業不同，這兩種方法並
沒有絕對的好壞，就看想招來什麼樣的人材。
這也讓我想到很久一陣子前，在這版上的筆戰，我主張「只要不出格，在
ethical, professional, legal 的前提下，我不在乎求職者如何表現他自己；這
是他的舞台，我只是觀眾」，但另一方的意見則是主張「標準化、公平、量化」，
意指每個求職者都應在客觀條件相等的測試方法下被評量。這兩種方法也是沒有絕
對的好壞，就看自己喜歡哪種文化。
結論: 應該不至於說有寫沒寫 summary/objective 就是成敗關鍵，最後還是看你
想為自己如何編劇。但如果要寫的話，我建議以寫 cover letter 的心態去
寫，用一、兩行話點出你最大的價值。
又，求職用的 resume 與 cover letter 的目的本來就是 self-promotion :D 那
就完完全全 100.00% 是在「老王賣瓜」；在守誠信的前提下，「自誇」就完全是
這類文案要達成的目的 :) （不然何必花那麼多精神去寫 XD ）
推
01/29 04:24, , 22F
01/29 04:24, 22F
推
01/29 13:04, , 23F
01/29 13:04, 23F
※ 編輯: AmosYang (72.211.194.61), 01/29/2017 13:11:27
推
01/29 13:59, , 24F
01/29 13:59, 24F
推
01/29 16:12, , 25F
01/29 16:12, 25F
推
01/29 18:32, , 26F
01/29 18:32, 26F
推
01/31 01:42, , 27F
01/31 01:42, 27F
推
01/31 03:45, , 28F
01/31 03:45, 28F
→
01/31 03:46, , 29F
01/31 03:46, 29F
這取決於你打算如何寫這齣戲的劇本來訴說你的故事。易言之，如果你指的
「條列」是指像食品成分表一樣的條列，那我不會如此去條列。與之前討論過的
summary/objective 類似，我會這麼作：
1. 細讀該職缺的敘述。
2. 歸納出三至五項該職缺最重視的特點／技能／經驗。
3. 以兩行左右的文字，描述我如何符合 (2) 所指出的特點，並以粗體字標出。
4. 在 Experience 裡提到 (2) 所指出的特點時，也以粗體字標出。
（又，從另一方面來說，除了要標出最重要的重點，我個人會儘量避免使用粗體字
；把粗體字保留給最重要的七至十個重點，減少視覺噪音。）
例如，假設一個軟體業職缺一整頁的敘述讀下來，最後歸納為：
* 任務：協助團隊打造 _某系統功能Ｘ_
* 要三年專業經驗
* 要會 .NET/C#
* 要會 Git 版本控制
* 要熟悉敏捷開發
* 如果熟悉 ASP.NET/JavaScript/HTML/CSS 更好
再假設求職者是
* 作過 _某系統功能Ｙ_ ，與 _Ｘ_ 扯得上邊
* 有四年 .NET/C# 經驗
* 會 SVN
* 有待過跑敏捷開發的團隊
* 但對 ASP.NET/JavaScript/HTML/CSS 只有基礎知識，實戰經驗少
那我個人會把以下這樣一段話放在履歷表的開頭：
* 4-year .NET/C# mid-level developer seeking opportunity to contribute
lessons learned from _Y_ to project _X_; familiar with SVN version
control and Agile development; intermediate knowledge in ASP.NET.
上粗體字
* 4-year .NET/C# mid-level developer seeking opportunity to contribute
lessons learned from _Y_ to project _X_; familiar with SVN version
control and Agile development; intermediate knowledge in ASP.NET.
看，很簡單吧 XD （概念圖片支援：
https://upload.wikimedia.org/wikipedia/en/7/70/Bob_at_Easel.jpg
）
結論：基本上，如果讀者看完這段仍無興趣的話，那接下來寫什麼大概都沒有用了
；反之，如果這段能引起讀者的興趣，他接著仔細讀接下來的資料的機會應該會高
些。這也就是為什麼我主張「切忌一稿多投」；「多投」本身沒有問題，問題在
「一稿」。除非你個人品牌響亮，不然求職時最好還是針對每個職缺微調優化你的
履歷表與求職信。而這微調優化的過程，對接下來的面試準備也會有相當的助益。
※ 編輯: AmosYang (72.211.194.61), 01/31/2017 07:14:29
※ 編輯: AmosYang (72.211.194.61), 01/31/2017 07:31:15
※ 編輯: AmosYang (72.211.194.61), 01/31/2017 08:10:08
## 更正啟事
在上段中的假設例子，本意是想把求職者的經歷假設為「有四年 .NET/C# 經驗」
，但卻寫成了
> * 有四年經驗
> * 會 C#
經 [Jimin Hsieh][11] 指出，這會讓人誤解，
> Jimin.Hsieh
>
> 這樣說，四年經驗和會C#，並不等於，4-year .NET/C# mid-level developer，
> 實際上是，兩年C#和兩年C++，這樣說，一個人可能是Polyglot的，
> 這樣寫可以嗎？XD
是故，將原文修正為
> * 有四年 .NET/C# 經驗
感謝 Jimin Hsieh 的指正。
[11]: https://www.facebook.com/Jimin.Hsieh
※ 編輯: AmosYang (72.211.194.61), 01/31/2017 09:41:16