爲何互聯網公司每天都在招人？

互聯網公司招聘是很重要的環節，互聯網公司離職率廣泛較高，傳統企業離職率較低，因此對於公司招聘是很重要的環節，一樣一句「很重要」我看到許多人理解其程度實際上截然不同。在不少互聯網公司，招聘被視爲「最重要」的事情。這是令許多人不理解，甚至以爲難以想象的事情 ，這裏的「許多人」也包括曾經的我。公司不開展業務嗎？無論理員工嗎？不和了解客戶需求嗎？這些事情哪一個不比招聘重要呢？

中午吃飯的時候，同事老兔和我算了這麼一筆帳。估算很是之粗略，請勿以之做爲任何有效依據，可是從大略上足以窺其端倪。

**一、**假如一個勤奮的中級程序員工程師，一年薪水 20w 的話，一年 365 天，大約有 52 周，扣掉雙休日還有 365-52x2 = 261 天，加上法定假大概 10 天，休假大約 3 周，還有亂七八糟的病假、事假大約 10 天，也就是說，工做的時間只有 261-10-3x7-10=221 天，平均每一個工做日的薪水是 200k/221≈905元，那麼按照多數人朝九晚五且扣除一小時午休等緣由的一小時之後，天天工做 7 小時，時薪大約是905/7=129元。

**二、**另外一方面，考慮 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元往上。

**三、**即使這樣的投入後，多數結果固然都是沒有錄用的，即使給了 offer，還有多家公司在 offer 上的競爭。不少公司的 onsite 的錄取率都在 40% 左右，而最終入職率的百分比就要掉到 20% 如下。因此這個數還須要調整：1300/0.2 = 6500。花了那麼多錢，才能錄用一個工程師。 這個計算已經觸目驚心了，招人的成本看起來是很是巨大的，而事實上，這個數會更大。考慮其餘的開銷，它就更扎眼了。好比和招聘機構合做的年費，好比招聘校園行宣講的費用，因此，就如同我一位老朋友程序員所說，「工程師是很貴的」。

但是，我要說的是，這只是「小錢」。

什麼！？

爲何？

由於對於許多互聯網公司來講， 招聘這個環節，和後面的環節比起來，性價比過高了，投入相對更值得 。在招聘上省錢，頗有可能，會讓以後的團隊運做付出多得多的代價，還不必定能識別並挽回形成的損失。

也許你會猜，我大概會舉招聘的 bar 過低，入職員工技術能力不足，拖累團隊的例子。誠然，這樣的例子很典型、很廣泛，可是這方面絕大多數團隊和招聘流程都會關注，並沒有新意可言。並且，對於一個技術或者業務能力不足的人，不管在決策仍是實現層面，因爲缺乏技術或者業務影響力，每每形成的負面影響比較有限 ，換言之，更可怕的人，多是技術或者業務足夠強，可是種種緣由不契合團隊，嚴重影響工做輸出的那些，而這，足以帶來超出想象的破壞力。

經歷過這樣一個例子： 有一位黑客界的牛人，費了九牛二虎之力把他招到團隊，結果入職之後工做能力並不達標，或者說，並不契合他所擅長的內容和方式，結果搞出一大堆問題不說，deliver 也不合格，同事不得不跟在他後面給他收拾殘局，給他的代碼修 bug、打補丁，他本人更是很是痛苦。最後他本身和公司雙方都選擇「解脫」，他入職不到半年就離職了。

其實這個問題就出在招聘，他至少在某些方面獲得過業界的證實，他擁有頂尖的某些能力。但是不管是工做方法上，仍是嚮往的工做內容和團隊的契合程度，都不符合要求。

一個團隊的包容力當然重要，可它依然是有限的。太多的雞湯文推崇招募牛人，可隨便什麼牛人放到一塊兒工做就能夠作得很好，這只是一廂情願，它只在書本上出現 。

再好比這個更可怕的例子： 有一種可怕的開會，特別是那些十幾我的的團隊，一開就是一個小時的會議，結果變成了神仙大會，扯的東西看似工做相關，實則都是一些遙遠而不甚關聯的話題。每一次開會就是十幾個小時工時的浪費。按照上面粗略的時薪計算，開銷可觀。

什麼狀況下會這樣？

招來不幹實事，卻滔滔不絕的人。更可怕的是這樣的人混成了團隊骨幹。因而帶着一幫人每天在會議上侃大山。

招聘就是這樣，招得好，公司和團隊長期受益，招得很差，長期危害。

因而有人說，招聘小投入，等到入職之後再來衡量績效不就行了嗎？績效很差就裁掉，或者其它方式停止合同。經歷實戰才能出英雄，不是嗎？

理兒是這個理兒，可這個邏輯存在幾個致命傷： 入職後的績效衡量，等到獲得結果的時候，羊已亡，不管補牢是否已晚。有不少後果是很難彌補的。這個績效衡量，又怎樣保證儘量客觀而有效？一個「最能混」的工程師，也許可以有十種百種奇葩的辦法拿到好的績效，卻沒有爲團隊帶來真正等效的價值。這裏還忽視了停止合同的代價 。雖然說合同都是 at will 的，法律上上午說離職，下午就能夠滾蛋的。除非涉及種族歧視等法律底線，極少有公司這樣作，若是由於績效緣由，一般這樣的合同終止，公司都會給員工以數個月的補救或緩衝時間。緣由很簡單，一個習慣於停止合同的公司，名聲就臭了，誰還願意來？

…… 更重要的，也是我要提醒的是，咱們不能總把眼光放在「不損害團隊利益」這樣低層次的層面，而應該盯着怎樣提高團隊能力這個層面。

招聘就像是惟一的一個損失極小的影響產品方方面面的環節，若是不努力招聘更好的人，怎樣要求最後發佈的產品變得更好？

這也是 Amazon 最初定下的，要求招的人，「比團隊中 50% 以上的人更好」這個說辭的由來。

若提及招聘環節在整個公司運做中的位置，它其實和軟件工程裏的項目流程同理，越早發現 bug 代價越小 。

從招聘，到入職，到團隊建設，到項目輸出，整個流程下來，總要在一個環節上面付出很大的代價。若是招聘作很差，那麼倒黴的就是後面的環節。這也像軟件工程的項目流程同樣，若是設計作很差，那麼糟糕的設計帶來糟糕的版本質量，就要靠大量的測試來彌補，多數還補不過來；而若是測試也草草了事，那就要靠瘋狂的 bug fixing 和打 patch 來彌補，還幾乎確定會形成大得多的後果。越日後，代價越大，效果也越差。

所以，把問題解決得越早越好。把工程質量這個 bar 擡高，擡得越早越好，不如就從篩選工程師開始。

**招聘到的工程師不僅是優秀，還符合團隊須要，那麼在後面的流程中，就能夠減小不少投入。**好比，不須要花錢請人監督工程師的工做，由於工程師又自我鞭策的能力；好比，不須要大量的團隊建設活動，由於工做態度和方法上彼此都有大體類似的觀點；再好比，不須要招許多測試來保證質量，由於良好的設計和實現階段的開發期測試已經足夠好；好比，不須要再維護優化環節投入不少專職人員，是由於良好的穩定性、易用性和可擴展性配合好用的工具使得開發團隊自身就能夠搞定這些事情。

最後，回到招聘自己。面試是雙向的，一個草草了事的招聘幾乎意味着一家草草了事的公司。想知道將來的團隊氛圍是否是適合本身，那麼看看是否是和麪試的人聊得來；想知道公司的技術實力如何，那就看看招聘過程反映出來的技術怎樣；想知道入職之後身邊的人會不會優秀並且契合，那就看看來面試你的面試官是否是優秀，招聘是否是嚴格且謹慎吧。

原文：http://www.raychase.net/4868 做者：四火