你的履歷只是招募者要掃過的眾多申請之一。如何從幾十份申請中脫穎而出?

如果你的履歷讀起來很「通用」,就很難吸引注意。想像一份 hiring manager 認真讀完後還是記不住任何具體內容的履歷;每段工作經驗描述都長得幾乎一樣——「用某某技術建了某某東西,做了某某重要的專案」。

本章說明如何透過具體描述讓履歷突出:用數字讓工作經驗閃閃發光、為職缺量身打造、以及不同類型公司關注的重點。

讓我們先從「如何更好地描述工作影響力」開始。

Results, Impact and Your Contribution#

列出工作或專案經驗時,聚焦在你達成了什麼,而非你做了什麼。盡量用影響力與**(商業)成果**來量化你的成就。

可以套用這個公式:

Accomplished {impact} as measured by {number} by doing {specific contribution}

這與 Google 建議的履歷結構 類似。不必逐字照抄,但要讓影響力清楚、貢獻明確、盡量具體。

編輯成就時的三個重點#

  • Use numbers(用數字)
    • 盡可能量化影響力。多數履歷沒有數字,加上就會突出。
    • 與其寫 「Built a tool widely adopted by the company」,不如寫 「Led a team of 3 developers to build a dependency injection framework that was adopted by 15 teams and all 50+ developers at the company」
    • 數字可以是:團隊人數、程式碼行數、coverage 前後百分比、SLA 變化、專案產生的營收、使用者數、安裝數、五星評價數、主動解決的客服工單數。
  • Use active language(使用主動語言)
    • ledmanageddroveimprovedrolled out 等主動動詞,而非 improvingrolling out 等被動形。
  • Mention specific languages and technologies(具體提到技術)
    • 敘述結尾提及使用的技術。
    • 影響力與貢獻更重要,但點出工具能加強說服力。
    • 確保這些技術與你在 Languages & Technologies 區塊列出的項目一致。

你不是靠列出「做了什麼」或「負責什麼」來脫穎而出,而是靠描述工作的影響力你如何貢獻。職位越資深越是如此,但即便資淺也一樣有效。好的履歷展現的是「主動創造價值」的人——只會照做的開發者一抓一把。

From the inside out:如何想出履歷的 bullet points?

Andy Lester(manager、lead、engineer、ack 的作者)在 Land the Tech Job You Love 中建議:

「寫 bullet 是整個履歷流程最困難的部分。我建議盡早開始——隨身帶張紙,隨手記下想法。不要擔心順序與措辭,把能想到的都寫下,之後再刪減比臨時多擠一條容易。聚焦在『故事』而非『流行詞』。」

「履歷書常強調 action words 的重要性,列一堆可用字:analyzed、compiled、coordinated、drafted、devised、implemented……沒錯,要用主動動詞,但不要糾結於用哪個華麗的字,專注於工作細節、寫得越具體越好。」

「細節包含數字。即使你不是專案唯一負責人,也能談自己的參與。」

範例:

  • Increased traffic to website 50% over six months by (listing the actions you took)
  • Led teams of four to six programmers
  • Created new task tracking system that reduced schedule creep by 40%
  • Installed new routers that increased throughput 25%, virtually eliminating the 20% of help desk calls related to network responsiveness
  • Reduced open ticket backlog from 500 to 20 in three months
  • Refactored codebase to take advantage of standard C++ libraries, reducing total LOC from 100,000 to 70,000

談論影響力與成就是開發者履歷中最被低估的做法之一。多位資深開發者都得出相同結論:

Before and after:results and impact#

Before:

原始版本敘述籠統、缺乏具體資訊的工作經歷

這個敘述不算糟,但沒有提到任何非公司內部人員能理解的細節,也沒有數字。同事也許知道 MyTrinn 平台是什麼、工作有多複雜,但招募者與 hiring manager 完全沒概念。最後一句不算差,但讓 refactor 看起來像是被指派的,且影響力不清楚。結尾用 etc 也讓整段看起來草率。

改善點視覺化:

標記出原版本缺乏數字、被動語氣等問題

After:

重寫後加入具體數字、行動動詞與技術細節

改寫後加入具體內容:數字、行動、使用的技術。這個版本傳達出此人推動了業務、能把事情做完,並點出了專案中使用的具體技術。

Don’t Be Humble#

履歷是在**銷售「專業的你」**給目標職缺。不要吹噓不實的事情,但要努力為讀者(招募者與 hiring manager)描繪出最好的自己。

  • Talk about yourself, not your team—avoid using “we”
    • 使用第一人稱(大多情況可省略 “I”)。
    • 履歷是關於「你」帶來了什麼。
    • 非母語英文使用者注意:有些語言習慣用 “we” 談成就,在英文履歷中請一律使用第一人稱。
  • Be concise but not humble
    • 不要隱藏你的成就。
    • 有疑慮時,稍微「誇大一點」造成的傷害,小於「過度謙虛」造成的傷害。
  • Make side projects and open-source contributions shine
    • 用 results-impact-contribution 的框架描述。
    • 不要只丟 GitHub 連結而不加說明——沒人會點進去看。
  • Do talk about extracurricular activities adjacent to tech
    • 放在履歷尾端。
    • 談影響力、難度,連結到高品質的成果。
    • 例如:辦過 100 人的 meetup、寫技術部落格並連結到一篇特別好的文章。
    • 注意避免可能觸發偏見的活動——例如在曼徹斯特應徵時寫「支持 Chelsea」(曼聯敵對球隊)可能觸發無意識偏見。
  • Mention your learnings
    • 說明你為什麼、如何學會某項技能,以及它如何影響目前工作或未來目標。
    • 例如:為了加速專案主動學新技術、為了挑戰自己而學習——這些都是 hiring manager 看重的特質。
  • Don’t highlight negatives
    • 不要捏造事實,但也不必列出對自己不利的東西。
    • 失敗專案、低 GPA 等負面內容可以安全地省略。

Before and after:don’t be humble#

Before:

多處使用「團隊」與被動語氣、含糊修飾詞的原始履歷

這個版本的主要問題:

  • Work experience:低估候選人。多次用團隊代替個人、使用被動措辭(“team member”、“took part”)、加上模糊修飾詞(“sometimes”、“occasionally”)讓人覺得此人貢獻很少。
  • Volunteer experience:細節多但缺乏數據,篇幅冗長。
  • bareGo:描述過於隨意(“this project is usually…"),沒說明為何有趣或具挑戰性。
  • RESTAPI project:描述過於通用,可能是 Hello World 也可能是複雜實作。

改善點視覺化:

標記出被動語氣、模糊用詞、資訊不足的問題點

After:

重寫後具體化數字、學習收穫、專案挑戰的版本

改寫後解決了幾個問題:

  • 專案描述加入具體影響力、數字與技術。
  • Learnings 段落解釋此人為何學 Groovy 與 Scala,希望達成什麼。
  • Volunteer 區塊聚焦候選人的貢獻與成果:「I built up a local group of 500 developers, organized 30+ events and hackathons」。並移除了對履歷幫助不大的「合作夥伴」內容,改以媒體報導提升可信度。
  • bareGo 現在說明專案目標與解決的複雜問題。身為 hiring manager,已經準備好點連結檢視。
  • RESTAPI with Node 也描述得更完整,加入 HATEOAS(Hypermedia as the Engine of Application State)與 Content Negotiation 等非尋常元素——會立刻引起技術型 hiring manager 的興趣。

Write a Resume for That Job#

如果你的履歷已經能穩定拿到招募者電話,那很好——代表你的個人檔案很出色,或該角色競爭不激烈。

然而大多數公開職缺,合格申請者遠多於職缺名額。對招募者來說這是好事,但對你來說意味著必須更努力才能抓到注意力。要讓履歷脫穎而出,必須為「那個特定職缺」量身打造。

做法#

  • Create a “master” version of your resume
    • 詳細列出工作經驗與專案,使用 results、impact、contribution 的語言。
    • 可以超過兩頁——只要之後能為每個職缺修剪即可。
  • Create a version of your resume for the specific job description
    • 重新編輯以使用與職缺描述類似的語言。
    • 移除對該職缺無幫助的內容,或把它們移到後方。
    • 例如應徵以 Kotlin 為重點的 Android 職缺,而你同時有 Android、Kotlin、web 經驗,就強調 Android 與 Kotlin 貢獻,把 web 移到後面。

From the inside out:獵頭對履歷客製化的建議

Csudi Csudutov,Mimox 創辦人(匈牙利最大 tech 招募公司),20 年面試過 6,000+ 位開發者:

***「從 master 履歷移除非相關的 bullet,你失去的東西非常少。**大多數人卻不敢這麼做,寧可硬塞。別這樣。履歷的目的是拿到面試,面試時有的是機會談履歷上沒寫的東西。毫不留情地移除無助於這份職缺的內容。」*

***「為職缺量身打造的最大『秘訣』之一,是理解該職缺為什麼開缺。**仔細閱讀 JD。它像是在找人建立全新東西、新團隊?還是維護既有系統、替補某個離職者?大公司不容易看出來,但小公司可以這樣判斷:」*

「閱讀小公司職缺時,搜尋該公司員工的 LinkedIn 並瀏覽。他們已經有會該職缺技術的人了嗎?如果有,你很可能要跟他共事,他也會出現在面試迴圈裡。若沒有,那大概是新東西——從零到一的能力就會被看重。」

*「和獵頭或招募人員合作對你有利,他們已經握有這些內幕。他們站在你這邊,希望把你放到對你與公司都合適的位置,所以不要輕忽透過代理商的管道。」*

Before and after:writing a resume for that job#

以下是 Amazon 的 JD 片段,加上高亮標示出可在履歷中呼應的關鍵字(前提是你確實有相關經驗)。

Amazon Software Development Engineer 職缺描述,標出可呼應的關鍵字

Before:

通用版履歷片段,未針對職缺調整語言

這不算糟,但一看就是通用版本,完全沒呼應 JD。讓我們為 Amazon 這個職缺客製化。改寫後的用詞反映 JD 的語言——注意履歷內容完全相同,只是換了語言。

After:

針對 Amazon 職缺調整用語後的履歷片段

履歷背後的人還是同一個,但招募者讀完兩個版本後,更可能推進第二個量身打造的版本。

Different Companies, Different Focus#

頂尖 tech 公司比較不在乎你用哪個特定語言,他們在乎的是軟體工程能力;顧問公司與代理商則更在乎特定技術與該技術的年資。針對不同類型的公司量身打造履歷。

Tech 公司招募泛用工程師#

大型 tech 公司與快速成長的 venture-funded 公司幾乎都找 generalist——因為他們的 stack 多元且變化快。他們看重:對至少一種程式語言的深入理解、演算法與資料結構、以及(資深者)系統設計能力。

典型 JD 大概長這樣:

大型 tech 公司的 generalist software engineer 職缺描述範例

吸引這類公司的原則#

  • Do mention programming languages you are proficient with——尤其是 JD 提到的。會幾種語言代表你能快速上手新語言,這在這類公司很重要。
  • Do tailor your resume to the job description——資料結構與演算法、CS 基礎、OO 設計、分散式系統、能用數字佐證的 scale 經驗,都是招募者在意的。
  • Do focus on impact and engineering metrics——例如 RPS、test coverage 提升、infra 成本節省、使用者/客戶團隊數、latency 改善。
  • Do mention open source frameworks by the company——如果你熟悉、使用或貢獻過就列出。這類公司常貢獻 open source,熟悉其冷門框架會很加分。
  • Don’t list too many technologies——在這類公司 hiring manager 預設你能快速上手任何工具,招募者對 keyword stuffing 也比較敏感。
  • Don’t list trivial tools——列 Trello、JIRA 只會讓 hiring manager 皺眉,這些不用是工程師都會。

From the inside out:抓住 tech 公司 inbound sourcer 的注意力

Veronika Nora Nagy(為 Uber、新創、顧問公司招募,曾為 Uber 的 tech inbound sourcer):

「強調與你所應徵公司相關的經驗。例如 Uber 的 senior 後端職缺,我們找的是有處理大型分散式系統經驗的工程師——把 monolith 拆成 microservices、或在目前/過去公司建過 microservices 的人。Scalability、reliability 相關經驗也會吸引我。」

***「無論申請什麼角色,請清楚標示你使用過、與職缺相關的技術。**我也喜歡看到使用過多種語言與框架的人——這代表好奇心、學習意願、開放態度。」*

「不同文化教的 CV 寫法不同,有些不一定適用於國際公司。有些文化喜歡用表格列經驗——但 tech 公司的招募者往往覺得難讀。簡短精煉是關鍵。」

「我喜歡乾淨、易讀的履歷勝過一切。強調最相關的專案、用過的技術,並準備在招募者電話中談這些。」

「最後:只有在你願意學新語言、或對該公司的既有 stack 感到舒適時,才申請 generalist 公司。先看他們的 engineering blog,了解 tech stack。如果你堅持只用 C# 或 Go,但公司只用 Java 或 Node.js,那只是浪費雙方時間。」

招募「特定技術」的公司#

非 tech-first 公司與小公司常為特定技術招募。Stack 已經確定、短期內不會改變。從 JD 就能看出:它會大量列出所需技術——這些就是公司現在的 stack,也是他們要找的。

典型 JD:

某 Java Developer 職缺描述,明列技術需求

這類 JD 也較傳統,會用 “duties and responsibilities”、“technical expertise”、“delivering code” 等字眼。

吸引這類公司的原則#

  • Do mention all relevant technologies in the job description——即使不是樣樣精通也值得列。這類公司的招募者通常不太懂技術,只會掃特定關鍵字或短語。
  • Do spell out how many years’ experience you have with the main language——值得在簡短 summary 中直接寫出。
  • Repeat the technologies——在工作經驗中再次出現你用過的技術,讓招募者與 hiring manager 雙重確認你是 hands-on。
  • Do not list unrelated or trivial technologies——keyword stuffing 對這類公司稍微適用,但別誇張。
  • List relevant technology certifications——tech 公司通常不在乎證照,但非 tech-first 公司常視為正向訊號。
  • Do keep your resume easy to read——別為了塞技術而胡亂造句。這類公司收到的申請本來就充斥關鍵字卻內容空洞,找到平衡點就能脫穎而出。

Agencies#

代理商把開發者外包給客戶。與其他公司不同,他們對「額外技術」更有彈性——可能派上用場。適用於非 tech-first 公司的建議大多適用,但技能列表方面有兩個例外:

  • Consider mentioning all technologies you are proficient with,不只是 JD 上的。
  • List all certifications for technologies——證照讓代理商更容易把你外包出去。

From the inside out:抓住技術特定公司招募者的注意力

Konstanty Sliwowski(近 20 年招募資歷,專精 Go、JavaScript、PHP、Java 職缺),在 The Developer’s Guide to Getting a New Job 中的建議:

「先列最強技術。絕不要列出每一樣你碰過的技術——極端例子:完全不需要列 Microsoft Office。可以把技能與技術分類,做成一個展開列表。」

「列舉技能的實際應用。你的 CV 必須舉例說明每項技能如何、何時、在什麼情境下被使用,產生什麼效果。」

「角色摘要保持精煉——每個角色三到四個 bullet 最理想。可以用幾條 bullet 或一段文字涵蓋主要職責與關鍵成果。額外資訊放到最後一頁。句子要簡短(認真——避免長句),別列出你用過的每個工具或每個專案。用 action verb 開頭讓重點快速傳達。」

Keyword Stuffing#

Keyword stuffing 是個爭議但重要的主題。在招募者不太懂技術的公司,履歷篩選的方式是「沒有某些關鍵字就丟掉」。招募者與 HR 常根據 hiring manager 的期望或經驗做 pattern matching。

舉例:後端 JD 明確說團隊用 Java 開發。大多情況下,沒提到 “Java” 或 “backend” 的履歷會被略過。若團隊做分散式系統,較不懂技術的招募者可能會略過所有沒有「distributed」字樣的履歷——即使你描述的是「microservices」、「messaging queues」、「globally fault-tolerant systems」。招募者不是工程師,他們只找「distributed」這個詞。

這種狀況在有技術型招募者的大公司比較少見,但在由較資淺的人篩選時確實存在。

過度 Keyword Stuffing 的樣子#

變通方法是把所有可能相關的關鍵字都塞進履歷——也就是 keyword stuffing。下面就是個例子:

過度 keyword stuffing 的技能列表:過量分類與技術

Keyword stuffing:做過頭的例子

做這種事的人會覺得「我都 cover 了」,但這會讓履歷看起來不專業。在招募者不太懂技術的地方或許可行,但在需求明確、招募者技術性較強的地方,這招效果差。即使招募者決定繼續,身為 hiring manager,我會把這份履歷放進「不確定」堆。

合理地納入關鍵字#

保持專業的做法是:納入最相關的關鍵字(技術與框架),但以人類可讀的方式呈現

  • 在 Technologies、Skills 或 Languages and Technologies 區塊簡短列出與職缺相關的技術。
  • 在 Experience 區塊順勢提及你在專案中實際用過的相關技術。
  • 同一項技術同時出現在技術區與具體工作經驗中是 ok 的,但整體仍要保持易讀。

修改後的版本:

精簡後的技術列表與加入具體範例的工作經驗

合理的關鍵字:只列與職缺相關的,在工作經驗中提供範例

結果是更乾淨的履歷,仍保留關鍵技術——事實上還強化了你真正 hands-on 的那些。

不同職缺的招募者掃的是不同關鍵字,這也是為什麼要為每個職缺量身打造履歷。調整用詞與列出的技術,讓招募者在看到關鍵技術後能繼續往下讀。

別忘了:你的目標是通過初步篩選——大多數沒有 referral 的申請都在這關失敗(其中不乏真正合格的人,只是履歷沒說對故事)。

Recap:改善履歷的行動清單#

本章介紹了讓履歷脫穎而出的方式。具體描述成果與影響力、用數字傳達價值是最大的差異化因素;為職缺量身打造更是關鍵。

不同公司在乎不同面向:tech 公司喜歡看到廣度,技術特定公司在乎該 stack 的專精度。合理的 keyword stuffing 能幫助履歷通過 ATS(沒有 referral 時特別重要)。

檢查清單:

  1. Numbers and impact in your resume——你的結果大多以數字或百分比表達了嗎?越具體、越可衡量,越能傳達成果。
  2. Are you using active language?——用主動動詞描述你做了什麼,而非被動地描述發生了什麼。
  3. Are you mentioning technologies in your examples?——除了數字,也要具體點出你用什麼工具達成結果。
  4. Have you customized your resume for that specific job?——用類似 JD 的語言描述活動?明確呼應 JD 列出的技術與語言?使用 JD 中的主動動詞?量身打造與描述影響力,是最有效的兩個改動。
  5. Are you talking about yourself, not “we” or “the team”?——履歷是關於你的成就。不要謙虛——該居功就居功。
  6. Do you mention impactful, complex or interesting side projects?——你有清楚說明它們為何相關嗎?
  7. Generalist 還是特定技術職缺?——兩種類型的公司需要不同的履歷版本,要區分清楚。
  8. Have you “stuffed” keywords in a sensible way?——對照 JD,你的履歷有包含主要關鍵字嗎?含有關鍵語言與技術、職位名稱、tech stack?若有最低年資要求,是否直接或間接傳達?