軟體開發者可以分成兩種：已經拿到第一份全職工作的，以及還在找第一份全職工作的。你屬於哪一邊，決定了招募者與 hiring manager 關注的重點。

• 還沒有全職經驗者：實習、學歷、專案、成就是你與其他申請者最大的差異來源。
• 已經有第一份工作者：實際工作經驗與日常使用的專業技能，變得遠比學歷重要。
• 經驗累積到無法放進幾頁後，你會面臨「快樂的煩惱」——該刪掉哪些過去的經歷。

本章依照經驗階段，說明不同情境下履歷該如何結構化。

Structure for Interns, New Grads and Bootcamp Grads#

學生或剛畢業時，常常會覺得自己沒什麼東西可寫。請善用你擁有的一切——而如果真的太薄弱，就在申請的同時補強內容。以下是評審者最在意的經歷，按優先順序排列：

1. Real-world work software development experience（真實的軟體開發工作經驗）：有兼職或全職開發經驗，就大方列出來，加上你的成果。
2. Internships（實習）：具體說明成果、影響力與你的貢獻。注意大型 tech 公司的應徵者通常有多次成功且有影響力的實習經驗。
3. Sizeable contribution to real-world (open source) projects（對真實 open source 專案的顯著貢獻）：核心貢獻者或頻繁貢獻者都值得列出。
4. Your school details（學校資訊）：尤其是知名學校與高 GPA。必要時可加上一句說明：例如 「Budapest Technology University is the #1 ranked university for Computer Science in Hungary」。
5. Projects that stand out（亮眼的專案）：因複雜度、使用者數量或其他令人印象深刻的指標而突出。
6. Tutoring and leadership positions in student groups（教學與學生社團領導經驗）：擔任助教或 lab assistant 代表你能指導他人；帶領學生社團或專案也同樣有價值。

一份新鮮人履歷的建議結構#

以 Pragmatic Engineer’s Resume template ^↗ 為例：

依照以下準則安排，讓履歷容易掃描，且重要資訊靠近頂部：

• Fit on one page（放在一頁內）：身為新鮮人，競爭者眾，沒人會讀到第二頁。
• Work Experience and Internships：如果有任何工作經驗或實習，放最前面。
• Projects：用 results、impact、contribution 的格式描述為什麼它們重要，並提供連結。如果程式碼整理良好、README 完整，可連到 GitHub。
• Education：畢業日期（含預計）、主修、相關或亮眼的活動、成績、獎項。
• Languages and Technologies：把你真正 hands-on 的技術寫在第一頁。
• Interests：一兩個興趣可以成為面試時的話題起點。
• Use an order that highlights your strengths：最相關的放最前面。大多數新鮮人適用上述順序，但可依職缺調整。

From the inside out：新鮮人與實習生如何吸引招募者？

Sebastian Prieto Tovar 與 Claire Taylor 曾為 Uber 與其他 tech 公司招募數百位學生與實習生：

「從數百份履歷中脫穎而出的，是那些『與 JD 相符』且『展示相關經驗』的履歷。可以是實習，也可以是個人專案。我們總會告訴學生：先讀 JD，然後相應地調整履歷，能直接聯絡招募者最好。大學生也可以找職涯中心幫忙。」

「履歷上我們看：學業、相關課程、你最擅長的東西、最熱情的課題。也看課外活動、hackathon、校外團隊合作，還有你自己做的 app、網站。」

「實習招聘我們會看時程——例如 6 月開始的實習，我們只考慮能在那時開始的候選人。履歷上請明確寫出你能開始的時間或剩餘學期數。」

「請花足夠時間準備面試：讀公司資料、看影片、了解文化、讀員工故事、研究 JD；面試前在 LinkedIn 上查面試官並讀他們發表過的東西。這不只展現誠意，也能學到很多。」

申請大廠（Big Tech）的建議#

以下是 Fortune 100 招募人員在 Twitter 分享的建議 ^↗，適用於所有每個職缺都收到上百份申請的大公司：

• Don’t put your address：沒人會寄信給你。地址只用來判斷是否需要搬遷或簽證。
• Don’t include an objective statement：你在申請工作已經很清楚。
• Only include your GPA if it’s high，否則會扣分。
• DO include a graduation date，不要寫 “2019—present”。
• Use a PDF format。
• Use numbers 來展示你做了什麼，不要列出籠統的責任。
• Don’t waste time on a cover letter，除非能直接寄給 hiring manager 或招募者。
• Tailor your resume for the position，使用與 JD 呼應的語言。

Structure with Work Experience#

離開學校一段時間後，請用以下結構讓履歷容易審閱。

• Work Experience at or near the top of the page：目前職稱、公司、近幾年工作經驗放最上面或接近頂部。
• Languages and Technologies section on the first page：列出你精通或至少熟練的相關技術，不要列無關項目、也不要列出熟練程度。
• If you have spent a long time at one workplace：列出重要專案與擔任過的職稱。升遷時視為子區塊，列出當時做的專案。升遷是重要訊號，代表你能創造被認可的影響力。
• Education details become less important with seniority：隨工作經驗增加，學歷區要縮短。
  • 1–3 年經驗：可以有細節。
  • 5+ 年經驗：只留學位、畢業日期、最多一個仍相關的亮點（Summa cum laude 可留）。
  • GPA、課程、活動都應移除。
• Spend less space on old positions：10+ 年經驗者，超過 10 年的內容已不具代表性，技術也可能過時。縮短這些區塊，甚至刪除不相關的。
• Extracurricular：專利、發表、演講、亮眼的 open source 專案、發佈的作品。結尾放興趣（保持簡短）讓履歷更有人味。
• Certifications：與工作或產業相關的證照可放在工作經驗下方。和政府合作的公司可能特別看重。但要小心——像「LinkedIn 程式語言證書」這種很容易取得的證照反而會扣分。
• Projects：工作經驗越多，課外專案越不重要。真正亮眼的專案可放在 extracurricular。
• Interests：依履歷長度決定是否加入。一頁版空間不夠時可省略。

From the inside out：招募者通常在履歷中找什麼

Victoria Farelly（曾於 Uber、Booking.com、ING 招募）：

「Hiring manager 常跟我說：『我要這五樣東西，少一樣我都不錄。』好的招募者會提醒他市場現況——也許能接受只有三四樣、再訓練或 mentor 一下。」

「當 hiring manager 比較彈性時，我會看候選人是否在類似環境或類似問題上工作過。例如招 Uber 時，我會找在 scale 上工作過的人。他們在 multidisciplinary team 嗎？用過什麼技術？我不只看工作專案，也看個人專案。例如你工作用 .NET，但職缺必須會 Java 或 Go，那我會想在專案或技術區看到這些語言。」

「真正讓你脫穎而出的是『為職缺量身打造 CV』。如果你申請 20 個職缺，就該有 20 份不同的 CV，每一份都針對該職缺。這不是壞事，而是必要的做法。」

量身打造履歷的可操作方法請參見 Keyword Check for That Position。

Languages and Technologies#

「這個人真正 hands-on 的語言與技術是什麼？」 這是招募者與 hiring manager 看履歷時最先問的問題之一。越容易從履歷中找到答案越好。以下介紹三種常見做法。

Approach #1：獨立的 Languages and Technologies Section#

最常見的做法是把職缺相關且你精通的技術，放在單獨的區塊。名稱可以是 Skills、Tech、Tools 等——名稱不重要，內容才重要。

• 只列你能日常使用的技術
• 不要只列 JD 上的東西，但也不要過度鋪陳
• 避免標示熟練度（除非對某項技術有極深的知識）
• 避免評分制
• 避免列瑣碎或與工作無關的技術
• 即便有獨立區塊，工作經驗敘述中仍要順勢提到關鍵技術——可以強化你確實 hands-on 的印象

Before and after：Languages and Technologies#

這份履歷是申請一個全端職缺。JD 要求至少一種 OO 語言（JavaScript、Go 或 Java），React.js 加分，API 設計經驗加分；engineering blog 顯示公司主要使用 AWS。

Before：

這個區塊列出此人過去碰過的所有技術，包含一些隱含於其他技能的項目——用 Java 當然會用 IDE 如 Eclipse。有些項目沒有意義：Rational Rose 幾乎只在學術界使用；phpMyAdmin 讓人懷疑你能不能用純 PHP；Trello、Word 誰不會用？

這份履歷還用了 “expert”、“proficient” 這些字眼——這是雙面刃。它暗示你在其他語言都不是專家。與招募者交談時也發現，自稱「expert」的人常在面試中因「深度不足」而被拒。

實用原則：不要標示熟練度。只列你熟練的語言，並把最擅長的放在最前面。

改善點視覺化：

After：

清理後的版本乾淨許多。格式使用 tab 對齊，容易掃描。可以在幾小時內學會的工具都移除了，列表更貼近 JD，只保留真正 hands-on 的語言。

經過訪談發現這個人已多年未使用 C++ 與 Perl，自評很生疏。移除「舊」語言還有另一個好處：老舊語言可能觸發 age bias——招募者會無意識地假設你年紀大、或不願學新語言。

Approach #2：把技術融入工作經驗#

另一種做法是在每段工作經驗中明確列出用到的語言與技術，不用獨立區塊。這種做法能傳達「技術的新近性」，因為大列表會讓人不確定哪些技術你最近還在用。

這種做法特別適合申請招募泛用工程師（generalist software engineer）的 tech 公司——能展示你曾在不同語言與 stack 間切換，是一種優勢。

範例片段：

把技術自然地編織進敘述也是可行的做法，讀起來更流暢。建議在「固定位置」提到技術，方便讀者掃描：

Approach #3：區分「仍 hands-on」與「較生疏」的技術#

獨立列表的缺點是無法區分「每天在用」與「需要複習」。這種做法適合加入幾項「略生疏但願意補上」的技術，但清楚標示出來。

下面這個例子是應徵一家 Ruby 為主的公司——這個人以前寫過 Ruby，也不介意重新拾起，但 Ruby 的熟練度不如他每天使用的 JavaScript 與 Java。

Tell a Story#

你的履歷應該反向時間順序講一個故事，讓讀者一眼看懂。看看這個範例：

它展現了進展與清晰度——這正是你要追求的。以下是讓故事清楚的幾個做法：

• Make promotions clearly visible（讓升遷清楚可見）
  • 上例中明顯看出此人在 Skyscanner 被升遷。
  • 升遷是重要訊號——代表你能創造影響力並被公司認可。
  • 好的 hiring manager 會注意到這點，因為對開發者來說，跳槽往往比內部升遷容易。
• Don’t always stick to your “formal” titles when they describe your role poorly（職稱不適切時不必硬用）
  • 有些公司的職稱聽起來怪——金融業的 Associate（軟體工程師）、Vice President（資深軟體工程師）。
  • 若職稱無法描述實際工作，可以加註或使用更貼切的說法：Software Developer (Associate)。
  • 作者親身經歷：曾在新創公司被「升遷」兼任 Community Manager，官方職稱也改了。他至今後悔讓履歷上最後一個職稱變成 Community Manager，而不是 Software Developer。
• Dec 2013 vs 2013：超過幾年的日期省略月份
  • 2–3 年以上經驗後，月份層級細節只會成為雜訊，請移除。
• Omit work experience that doesn’t support your story（刪掉不支援故事的工作）
  • 有人會在履歷上列披薩外送員。
  • 有人 15 年經驗還列十幾年前的 4 次實習。
  • 聚焦故事，只保留相關的。近期經驗要比早期經驗寫得更深入。

From the inside out：修改職稱符合倫理嗎？

一位在國際新創與 Fortune 100 招募十年的資深招募人員：

「唯一符合倫理的例外是：你過去三個月以上的實際職責與職稱不符；或職稱過於公司特定以致無法轉換到業界。」

「例如你以 software developer 的職稱加入一家新創，但因為節奏快，這一年你實際上擔任 team lead、帶五人團隊，職稱卻沒變。若不調整，招募者掃過時可能會略過你的團隊領導職缺申請。這種情況下我認為可以調整職稱反映實際工作。其他情況我不建議。」

作者（作為 hiring manager）舉例：一位被聘為 iOS engineer 的人，三個月後轉做後端，一年半沒有更新職稱。這種情況可以把履歷上的職稱改為 Software engineer (iOS & backend)、Software engineer，或把該段時間切成兩段分別標示。

The Summary Section#

許多履歷以 “Summary” 或 “Profile” 開頭，內容從一句話到一整段都有。例如：

• An experienced and positive backend developer, who enjoys working on high-performing teams and contributing to open source. Looking for a remote position as a Go developer in a finance company that values open source, hard work and gives back to the community.
• Solid yet versatile Software Engineer with more than 12 years experience in developing and leading projects. I hold a BSc in software engineering and am passionate about distributed systems.
• I am a software engineer with 5 years’ experience, passionate about technology and microservices…

招募者與 hiring manager 在首次掃描時很少閱讀 summary，不論你投入多少心力。他們只在決定繼續看時才會讀。對經驗較少的候選人，除非能為職缺量身打造，否則建議不要放這個區塊。

Summary 可能會反效果#

假設你應徵 developer 職缺，summary 寫「尋找能領導的機會」。如果 hiring manager 並不打算提供領導機會，他可能直接跳過你——認為雙方期望不符。反之，若沒寫這句，你可能順利面試、錄取，進入團隊後再自然發展成 lead。

何時 Summary 有幫助#

• Senior/standout profiles：資深或亮眼候選人的 summary 會被認真閱讀。例如你在知名 tech 公司有四年經驗、申請較小公司時，可以說明你正在找「下一個挑戰，偏好高成長但規模較小的環境」。
• For fully remote positions：說明你只找遠端或擅長遠端工作。
• When changing roles compared to your last title：例如從 manager 回到 IC，用 summary 說明原因，hiring manager 會想知道。
• With formatting that naturally lends itself to reading this section：有些模板留白較多，自然引導讀者閱讀 summary——代價是履歷資訊密度較低。

From the inside out：如何打造有力的 summary

Randall Kanna（曾於 Eventbrite、Pandora 任資深工程師）在 The Standout Developer ^↗ 書中建議：

「傳統的『Objective: Obtain a goal in Software engineering at a tech company.』已經過時。強力的 summary 能讓你在一堆履歷中被看見，並立刻抓住招募者的注意力，展示你是誰、強調一項成就。」

「寫 summary 的關鍵是『最後才寫』。先寫完其他部分，再從履歷中找出最亮眼的細節提煉出來。招募者不在乎你愛園藝或爬山，他們想知道你能為公司創造什麼成果。」

「可以的話，為每個職缺客製 summary。例如我要申請 iOS 工作時，我不會強調前幾年做前端，而會強調我在短時間內自學 Swift 與 Objective-C，補上公司需要的角色。」

「最後：summary 不要太短也不要太長。」

Structure for Senior and Above People#

超過 10 年經驗、任職過多家公司時，你會逐漸從應徵者中脫穎而出。此時履歷會被 hiring manager 本人（而非僅是招募者）更常閱讀。他們想了解你的歷程以及你能帶來什麼。

以下是可以「打破」前述建議的幾個方向，以發揮你的優勢。

主要原則#

• List your major deliverables and accomplishments——兩頁上限不是硬性規定，但盡量別超過。
  • 新鮮人 1 頁、一般人 2 頁是一般建議。
  • 若你有大量相關經驗，可稍微超過；但仍要保持精煉。
• Consider having a summary section——簡短描述你的亮點以及公司能從你身上得到什麼。為職缺量身打造。不建議談動機（那是 hiring manager 面試的話題）。對資深候選人來說，summary 很少是決勝關鍵，履歷其他部分才是。
• Do have separate resumes for management and IC positions
  • 資深工程師常在 tech lead、engineering manager、senior engineer 角色之間切換，這種 manager-engineer pendulum ^↗ 很正常。
  • 最好的 staff engineer 有些曾是 manager。
  • 但請針對每種角色分別製作履歷——一份說明為何要回到工程師，另一份說明為何適合當 manager。

公司很少招募 hybrid 角色。如果 hiring manager 收到一份「混合 senior engineer 與 manager 經驗」、沒有清楚方向的履歷，往往會被丟進「不知道怎麼處理」的堆裡。為每種職位量身打造，callback 機率會高很多。

範例：同一人，兩種版本#

此人兩種角色都開放，偶爾想念寫 code，但在對的機會下也願意繼續走領導路線。

Resume 1——回到 IC：

Resume 2——繼續走 manager 路線：

兩份履歷講了非常不同的故事，但所有事實都 100% 正確。差異點：

• Summary tailored for the role——各自說明為何適合 IC 或 EM 角色。
• Titles amended to tell the story——此人在 OneDrive 的職稱原是 Senior Engineer，但實際上從第一天就帶團隊。IC 版保留原稱呼；manager 版改為 “Team Lead, Senior Engineer”，捕捉到他其實有四年以上管理經驗。
• Role highlights reflect on the career path——Head of Engineering 的內容在兩份履歷幾乎不重疊：IC 版聚焦個人貢獻成就，manager 版聚焦管理成就。

製作不同版本時絕對不要扭曲事實。你的履歷會在公司內流傳。招募者曾看過候選人在系統裡有多達 4 份互相矛盾的履歷——該人後來被列入黑名單，因為看起來像在「為職缺捏造經歷」。

From the inside out：履歷可以超過兩頁嗎？

Ken Liu（Microsoft 招募近十年）：「保持精煉，一到兩頁最理想。如果是管理/總監級，可到 3–4 頁上限——但不鼓勵。大公司的招募者與 hiring manager 即便是資深候選人，也只會花 10–15 秒做初步判斷。」

Steve Ball（CTO 20 年，面試過上千份履歷、錄用上百名工程師）：「一兩頁履歷是現代的風潮。身為 CV 審閱者，我常覺得細節不夠無法做決定。感興趣時，我會請招募者向候選人要更完整的 CV。我建議候選人為每個角色列出主要交付物與成就。如果你有 5–10 個角色，很容易超過 2–3 頁。如果一個角色裡有很多重要成就，就列出來。」

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

本章依據經驗階段介紹了建議的履歷結構。把招募者與 hiring manager 最在意的細節放在第一頁；講故事、客製 summary、列出相關技術都是結構良好履歷的特徵。

進一步檢查清單：

1. 區塊順序是否依據你的經驗階段排列——關鍵細節（技術、工作經驗或學歷、專案）先出現。
2. 你列的語言與技術相關嗎？——只列你熟練、且與職缺相關的技術，移除無關項目。不要標示熟練度，改用排序表達。
3. 你在講故事嗎？——職稱展現進展嗎？升遷有被視覺化嗎？非標準職稱有釐清嗎？是否刪掉了無助故事的工作？
4. Summary 是否為職缺量身打造？——若有 summary，夠精煉嗎？是否反映職缺、談具體事實而非空話？
5. 近期與早期經驗的細節比例是否恰當？——近期多、早期少。10–15 年前的細節可以縮減或刪除。
6. 日期是否容易閱讀？——格式一致嗎？該省略月份處是否省略？
7. 履歷長度是否與經驗相符？——新鮮人一頁；幾年經驗兩頁；資深或 10+ 年者仍應盡量不超過 3 頁。