作者：四火
來源：https://www.raychase.net/4868
網際網路公司招聘是很重要的環節，網際網路公司離職率普遍較高，傳統企業離職率較低，所以對於公司招聘是很重要的環節，同樣一句「很重要」我看到許多人理解其程度實際上大相逕庭。在很多網際網路公司，招聘被視為「最重要」的事情。這是令許多人不理解，甚至覺得不可思議的事情 ，這裡的「許多人」也包括曾經的我。公司不開展業務嗎？不管理員工嗎？不和了解客戶需求嗎？這些事情哪個不比招聘重要呢？
中午吃飯的時候，同事老兔和我算了這麼一筆帳。估算非常之粗略，請勿以之作為任何有效依據，但是從大略上足以窺其端倪。
1、假如一個勤奮的中級程式設計師工程師，一年薪水 20w 的話，一年 365 天，大約有 52 周，扣掉雙休日還有 365-52x2 = 261 天，加上法定假大概 10 天，休假大約 3 周，還有亂七八糟的病假、事假大約 10 天，也就是說，工作的時間只有 261-10-3x7-10=221 天，平均每個工作日的薪水是 200k/221≈905元，那麼按照多數人朝九晚五且扣除一小時午休等原因的一小時以後，每天工作 7 小時，時薪大約是905/7=129元。
2、另一方面，考慮 Google、FB、Microsoft、Amazon 之類的知名網際網路公司，粗略地如下假定：onsite 都要經過 5 輪左右的面試，每輪大約 1 小時，外加最少 1 小時左右的電話面試（有些電話面試要兩輪），而且電話面試的錄取比例大概是 1/3，所以每一個 onsite 認為綁定了三輪電話面試，debrief meeting 討論面試情況半小時，以及面試官的面試準備，和面試完畢後 report 的撰寫半小時後，那麼光是工程師就要投入 5+3x1+0.5+0.5=9 小時，按照時薪算就要耽誤掉129元*9=1161元，再加上 HR 和 recruiter 等其他人的工作投入，場地費、有時會有的餐旅費等等，onsite 一個人的成本平均在1300元往上。
3、即便這樣的投入後，多數結果當然都是沒有錄用的，即便給了 offer，還有多家公司在 offer 上的競爭。很多公司的 onsite 的錄取率都在 40% 左右，而最終入職率的百分比就要掉到 20% 以下。所以這個數還需要調整：1300/0.2 = 6500。花了那麼多錢，才能錄用一個工程師。
這個計算已經觸目驚心了，招人的成本看起來是非常巨大的，而事實上，這個數會更大。考慮其他的開銷，它就更扎眼了。比如和招聘機構合作的年費，比如招聘校園行宣講的費用，所以，就如同我一位老朋友程式設計師所說，「工程師是很貴的」。
可是，我要說的是，這只是「小錢」。
什麼！？
為什麼？
因為對於許多網際網路公司來說， 招聘這個環節，和後面的環節比起來，性價比太高了，投入相對更值得 。在招聘上省錢，很有可能，會讓之後的團隊運作付出多得多的代價，還不一定能識別並挽回造成的損失。
也許你會猜，我大概會舉招聘的 bar 太低，入職員工技術能力不足，拖累團隊的例子。誠然，這樣的例子很典型、很普遍，但是這方面絕大多數團隊和招聘流程都會關注，並無新意可言。而且，對於一個技術或者業務能力不足的人，無論在決策還是實現層面，由於缺少技術或者業務影響力，往往造成的負面影響比較有限 ，換言之，更可怕的人，可能是技術或者業務足夠強，但是種種原因不契合團隊，嚴重影響工作輸出的那些，而這，足以帶來超出想像的破壞力。
經歷過這樣一個例子：
有一位黑客界的牛人，費了九牛二虎之力把他招到團隊，結果入職以後工作能力並不達標，或者說，並不契合他所擅長的內容和方式，結果搞出一大堆問題不說，deliver 也不合格，同事不得不跟在他後面給他收拾殘局，給他的代碼修 bug、打補丁，他本人更是非常痛苦。最後他自己和公司雙方都選擇「解脫」，他入職不到半年就離職了。
其實這個問題就出在招聘，他至少在某些方面得到過業界的證明，他擁有頂尖的某些能力。可是無論是工作方法上，還是嚮往的工作內容和團隊的契合程度，都不符合要求。
一個團隊的包容力固然重要，可它依然是有限的。太多的雞湯文推崇招募牛人，可隨便什麼牛人放到一起工作就可以做得很好，這只是一廂情願，它只在書本上出現 。
再比如這個更可怕的例子：
有一種可怕的開會，特別是那些十幾個人的團隊，一開就是一個小時的會議，結果變成了神仙大會，扯的東西看似工作相關，實則都是一些遙遠而不甚關聯的話題。每一次開會就是十幾個小時工時的浪費。按照上面粗略的時薪計算，開銷可觀。
什麼情況下會這樣？
招來不幹實事，卻口若懸河的人。更可怕的是這樣的人混成了團隊骨幹。於是帶著一幫人天天在會議上侃大山。
招聘就是這樣，招得好，公司和團隊長期受益，招得不好，長期危害。
於是有人說，招聘小投入，等到入職以後再來衡量績效不就好了嗎？績效不好就裁掉，或者其它方式中止合同。經歷實戰才能出英雄，不是嗎？
理兒是這個理兒，可這個邏輯存在幾個致命傷：
入職後的績效衡量，等到得到結果的時候，羊已亡，無論補牢是否已晚。有很多後果是很難彌補的。這個績效衡量，又怎樣保證儘可能客觀而有效？一個「最能混」的工程師，也許能夠有十種百種奇葩的辦法拿到好的績效，卻沒有為團隊帶來真正等效的價值。這裡還忽視了中止合同的代價 。雖說合同都是 at will 的，法律上上午說離職，下午就可以滾蛋的。除非涉及種族歧視等法律底線，極少有公司這樣做，如果因為績效原因，通常這樣的合同終止，公司都會給員工以數個月的補救或緩衝時間。原因很簡單，一個習慣於中止合同的公司，名聲就臭了，誰還願意來？
……
更重要的，也是我要提醒的是，我們不能總把眼光放在「不損害團隊利益」這樣低層次的層面，而應該盯著怎樣提升團隊能力這個層面。
招聘就像是唯一的一個損失極小的影響產品方方面面的環節，如果不努力招聘更好的人，怎樣要求最後發布的產品變得更好？
這也是 Amazon 最初定下的，要求招的人，「比團隊中 50% 以上的人更好」這個說辭的由來。
若說起招聘環節在整個公司運作中的位置，它其實和軟體工程里的項目流程同理，越早發現 bug 代價越小 。
從招聘，到入職，到團隊建設，到項目輸出，整個流程下來，總要在一個環節上面付出很大的代價。如果招聘做不好，那麼倒霉的就是後面的環節。這也像軟體工程的項目流程一樣，如果設計做不好，那麼糟糕的設計帶來糟糕的版本質量，就要靠大量的測試來彌補，多數還補不過來；而如果測試也草草了事，那就要靠瘋狂的 bug fixing 和打 patch 來彌補，還幾乎肯定會造成大得多的後果。越往後，代價越大，效果也越差。
因此，把問題解決得越早越好。把工程質量這個 bar 抬高，抬得越早越好，不如就從篩選工程師開始。
招聘到的工程師不只是優秀，還符合團隊需要，那麼在後面的流程中，就可以減少很多投入。比如，不需要花錢請人監督工程師的工作，因為工程師又自我鞭策的能力；比如，不需要大量的團隊建設活動，因為工作態度和方法上彼此都有大致相似的觀點；再比如，不需要招許多測試來保證質量，因為良好的設計和實現階段的開發期測試已經足夠好；比如，不需要再維護優化環節投入很多專職人員，是因為良好的穩定性、易用性和可擴展性配合好用的工具使得開發團隊自身就可以搞定這些事情。
最後，回到招聘本身。面試是雙向的，一個草草了事的招聘幾乎意味著一家草草了事的公司。想知道未來的團隊氛圍是不是適合自己，那麼看看是不是和面試的人聊得來；想知道公司的技術實力如何，那就看看招聘過程反映出來的技術怎樣；想知道入職以後身邊的人會不會優秀而且契合，那就看看來面試你的面試官是不是優秀，招聘是不是嚴格且謹慎吧。