程式設計師：假如你重新面試你現在的工作崗位，通過率有多大？

面試這件事有難度，但我想只要遵循一套縝密的流程，那麼許多問題都會迎刃而解。

 

大多數的面試過程主要包括兩步：

簡歷篩選

面試

對求職者的篩選就是為了提前淘汰一些求職申請者，節省面試工作的時間。通常篩選過程包括：招聘官大體瀏覽求職申請者的簡歷（大概用時 10 秒以內），然後進行 30~60 分鐘的電話面試。我們的合作方公司中有 18% 的公司為了考驗求職者，也會出程式設計題讓他們回家完成（要麼代替電話面試，要麼作為電話面試以外的附加題）。有意思的是，絕大多數的求職申請者都是在篩選這一關被拒的。真是這樣，我們合作的所有公司中，單純因為簡歷就被篩掉的求職申請者已超過了 50%，另外有 30% 因為電話面試/帶回家的專案完成不佳而被刷掉。篩選也是聘用過程最變化無常捉摸不定的環節，應聘者太多，導致招聘人員應接不暇，只能做出倉促的決定，因此這時候求職者的文憑資歷和專業匹配度就派上了用場。

終面幾乎普遍都是由一系列 45 分鐘到 1 小時的會談組成，每次會談的面試官都不一樣，會談主要考技術題（每個公司外加一兩個針對文化適應和軟技能的問題）。招聘經理和每個面試官會在求職申請者離開後，在決策會議上做出他們最終錄用/淘汰的決定。在至少有一人力挺，且沒人強烈反對的情況下，一個求職申請者才可能被錄用。

終面除了常見的形式之外，還有各種千變萬化的型別。

有 39%  會使用白板面試。

有 52% 允許求職者使用他們自己的電腦作答（剩下的 9% 視情況而定）。

有 55% 讓面試官隨意提問（剩下的 45% 採用一套標準面試題）。

有 40% 要考察求職者的 CS 學術技能後，才能確定去或留。

有 15% 不喜歡 CS 學術技能（而且覺得探討電腦科學只能暴露該求職者生產力低）。

有 80% 允許求職申請者在面試時使用任何程式語言（剩下的20%要求他們使用特定程式語言）。

有 5% 會在面試過程中直白地評價求職者程式語言的細節。

終面後決定錄用的佔 22%，其中大概 65% 會接受 offer（達成僱傭關係）。一年後，公司對錄用了 30%、開除率 5% 的情況非常滿意。

 

漏招 VS 誤招

所以，現在的面試存在什麼問題呢？畢竟開除員工的頻率並非是不可控的。為了更清楚地看待這個問題，我們需要考慮導致面試失敗的兩種情況：

面試了一個不合格的工程師，卻將其聘用，過後只好開除（誤招）；

面試了一個工作能力很強的工程師，卻認為他不合格，選擇不予聘用（漏招）。

誤招一眼就能看出來，公司會（在薪水、管理成本和全團隊的精神面貌上）付出很大代價，會把一個團隊搞得萎靡不振。而與之對比，漏招的損失卻看不出來。雖然以上任意一種情況都很有問題，但由於這誤招和漏招引發的後果乍一看很不平衡，所以公司的面試很大程度上傾向於不予聘用。

面試中存在的干擾會使公司不予聘用的傾向更加嚴重。在一小時內評估一個人的程式設計能力本來就是很難的，各種條件經歷的匹配、某些直覺感受和以上談到的公司的複雜喜好等因素摻雜進來，使得你在面試別人時被各種干擾團團圍困。

為了在受干擾環境下把誤招率控制在一個較低的水平，公司在招聘時越來越偏向於不予聘用。這樣會錯過優秀的工程師，會使文憑的重要程度高過實力，也會由於反覆無常，使參與其中的人（面試官和求職者等）感到失望。假使你公司中的每個員工為了爭取他們當前的職位都得重新參加面試，那麼通過率能有多大呢？這個問題很駭人，幾乎可以確定他們不可能都被錄取。求職申請人會因為本有能力為公司好好效力卻沒被錄用而神傷，公司也會因為找不到可用之才而遭受損失。

要澄清一點，我不是說公司應該降低面試的門檻，相反，面試招人正因為會有拒絕才存在的意義！我更不是說公司對誤招的擔憂遠大過漏招是不對的，招錯人要付出高昂代價，我想說的是：各種干擾訊號的影響外加之對於誤招的防範，會導致面試的漏招率大大攀升，導致人才流失。為解決這一問題，就需要改善面試環境。

 

減少面試中干擾因素的具體方法

1.決定你想要招聘哪方面的技術人才

一個程式設計師不可能因為具備了哪一套技能就能被定義為優秀的程式設計師了，相反，世上的程式設計技能多得猶如汪洋大海，沒有工程師能在所有的領域都遊刃有餘。實際上，我們在 Triplebyte上碰到過一些傑出、成功的軟體工程師，他們在幾個毫不相關的領域都頗有建樹。面試成功的第一步就是決定你想要招聘哪方面的技術人才。我建議你問自己以下幾個問題：

你想要的程式設計師是效率高，但寫的程式碼不完善需反覆修改的，還是一絲不苟、思維嚴密的？

你想要的程式設計師是熱衷於解決技術難題的還是構建產品的？

你想要已經具備某種特定技能的人才還是在工作中有很強的學習能力的？

電腦科學學術/數學/演算法方面的能力是至關重要的還是無關緊要的？

瞭解併發/ C記憶體模型/ HTTP 很重要嗎？

這些問題沒有正確答案，我們合作的成功企業對以上每個問題選任一方的都有。但關鍵是要根據自己的需求有針對性地做出選擇，應該避免隨便向求職者拋個面試問題了事（或者讓每個面試官決定）。這樣的話，公司的工程文化就會有一定傾向：淘汰掉越來越多雖然有一技之長但是對公司並沒太大用處的、以及不具備公司所需技能（卻具備其他重要技能）的工程師。

2.問儘可能和實際工作相貼切的問題

專業程式設計師的任務是花數週數月的時間解決大型的、錯雜延展的問題，但是面試官並沒有數週數月的時間去評估求職申請者的能力，通常每個面試官只有一個小時去考核，所以他們會轉而去考察求職申請者在強壓下迅速解決小問題的能力。這是兩種不同的能力測試。二者有一定的相關性（面試並不完全隨機），但並不是完全相關。制定面試問題的一大目標就是減少面試考察和實際工作的差異。

方法是在面試時向申請某一職位的求職者（或者為了衡量某一技能）問儘可能相似的問題。比如說，如果你關心後端程式設計，那就讓求職申請者建一個簡單的 API 端點，再新增特性，幾乎可以肯定，這比讓他們解決一個 BFS 詞鏈問題有意義得多；如果你關心演算法能力，那讓求職者在問題中運用演算法（比方說，建一個簡單的搜尋索引，可能使用 BST 和 hashmap，實現提升刪除操作的效能），幾乎可以肯定，這比讓他們確定一點是否包含在一個凹多邊形中有意義得多；讓求職者在實際程式設計過程中去嘗試除錯程式，幾乎可以肯定，這比讓他們去解決一個白板上的小問題有意義得多。

即便如此，面試中要不要讓程式設計師在白板上作答還是有爭議的。作為面試官，我不在乎工程師是否記住了 Python 中的 itertools 模組，我在乎的是他們是否想通了如何用 itertools 模組去解決問題。通過讓他們在白板上答題，他們便可以不用遵循嚴格的程式設計語法，而完全專注於邏輯問題。但最終白板答題的提議還是行不通，因為白板上答案的形式五花八門，沒有那麼多的評判標準可以對它們一一進行對錯評判。所以讓求職申請者們迴歸到電腦上程式設計，同時告訴他們不必真正去執行程式碼（或者採用更好的方法，進行開卷面試，讓他們在 Google 上查詢任何所需的資訊），那麼考察他們的目的就已經達到了。

面試問題應該對日後工作有所反應，對此要特別警告，面試不依賴於外部因素是至關重要的。比如說，讓一個求職者用 Ruby 編寫一個簡單的爬蟲看似是個很好的實際問題，但是，如果求職者為此需要先安裝 Nokogiri （一個安裝起來非常費勁的 Ruby 解析庫），結果花了 30 分鐘絞盡腦汁應對本地擴充套件，那麼這次面試就糟透了，不僅浪費了時間，而且也讓求職者一下子壓力爆棚。

3.問不會提前洩露的多面性問題

另一個針對面試提問的經驗之談是避擴音問有可能會“洩露”出去的問題。比如說，有些問題的某些資訊可能求職申請者提前能從 Glassdoor 上讀到，所以他們回答起來就會輕而易舉，因此這類問題就要避擴音問，否則求職者明顯就不用動腦筋了，也抹殺了需要考驗他們直覺洞察力的地方。而且除此之外，也意味著面試的問題應該由一系列相互承載的部分組成，而不是一個單一的中心。換種有用的方式去想，問問你自己，能不能在面試時幫助一個陷於困境的求職者，並讓他在面試結束還能給大家留下一個不錯的印象。對答案唯一的問題，如果你給求職申請者提供了明顯的幫助，那麼他就直接面臨淘汰；而對於多面性的問題，你幫了求職申請者一步，那麼他還有機會在其餘部分大展身手，完美表現。

伯樂線上補註：Glassdoor 是國外一家做企業點評和職位搜尋網站。

這一點很重要，不僅因為你的問題會在  Glassdoor 上洩露出來，而且（更重要的）是因為多面性的問題可以減少干擾。優秀的求職者會揹負壓力，陷於困境，面試時很重要的一點就是對他們提供幫助，從而讓其好好發揮。考查他們解決任意小程式設計邏輯問題的能力時，他們最近一段時間是不是看到過、或可能只是恰巧碰到過類似的問題，會對考查造成明顯干擾，而多面性的問題則可以消除一些干擾，也讓求職者們有機會看到他們的努力像滾雪球一樣越積越大。給他們提供一步的幫助，往往能幫他們解決緊接著的下一步，這給實際工作提供了重要動力，在面試時把握這一點就可以減少干擾。

舉例來說，讓一個求職者在終端實現“四子連珠”遊戲（一系列多個步驟），可能要比讓他去旋轉矩陣（一個單獨步驟，外加之一些小操作）要好得多；讓求職者實現 k 均值聚類（建立在彼此之上的多個操作）可能要比找到直方圖中的最大矩形（leetcode 的一道演算法題）要好得多。

4.避免問很難的問題

如果求職者很好地解決了一個很難的問題，那能極大地證明他的能力，但也正因為這個問題很難，所以大多數求職者都無力招架。你想要獲得的資訊量就很大程度上依賴於問題的難度，我們發現面試問題最合適的難度要明顯比大多數面試官所想的簡單得多。

這一點影響更大，因為面試求職者時，獲得的資訊有兩種來源：他們是否對一個問題給出了“正確的”答案、他們得出答案的過程/得出答案的容易程度。我們在 Triplebyte上收集了這方面的資料（同時給他們是否得出了正確答案和他們花費了多大努力這兩項打分，然後衡量對公司而言哪個分數能更準確地對求職者能力進行預測）。我們發現這是一種權衡，對於更難的問題，求職者是否給出了正確的答案更能說明問題，相比之下，對於更簡單的問題，求職者的答題過程和他們花費的努力程度則更有參考價值。考量了這兩種資訊來源後，面試問題最適宜的難度會往更加簡單的方向偏移。

我們現在遵循的經驗法則是，面試官解決問題所用的時間應該是他們希望求職申請者們解決問題所花時間的25%。所以如果我在為時1小時的面試中提出了一個新的問題，我希望我的同事（沒有提醒的情況下）能在15分鐘內解答。外加之我們應問實際環境下的多面性問題，這意味著最佳的面試問題真的是相當直白和簡單的。

要澄清一點，我不是說要降低通過率的門檻。我支援問簡單的問題，然後將他們回答的情況納入考評範圍；我支援問簡單的問題，然後給予相當嚴苛的評判。這就是我們所找到的對面試環境進行優化的方式，這種方式額外產生的好處就是可以降低大部分求職者的面試壓力。

舉例來說，讓一個求職者建立一個簡單的命令列介面，要求儲存和檢索鍵值對（如果做得好的話就再增添功能），可能要比讓他們為算數表示式實現解析器要好得多；面試問題包含最普通的資料結構（表、雜湊、還可能有樹）可能要比涉及跳錶、二叉排序樹或其他更模糊的資料結構要好得多。

5 向每個求職申請者問相同的問題

面試就要對各個求職申請者進行比較，我們的目標就是將他們分為能為公司奉獻光與熱的和不能奉獻的（在大家申請同一職位的情況下，選出申請人中最優秀的一個）。鑑於此，就沒有理由向不同的求職申請者問不同的問題。如果你對申請同一職位的不同求職申請者採用不同的方式進行評判，那麼你就引入了干擾因素。

面試之所以一直都是當場選擇問題，我覺得是因為面試官更喜歡這種方式。科技公司的工程師通常不喜歡面試別人，他們只是偶爾面試一下，面試會使他們偏離工作重點。為了將針對每個求職申請者的面試問題規範化，面試官們就需要花費更多的時間去學習如何制定面試問題，並且探討面試打分、交接的方式。而且每次問題一發生變化，他們就需要重複以上過程。經常問同樣的問題只是有些枯燥乏味而已。

不幸的是，面試成功唯一的正解就是面試官需要花費心力。保證一致性是實現良好面試的關鍵所在，也就是說向每個求職申請者問相同的問題，並且要確保交接標準化，除此之外別無他法。

6.考慮實行多重的面試方法

與我之前的觀點相悖，這裡我們可以考慮提供幾種截然不同的面試方法。籌備面試時，我們首先應該考慮想要招哪種型別的技術人才，但是我們想要的人才特質可能是相矛盾的，這一點很常見，例如想要招非常有數學天分的工程師，和一些高產/重複性強的工程師（甚至可能是針對同一職位）。在這種情況下，考慮採用多重的面試方法，其中關鍵在於你要很大程度上保證每種面試方法都是完全規範化的，我們在 Triplebyte上就在這樣做。我們發現你僅需問每個求職申請者他們所青睞的面試方法即可。

7.不要因為資歷而小看別人

資歷不是沒用的，畢業於麻省理工或者史丹佛的，抑或在谷歌和蘋果公司工作過的工程師組建的隊伍確實要比沒這些資歷的工程師更加優秀，但問題是絕大多數工程師（包括我自己）都沒有以上資歷，所以如果一個公司對此過分看重，那他們就會錯失大多數程式設計大牛。在篩選環節將申請人的資歷納入考量範圍並非毫無道理。我們在 Triplebyte 上沒這麼做（我們的考評是100%不看背景的），但是在篩選時對申請人的資歷做一定的參考可能會有用。

但是若讓資歷問題影響最終面試結果，那就沒有道理了，資料表明這種情況確有發生。在我們不看背景進行考評的過程中，對於表現情況一定的求職申請者，那些簡歷上寫有名校文憑的要在比沒有名校文憑的人過關率高30%。如果面試官知道求職申請者手握麻省理工的文憑，那他們就更願意原諒他們在面試環節暴露出來的一些瑕疵。

這就是你應該避免的干擾，最顯而易見的解決方式就是在開始面試前直接跳過申請者簡歷上的學校和公司名，有些求職申請者可能會提到他們的學校或公司，但是我們的面試都不看申請者的背景，而且在進行技術考評時，申請者自己提背景的情況也是相當少見的。

8.避免羞辱

面試失敗的最醜惡的一種情況，就是招聘人員表現出一種羞辱的態度。他們不僅是對求職者技能進行考評的人，而且也代表即將要納入成員的一個組或一支團隊，在第二種身份下，面試是迎接新成員的重要儀式。面試確實讓人有壓力，很恐怖，但我們都會揹負面試壓力，所以求職者也自然會有壓力，尤其在求職者表現不佳時，面試壓力會更加凸顯出來。當面試官看到求職者對著答案看上去那麼顯而易見的問題，就是答不出來急得砸腦袋時，就會覺得大失所望，氣不打一處來，同時又萬分沮喪，這樣無疑會讓求職者壓力更大，形成惡性迴圈。

一般這種情況面試官唯恐避之不及，為此應該展開探討，並且對面試官進行培訓。我們用的一個策略是，當求職者表現很差勁時，就將想要對其進行考評的評估模式切換成想要讓其理解問題正解的教學模式。心理上的這種切換大有裨益，當你採用教學模式時，你就沒有理由硬忍住不說答案了，也會變得完全親和友善。

9.根據最高技能，而非平均或最低技能做錄用決定

迄今為止，我只探討過單獨的問題，卻沒有談過最終的面試決策。我的建議：在做錄用決定時應看求職者（在你所關心的技能中）具備的最高水平技能，而非中等或最低水平技能。

無論是有意還是無意，你們好像就是這麼做的。每個面試過求職者的面試官通過聚在一起開會，來制定最終的錄用/淘汰決定。在至少有一人力挺，且沒有人強烈反對的情況下，求職申請者就會被錄用。要想讓一人力挺，求職申請者就需要主攻面試的其中一個部分，大顯身手。我們的資料顯示，要在公司面試的至少其中一個部分表現優異，求職者具備的最高技能就是最緊密的影響因素了。然而，為了得到 offer，求職者也需要保證沒有強烈反對的聲音，而若回答問題時表現得非常愚蠢，那麼就不會引發強烈的反對。

這裡我們會發現大量的干擾，技術高明的工程師具備的能力各式各樣，因而幾乎不可能有求職者能駕馭所有技能。這就意味著如果你問了一個正確的（或錯誤的）問題，任何工程師都有可能出醜。那麼求職者至少在一次面試中，體現了在一方面的優勢（最高技能），且沒有暴露在某些方面的明顯劣勢，才能獲得 offer，而這裡就有干擾出現。如同一個工程師在回答有關網路系統的面試問題時表現不好而遭到淘汰，但卻在另一個面試中成績優異，只因為面試沒出網路系統的問題。

我認為最好的解決方法就是讓公司專注於求職者的最高技能，同時對於面試中部分環節表現不佳的人也能通融給過。這就是說，尋找充分的理由去錄用，而不要因為求職申請者在某些技術領域能力薄弱的而過分擔心。我不想表現得過於絕對，當然有些領域對公司是至關重要的。而且對於企業文化，若團隊中每個人在特定的領域都有特定的定位，那很可能大有裨益，但是將更多的注意力集中於最高技能著實可以減少面試中的干擾。

 

到底為什麼要搞面試？

我應該回答的最後一個問題是為什麼要搞面試？我確信有些讀者已經咬牙切齒地問“對一個破敗的系統想那麼多幹嘛？直接用帶回家的專案進行考評不就行了！或者直接採取試用唄！”畢竟，一些非常成功的企業都會進行試用（求職者在團隊中待一週），或者用帶回家的專案取代當面面試。試用是很有意義的，幾乎可以肯定的是，讓他們花一週的時間跟在一個工程師旁邊工作（或者看他們是如何完成一個實際的專案的），要比讓他們回答1小時的面試問題更能反映能力。然而，有兩個問題導致試用一直無法取代標準面試：

1.要進行試用的話，公司要承受高昂成本，沒有公司能為每個求職申請者承擔整整一週的試用花銷。因而公司必須採用其他的面試環節來決定試用的人選。

2.試用（以及大型的帶回家完成的專案）對求職者而言成本高昂，即使他們能獲得報酬，那也未必有空參與。比如一個工程師的工作是全職的，就可能沒法抽空幹別的，而且就算能抽出時間，可能也不願意。而且如果一個工程師已經獲得了一些offer，那就不太可能再甘願承受結果還充滿不確定性的試用考驗了，這一現象明顯能從 Tripletype 上的求職者中看到。許多最優秀的求職申請者（擁有其他公司的offer）只是單純不做大型專案或者不經受試用考驗。

試用是一種選人的絕佳方式。我認為如果你有開展試用的經濟實力，那麼加上試用這種選人方式是很不錯的。但要想讓這取代技術面試，並不完全可行。

瞭解工程師過去的開發經歷也可以成為取代技術面試的一種方式。邏輯上來看，通過了解他們過去的開發情況，就可以推知他們未來是否可以將工作幹得得心應手。遺憾的是，我們在 Triplebyte 上實行此方法時，收效甚微。表達能力（推銷自己的能力）強的到頭來要比技術能力強的人更有勝算，巧舌如簧的工程師對自己的職能誇誇其談（將整個團隊的功勞獨吞），謙虛謹慎的工程師卻對自己的成績輕描淡寫，這樣的現象屢見不鮮。如果有充分的時間和大量的問題去刨根究底，就有可能弄清楚真實情況，但是我們發現，常規面試時間有限，談論過去的開發經歷通常並不能取代技術面試。雖然談過去經歷有助於破冰，拉近和求職申請者間的關係，能夠對他們的興趣有所瞭解，（而且能從中評判求職者的表達能力，還有可能看出他和企業的的文化契合度），但要想讓這取代技術面試，並不完全可行。

這裡推薦一下我的交流群：236283328    我主要是提供一個免費平臺，群內會 Java 工程化、高效能及分散式、高效能、深入淺出。效能調優、Spring，MyBatis，Netty 原始碼分析和大資料等視訊及文件資料，因為分享的是Java進階資料，所以小白勿入群，謝謝！

程式設計面試的好處！

我想讓這篇部落格以更加樂觀的角度作結，無論面試存在多大的問題，但採用這種方法其實也有頗多好處。

面試是對申請者能力的直接評估，我有一些朋友是當老師的，他們告訴我教師面試基本上考察的是語言表達能力（推銷自己的能力）和所具備的文憑資歷，這一點似乎從很多職業中都能得到印證。矽谷沒有非常完美的精英體制，但我們至少確實在設法對申請者應具備的重要能力進行直接衡量，並且秉持達觀開放的思想，認為一個人無論背景如何，只要具備相應的能力，就能夠成為非常優秀的工程師。

程式設計師同時也在選擇面試形式。儘管這個話題頗有爭議（當然有程式設計師對此持異議），但我們提供了各式各樣不同的考評形式，通過試驗，我們發現絕大多數的程式設計師還是會挑選常規的面試形式，僅有一小部分人會對公司採用試用或帶回家的專案進行考評的形式更感興趣。無論怎樣，我們這裡要說的是程式設計面試，其他形式的考評都能作為很好的補充備選，但看起來不太可能取代面試成為考評工程師的主要形式。不確切地套用丘吉爾的一句話：“面試是最差的一種考評工程師的方式，但它是我們迄今為止所能找到的最好的一種方式。”

結論

面試工作很難，無奈的是人類都是複雜的。從某種程度上來說，想要靠區區幾小時的面試去評判一個人的能力，這是傻子才會乾的事，因而我覺得保持謙遜的態度是至關重要的。任何面試在很多時候都註定會失敗，只是因為人實在是太複雜了。