根據你目前的經驗程度，履歷的重點應該放在不同的地方。本章將針對學生、Bootcamp 畢業生、轉職者、資深以上工程師、Tech Lead 與 Engineering Manager，分別提供具體建議。

在學大學生（Current College and University Students）#

如果你還在學校，其實你已經在為未來的履歷累積內容。除了掌握軟體開發、軟體工程與電腦科學的基礎以外，以下幾件事對未來求職會很有幫助：

• 申請實習 (Internships)：作為學生能獲得的最佳經驗之一，就是在真實業界環境中處理實際問題。請提早準備並積極申請實習，我自己當年沒有實習，至今仍感到遺憾。
• 參與校園課外活動：協助教授、帶實驗課、辦活動等，都是能累積 mentoring、領導與主動性經驗的好機會。
• 發佈你的課堂專案：大學中必定會有需要寫程式的課堂專案，花點額外心力把它們發佈到網路上，讓別人可以下載或試用。特別是畢業專案，通常比一般作業更複雜，更值得展示。

上述活動會幫助你成長得更快，並讓你在畢業時的求職中脫穎而出。實習更可能直接帶來畢業後的 return offer。

Bootcamp 畢業生（Bootcamp Grads）#

作為 Bootcamp 畢業生，你的經驗很難單靠本身脫穎而出。雖然你學到了基本的軟體開發技能，但修習時間通常比大學電腦科學／軟體工程畢業生短，而且你多半會與許多其他 Bootcamp 畢業生競爭同一個職位。

如果你完全沒有業界經驗，只能應徵那些「接受零業界經驗」的職位，但這類職位不多。

Projects：你脫穎而出的關鍵#

多數 Bootcamp 畢業生列的都是課程中的專案。若想突出，請考慮以下做法：

1. 發佈有完整 README 的專案到 GitHub。README 應包含良好的摘要、截圖、執行方式與測試方式。可參考 Awesome READMEs 清單 ^↗。
2. 為專案加入可執行的測試。多數 Bootcamp 作品沒有自動化測試（單元測試、端到端測試），甚至沒聽過 TDD (Test Driven Development)。可參考 Learn Test Driven Development ^↗。若有測試，請在 README 加入「Running tests」小節；可參考 Leaflet 的做法 ^↗。在專案描述中標註 code coverage 百分比。
3. 貢獻其他開源專案 (Open Source)。若你的 PR 成功合併，你就能宣稱自己為某個被 X 名開發者使用的專案做過貢獻。可用 star 數作為衡量指標。例如：Contributed to Leaflet, the leading open-source JavaScript mobile-friendly interactive library with more than 28,000 developers using it.
4. 把 take-home 題與 coding challenge 發展成完整專案。通過履歷篩選後的下一關通常是 take-home 題。繳交後別停手——繼續完善它，把程式碼放到 GitHub、加入測試、打磨使用者體驗。花一點錢買網域與 hosting，讓任何人都能使用，並寫進履歷。若未通過，就索取 feedback 並持續改進；當你做出滿意的版本後，也可回寄給該公司，說不定會有轉機。

業界觀點：Bootcamp 畢業生如何脫穎而出？

Raymond Gan 於 2013 年從 Flatiron School 畢業，畢業後在紐約擔任軟體工程師，並在多家新創與科技公司任職。他經營一個專為 Bootcamp 畢業生的讀書會，以下是他的建議：

「在找工作的過程中，除了有支薪的軟體工作外，最有價值的事情就是為熱門開源專案修 bug 或加 feature！這比刷 LeetCode 或做學生專案（沒有真實使用者）有價值得多。

我六年來認識的 junior 開發者，幾乎沒有人把 PR 提到熱門開源專案並成功合併進 master。開源工作更實際、更有說服力，而且直接對應日常工作——它們有『真實客戶』！這才是公司最想要的能力。

這裡有一份 新手友善的專案清單 ^↗。或者你可以從擁有幾百到幾千顆 star 的熱門專案中尋找 open issues。

以 Yarn ^↗ 為例，從 star 數可知至少有 35,000 名開發者在使用。你若能讓 PR 被合併，等於讓資深 JavaScript 工程師認可你的程式碼足夠讓 41,000 人使用。公司會被哪種經歷打動？

想找靈感，可參考 Leaflet 已合併的 good first issues ^↗。這些都是很小的修正，讀一讀就知道入門有多容易。

持續透過 PR 學習。被駁回也沒關係——駁回你的是這些專案的資深 owner，他們常會留下改進建議：『加測試、修這個 bug、用這種演算法試試』。這就是最棒的學習。」

Before & After：Projects#

大部分履歷建議聚焦在調整措辭，但這個例子不同——它展示的是當你在求職期間不斷成長、打磨 projects 後的結果。

若是剛畢業的 Bootcamp 學生，用基本的課程專案很難脫穎而出。但若你在求職期間投入時間改善專案（例如加入測試）、貢獻開源、或在 freelance 平台接案，差距會非常大。

Before：

After：

兩個版本之間發生了什麼？五個月的求職期間他做了這些事：

1. 貢獻熱門開源專案：他從 新手友善清單 ^↗ 篩出 JavaScript 相關的專案，花時間把玩、閱讀過去的 PR，最後做出幾個初步修改。經過多輪來回，學到很多，現在更自信。
2. 把 take-home 挑戰變成完整產品：一個使用 Flickr API 的圖片搜尋 app，雖然當時沒進下一輪，但他把它變成一個具備單元測試、UI 測試、並整合 Flickr、Giphy、Unsplash 的成品。他還花 15 美元買了網域——絕對划算的求職投資。
3. 在 freelance 平台接到一個付費案：與一家保險比價小公司合作。案子很困難、客戶還在殺價。他決定不以獲利為目的，專注交付高品質的成果，事後把截圖與程式碼片段放到作品集頁面。Freelance 案最棒的地方是——真實客戶在使用，而且你不需要透露報酬。
4. 把 coding challenge 的學習整理成公開專案：他在面試遇到資料結構時卡關，於是決定公開練習，實作了多種資料結構並附上測試與整理過的 README。不僅學得更紮實，還多了一個作品可以展示。

我自己當年也做過類似的事——SwiftAlgorithmsAndDataStructures ^↗。GitHub 上也有很多其他語言的版本，例如 JavaScript ^↗ 等。

轉職者（Career Changers）#

當你從其他職業轉入軟體開發時，大部分 Bootcamp 履歷的建議都適用——特別是如果你曾受過 Bootcamp 訓練。但無論是否有 Bootcamp 背景，你都會有許多與軟體開發關聯不大的過去工作經驗。

以下是建議做法：

• 撰寫一段 summary 說明你轉職了，以及動機是什麼。讓招募人員事先理解「這是一位剛進入軟體開發的人」，有助於正確解讀履歷。
• 把語言、projects、作品集放在履歷上方，讓讀者看到你是動手做的工程師。盡量附上可運作的 demo 與原始碼連結。
• 附上可運作的專案與原始碼。因為你缺少多年的科班學歷，必須用專案證明你懂得寫軟體，讓面試不會是浪費時間。可參考 Bootcamp 畢業生的建議加強 projects。
• 過去的工作經驗請精簡描述。一句話概述該職位，並在 bullet point 中聚焦於「可轉換技能」：主動學習、團隊合作、mentoring、公開演講等。
• 履歷要短。盡量維持一頁，不要超過一頁半。你可能很想多寫過去職涯，但招募人員並不在意——他們更想看你的專案與相關經驗。

範例轉職履歷：

這份履歷聚焦在重點資訊：

• 起頭的 summary 說明過往職業背景。
• 接著是語言與 projects，強調技術，這是招募人員最感興趣的部分。
• 工作經驗精簡地以一句描述、一句可轉移技能帶過（例如 led a training initiative、mentoring、coaching）。
• 結尾是教育背景，軟體開發相關的放較多細節。若有相關課程或證照也放這裡。非軟體的大學學歷仍值得列出。

職涯空窗（Career Breaks）#

你可能曾因為主動離職或被資遣，經歷數月甚至數年的全職空窗期。這可能是個人選擇，也可能是當時找不到合適工作。無論原因，履歷上就是有個缺口，該如何處理？

沒有通用解法，但以下是幾個好的方向：

• 數年前的空窗期不需要解釋。招募人員通常不會在意 4、5 年以前的空窗。即使在意，也會在電話篩選時再問，不會影響書面階段。不要浪費版面解釋。
• 近期但未延續到現在的空窗，視情況補充。如果空窗後你已有新工作，那段空窗的重要性就低得多，但仍可視情況補充說明。
• 近期並延續到現在的空窗——請主動說故事。當你尚未回到全職工作時，就由你主導敘事。履歷上寫的，應該和你在面試中被問到時的答案差不多。

以下是幾個清楚易懂的空窗敘事範例：

空窗期並非科技業獨有，因此相關建議也通用。Monster UK 的文章 ^↗ 提供了幾個實用範例：

• 旅行：「我完成了到南美洲旅遊六個月的夢想，期間精進西班牙文並接觸不同文化。」
• 尋找新方向：「我休息一段時間專注於繪畫，並利用這段時間找到符合個人目標的新職涯方向。」
• 生病：「我因長期病痛休假，但這段時間讓我完全康復，並在一家當地慈善商店擔任志工，逐漸重回職場步調。」
• 照顧家人：「我為了照顧兄弟而暫停工作，他現在已完全康復。」

為了學習的空窗期（Study Related Career Breaks）#

如果空窗是為了學新技術或語言，建議把它寫成類似一段工作經驗，並附上你已經掌握該技能的證據。上線運作的作品永遠比「完成一堂課」更有說服力。請用 results and impact 框架量化你所做專案的難度或有趣之處。

多數人會在學習後產出作品集 (portfolio) 專案，但這類專案很普遍，而且「只有你自己用」並不能強烈證明你在職場上的能力。若想脫穎而出，請做得更多：上線 production 作品、撰寫文章或 mentor 他人、對使用相同技術的開源專案做貢獻。

上面的例子雖然看起來還好，但招募人員通常更看重「工作經驗」而非「全職學習」。若你正在以空窗學習為目的，不妨找一個使用新技術的 freelance 案子——即使免費或低報酬也值得——這樣你就能把這段經歷改寫為 freelance 經驗，而非空窗。

「Freelance」這個詞代表你是能在 production 環境交付成果的專家，比「自學」更能展現工作級的技術能力。若你找不到 freelance 案，可以免費或低價幫朋友、小型企業主寫一個會上線的功能。

改寫後的版本會更有說服力：

資深以上工程師（Senior and Above Engineers）#

越資深的工程師，履歷越容易靠經驗與職稱脫穎而出。依你申請的公司類型，可參考以下建議。

若你的職稱已是 senior 但年資僅幾年，有些公司會看重年資更甚於職稱。若你被升遷過，請在履歷上凸顯這段升遷歷程，並清楚描述 results and impact，讓讀者理解你交付的成果。

當你有 8–10 年以上經驗時，你很可能與多種技術打過交道，挑戰在於「如何讓履歷貼近當前應徵的職缺」。

• 加入 summary 段落，針對該職位量身打造。你資歷足夠，招募人員與主管都會想了解你的動機與能帶來的價值。
• 除了業務成果，也提及「軟性」成就：mentor junior、leading teams 等。許多公司期待資深工程師不只會自己做事，還能幫助身邊的人。
• 不只提 impact，也提 influence。越資深越被期待要能影響更多人——例如 Facebook、Google 的 staff 工程師被期待要能影響多個團隊。
• 把 Education 區塊移到第二頁。你已有充足的工作經驗可填滿第一頁；把學歷移到後頁也能降低年齡偏見 (age bias)。
• Education 只保留突出細節：學校名、學位、日期，一到兩行就夠。只留下 summa cum laude、滿 GPA、相關專長等亮點。
• 早期經歷要更精簡：越久遠的經歷越不相關，比例上應占更少空間。

有充足相關經驗時，也可以考慮繞過官方申請管道。直接在 LinkedIn 找到招募人員或招募主管並私訊詢問。資深職位的決策者比較可能回覆，有了聯絡點後也更方便追蹤進度。

Tech Leads#

Tech Lead 常以 technical team lead、team lead 或 technical delivery lead 等名稱出現。和 senior engineer 不同的是，Tech Lead 角色較少著重在技術貢獻，而是偏重交付 (delivery) 與團隊領導。Engineering Manager 通常負責多個團隊，而 Tech Lead 只聚焦一個團隊。有些公司會以 Engineering Manager 職稱招募 “Tech Lead EM” 原型，可參考 Patrick Kua 的文章 5 Engineering Manager Archetypes ^↗。

申請 Tech Lead 時：

• 展現你如何幫助團隊，超越 senior engineer 的範疇。招募主管要解決的問題不一樣：可能是團隊交付落後、流動率高、品質堪憂——而這些不是加人寫程式就能解決的。你是否加速了交付？提升了品質？修復了利害關係人的關係？請清楚寫出。
• 舉例說明你如何讓團隊成功。要讓證據清楚可見。
• 提供具體的情境背景。招募人員會想了解團隊規模與組成（例如 2 名前端、2 名後端、1 名測試工程師）、外部背景（「屬於 50 人的大團隊…」）、以及重大技術選型。
• 結果與行動並陳。不只是「我主持每日 scrum」，而是「團隊是否準時交付？」請在履歷中加入 delivery 的佐證（「管理團隊準時且符合預算交付專案 x」）、團隊領導（「coached 與 mentored 兩位 graduate，後來都成為 senior engineer」）、以及技術領導（「與架構團隊合作交付核心元件 x」）。

Tech Lead 職缺相對較少。若你也想同時應徵 senior engineer 或 engineering manager 職位，建議準備各自對應的履歷，強調不同路線的相關經驗。

Engineering Managers#

應徵 Engineering Manager 時，公司通常預期你先前已有 EM、Tech Lead 或類似職位。假設你有，以下建議能協助你撰寫履歷。

• 說一個故事。EM 必須是好的 storyteller，履歷應該展現這點。講述你如何讓團隊變得更好、取得了哪些成就、以及加入後能帶給組織什麼。
• 熟悉公司的價值觀。EM 從來不是真空中的招募，而是為了讓某個團隊再上一層樓。請研究該組織的文化，思考哪些價值你本身已經體現，並在描述過去成就時呼應這些價值。
• 撰寫強而有力且切題的 summary。對 EM 而言，summary 就是你的 cover letter。仔細打造、為該職位量身定做，避免 buzzwords 與過度通用的描述。
• 適配度是雙向的——不要勉強。當 senior engineer 通常比 EM 更容易上岸，因為每個團隊都在找特定的 EM 適配度。你可能想調整履歷以「看起來很符合」，但請深思：你真正的目標是「進入那些能讓你發揮長處的對話」。因此清楚定義自己在什麼環境下能做出最佳成果非常重要。
• 成就不只談業務，也談團隊。交付有影響力的專案、達成 OKR、帶跨團隊計劃都很棒——但你的團隊呢？你如何支持人們？你協助誰升遷？你有招募到多元背景的人才嗎？你的離職率是否低？你有在團隊外擔任 mentor 嗎？人才是 engineering management 的核心，請描繪完整的樣貌。
• 從他人的 LinkedIn 尋找靈感。好的 EM 履歷資源很少，瀏覽同行的 LinkedIn profile 是很好的靈感來源。
• 直接與招募主管聊聊。EM 職位比一般 dev 職位更容易取得與招募人員或招募主管的初步對話。考慮在正式申請前先主動聯繫。

Neville Kuyt ^↗ 擁有超過二十年的團隊領導經驗，他額外的建議：

• summary 要鎖定特定 niche，並在工作經驗區塊中用事實佐證。許多 summary 充滿 buzzwords，通用到彷彿誰都適用——請反其道而行。
• 描述你最擅長解決的挑戰類型。回想你最成功的經歷是來自哪類型的問題，把它寫進 summary，再用工作經歷佐證。
• 鎖定對的公司類型。你是在大組織裡推動對齊的人？還是新創裡動手做的人？把履歷投向你已經或能夠勝任的位置。

多尋求 feedback。如果你有 EM 同儕或朋友，請他們幫你看履歷。EM 也可以在 Rands Leadership Slack ^↗ 的 #vet-my-resume 頻道獲得回饋。建議早點加入社群並參與其他討論，別等到要求職時才加入。