本章是寫給現任與未來招聘主管 (hiring manager) 的。我知道大多數讀者目前還不是主管，但有一天你可能成為 tech lead 或 manager，有機會參與甚至設計招聘流程。到那時，你可能早已忘記當年要踏進門有多困難、擁有一份強勢履歷有多重要。

作為招聘主管，請投入時間與精力打造更好、更公平的篩選流程。

我看過太多招聘主管以為自己跟履歷篩選無關，不清楚招聘人員是如何過濾履歷的，最後優秀候選人連電話面試機會都沒就被淘汰——因為主管沒有提供支援。別成為這種人。

認清你的篩選流程是有問題的#

讀過這本書並套用建議的人，求職會更順利，也會通過更多履歷篩選。有些人會成為你的好員工——但若他們的履歷寫不好，你或你的招聘人員可能就錯過了。

在《Smart and Gets Things Done ↗》一書中，Joel Spolsky 說：

「標準的求職申請——一封 cover letter 加一份 resume——是介紹候選人的一種極其薄弱的方式。它只給你一點點關於候選人品質的線索。有時候履歷能強烈暗示這個人品質不佳 (…) 除此之外，從履歷上看出一個人是很困難的。」

只要你有履歷篩選制度，就會不可避免地拒絕掉好的候選人——除非你放寬或取消履歷篩選。

然而，履歷篩選之所以存在是有理由的：它能過濾掉看起來不適合的應徵者，減輕負擔。在進行篩選時，請有意識地把履歷分到「Yes」、「Maybe」、「No」三堆中。Johanna Rothman 在《Hiring Geeks That Fit ↗》中解釋：

「因為我主要是為無法在履歷上適當呈現自己的技術人才做招聘，所以我會用懷疑從寬的原則閱讀履歷——這會讓我得到一堆 Maybe 履歷。在 Yes 候選人被電話面試完、職缺仍未填補時，我會再讀一次 Maybe，看看是否錯過了什麼璞玉。」

替代履歷篩選的方案#

這個觀察正是催生多家新創採用「評估型 (assessment-based) 第一輪篩選」取代履歷篩選的原因：

即使沒有額外預算，也應該這麼做#

  • 至少讓另一人一起篩選履歷，獨立評估同一批。比對兩人的 Yes 名單重疊度，既可以校準期望值、也能降低偏見
  • 為招聘活動預留專屬時間。若你沒時間處理招聘，結果就會草率
  • 依職缺數量與重要性分配時間。即將擴編一倍跟招一位 junior 完全不是同等投入
  • 意識到自己的文化偏見：你很可能有 self-selection bias ↗，下意識偏好跟自己相似的人。承認它，並刻意挑選背景與你不同的人選

把招聘視為夥伴部門#

與招聘團隊建立緊密關係#

  • 把招聘人員視為真正的夥伴。從開始招聘那天就跟他們坐下來，了解他們如何在不同階段處理候選人
  • 說明你要的人才特質與成功條件
  • 定期交流

若你不主動聯絡，HR/招聘部門可能會以為你不想參與。每當我看到主管與 HR 各自為政時，總覺得是巨大的浪費。

賦權招聘人員#

  • 讓招聘人員敢帶來不尋常的候選人進入技術面試
  • 不要死守「5 年 Java 經驗 + 2 年 JavaScript」這種條件
  • 給出合理指引，並鼓勵他們帶進自己覺得有亮點的人

動手審閱履歷#

  • 最好的主管會親自與招聘團隊一起審閱履歷
  • 主管往往能從寫得不好但有好 GitHub 或專案連結的履歷中讀出潛力
  • 即使不是全職投入，也花時間翻翻被拒絕的履歷

從內部視角看：不符合標準條件的優秀招聘

Brandwatch 工程副總 James Stanier 分享：「我曾經錄用一個人，他有一年空窗期是因為擔任半職業低音吉他手在跟樂團巡演。一開始有人看不上這個經歷，但那其實超酷！他是很棒的工程師。」

曾任 Google、Facebook、Uber 技術招聘的 Blake Stockman 也分享過一個案例：有個人連續數週寫信給整個招聘團隊要求面試實習機會。最後他讓步答應通話，結果發現這是個非常熱忱、極度渴望機會的人。他被納入面試流程，表現令人驚艷，後來轉正職，至今還在公司。

「瘋狂的是，幾乎所有招聘人員看到他的履歷都會直接拒絕，他的背景完全沒有亮點。但因為熱忱、渴望、謙虛、願意學習與堅持，他獲得了這個機會。」

我自己也有類似故事：一位我最尊敬的工程主管沒有 CS 學位、完全自學；一位兩年前還在送披薩的工程師，我們原本傾向不錄取，結果他成為頂尖人才；一位只有 iOS 經驗但願意學的人被我錄取做 Android，表現出色。而我自己當年也是在沒有 iOS 全職經驗的情況下被 Skyscanner 錄取做 iOS——我只有 Windows Phone 經驗。

寫好職缺描述#

  • 親自參與職缺描述的撰寫與迭代，別只是複製貼上現有的
  • 挑戰自己：這個職位真正需要什麼？
    • 這個人第一個月與第一年要做什麼？
    • 哪些技能與經驗絕對不可妥協？哪些可以上工後再學？

例如：若要招募 Node.js 廣告團隊的 tech lead，「曾帶過小團隊」是必要的，但「廣告產業背景」可能不是；語言/框架甚至可能可議——前提是找到學得快、有後端經驗、動機強的人。

避免偏見與性別化用詞#

若職缺描述使用偏男性化的用語，你會自動少掉許多女性應徵者。Accenture 在英國改寫職缺描述後，女性應徵比例從 34% 提升到 50% (根據 HR Magazine 文章 ↗)。

可以使用 Kat Matfield 的 Gender decoder for job ads ↗ 等工具，也可以參考如 Honeycomb.io 的工程主管職缺 ↗ 這類寫得很好的範例。

建立回饋迴圈#

監控招聘管線#

  • 追蹤數字也關注數字背後的故事：每個階段的通過率如何？隨時間變化嗎？
  • 監控管線的多元性：多元團隊能帶來更好的成果。候選人多元嗎？能通過履歷篩選嗎？沒有資料就無法改善

舉辦回顧 (Retrospective)#

  • 定期與招聘人員討論：回覆率？內推情況？最令人興奮的候選人？面試回饋？
  • 成功與失敗的 onsite 後都做簡短回顧
  • 當某人未被錄取時，反思是否有事前指標能預測；是否因為某個沒寫在職缺上的潛規則？

建立清楚的回饋政策#

  • 履歷階段被拒要如何處理？電話面試後呢？
  • 與招聘團隊確認回饋流程，兼顧法律與公司限制
  • 理想上每份履歷都該有誠實回饋，但現實通常不可行。至少確保候選人體驗一致

從內部視角看：BusyManager 與 MakeTimeManager 的故事

我曾觀察兩位主管在一年內與招聘人員的合作狀況，結果極其不同。

BusyManager 很忙，幾乎沒時間招聘。他獲得大量 headcount，直接把任務丟給招聘團隊自行處理。他只寫了簡短職缺描述。當他終於有空關心時，進度完全停滯。他向招聘施壓要成果，但招聘團隊帶來的候選人全被他拒絕。換了幾個招聘人員也沒用。

MakeTimeManager 一開始 headcount 少，但他希望好好招聘。他設立每週固定會議，表明招聘優先，隨時歡迎打擾。他也這麼做了——親自參與流程的每個環節，要求團隊在面試上全力以赴。

MakeTimeManager 迅速而成功地完成招聘，獲得更多 headcount。BusyManager 大幅未達標。兩人使用完全相同的招聘團隊。

差別在於 MakeTimeManager 把招聘視為合作夥伴關係。當你在招聘時，請成為 MakeTimeManager，並在發現自己變得像 BusyManager 時立刻警覺。

從別人身上學習#

本書不是一本關於「如何好好招聘開發者」的書，但以下幾本書涵蓋得很詳盡，值得一讀：

  • 《Smart and Gets Things Done ↗》by Joel Spolsky
    • 簡潔、有主見、實用的開發者招聘指南。雖然 2007 年出版，但大部分內容至今仍適用
  • 《Hiring Geeks that Fit ↗》by Johanna Rothman
    • 第一次招聘或尚未有完整招聘策略時的必讀。從策略定義、職位分析、面試規劃到 reference check 與 offer 流程都有涵蓋
Backward Chapter 12: Resume Improvement Examples Conclusion Forward