譯者注：Triplebyte是一家協助其他公司招聘工程師的企業。在他的招聘流程中不關注應聘者的背景，並通過多種方法來減少對應聘者的偏見，致力於建立更好的招聘流程。本文介紹了該公司的一些招聘經驗和建議。以下是譯文。

我們在Triplebyte公司做過很多次面試。事實上，在過去的兩年裡，我曾面試了900多名工程師。這是否真的很好地利用了我自己的時間了呢？值得探討一下！但是，不管怎麼說，我們的目標是讓工程師更好地被僱用。為此，對於應聘者，我們不關注他們的背景，不看他們的證書或者簡歷，而是直接考核他們的程式設計技能。在工程師通過我們的招聘流程之後，他們會直接進入我們合作的公司進行最後的面試（包括蘋果、Facebook、Dropbox和Stripe）。我們不看應聘者的背景，直接對他們進行面試，然後再看看他們在這些頂尖的科技公司表現的怎麼樣。這為我們提供了一些面試方面非常有用的資料。

在這篇文章中，將介紹我們從這些資料中學到的東西。技術面試現在出現了很多種不同的方式。但是這個說起來容易，做起來難。我這篇文章的目標就是來接受這個挑戰，為招聘經理和首席技術官提供具體的建議。面試雖然很難，但是我認為，只要認真對待，許多問題都可以得到解決。

現狀

大多數的面試過程都包括這兩個主要步驟：

1. 申請人篩選
2. 親身面試

對申請人進行篩選，目的是儘早過濾掉一部分應聘者，以節省面試時間。篩選的過程通常包括：招聘人員瀏覽應聘者的簡歷（約10秒鐘），然後是30分鐘到1小時的電話溝通。我們共有18％的公司使用了家庭式的程式設計考核（無論是取代手機篩選，還是額外增加的考核）。 有趣的是，經過這些篩選步驟，絕大多數應聘者都會被拒絕掉

親身面試通常由45分鐘到1小時的談話組成，每次談話都有不同的面試官。這些談話主要是技術方面的（每個公司一般都會有一兩個專注於文化素養和軟技能方面的談話）。聘用或者不聘用的決定最終會在應聘者離開後的相關會議中確定下來，招聘經理和每個面試官都會參加這個會議。基本上來說，應聘者至少需要有一個強有力的支持者，並且沒有強力的反對者才能最終得以錄用。

然而，除了常見的形式之外，最終面試的形式也千差萬別：

• 39％的公司在面試過程中會在白板上做標記
• 52％允許應聘者使用自己的電腦（有9％不一定）
• 55％讓應聘者自己挑選問題（剩下的45％使用標準題庫）
• 40％需要視應聘者的理論電腦科學水平來決定是否錄用
• 15％不喜歡理論電腦科學（並認為，談論理論電腦科學代表了這個應聘者並不具有創造性）
• 80％讓應聘者在面試中可以使用任何程式語言（其餘的20％需要使用特定的語言）
• 5％在面試中會明確地評估程式設計中的細節問題

在所有合作的公司中，最終22%的人能得到錄用通知。約65％的錄用通知會被接受（最終產生僱傭關係）。一年以後，這些公司會對其中大約30％的員工感到非常滿意，同時，5％左右的員工被解僱。

錯誤的否定 vs. 錯誤的肯定

那麼，目前的這種狀況有什麼問題嗎？要看清楚存在的問題，首先要思考一下面試失敗的兩種情形。面試可能會讓一名壞的工程師被僱用，後來再被解僱（錯誤的肯定）。而面試也可能會使那些本來能夠勝任這份工作的人失去資格（錯誤的否定）。錯誤的錄用所產生的後果是顯而易見的，對公司而言代價也是很昂貴的（體現在薪酬、管理成本和整個團隊的士氣等方面）。錯誤的錄用會消耗團隊的精力。相比之下，可以勝任工作但卻沒有得到機會的候選者是看不見的。這兩種情況中的任何一種都存在爭議。由於這種不對等性，公司在面試中更傾向於拒絕應聘者。

招聘過程中的雜音會增加這些問題出現的概率。在一小時內判斷應聘者的程式設計水平從根本上來說是很困難的。再加上一系列的模式匹配和依賴直覺的電話溝通，以及上面提到的不同公司的不同偏好，這些都會給你留下非常大的雜音。

在這些雜音下，為了保證低概率的“錯誤的決定”，公司的決策必須偏向於拒絕應聘者。最終產生的結果就是錯失優秀的工程師、相對於實際的技能更看重其擁有的證書，以及對相關的人員舉棋不定甚至失望。如果對公司的每個人都要針對其從事的工作重新進行面試，那麼通過的百分比有多少呢？這是一個可怕的問題。答案几乎可以肯定在100％以下。應聘者在被公司拒絕後可能會受到傷害，而公司在找不到所需的人才時也會受到傷害。

需要澄清的是，我不是說公司在面試中應該降低要求。拒絕是面試的重點！我更加沒有說，公司害怕“錯誤的肯定”甚於“錯誤的否定”是錯誤的。錯誤的錄用一個應聘者所帶來的代價是昂貴的。我認為，招聘過程中的雜音和避免招錯人的想法，導致了“錯誤的否定”的概率很高，這傷害了那些應聘者。而解決的辦法就是改善訊號。

減少面試中的雜音的具體方法

1. 確定你要找的員工需要具備哪些技能

並沒有一套技能標準來定義一個好的程式設計師。相反，這世上有很多種各不相同的技能集。沒有哪個工程師能夠擅長這所有領域的技能。事實上，在Triplebyte公司，我們經常會看到優秀而又成功的軟體工程師擁有完全不相關的技能。那麼，進行一個好的面試的第一步就是要確定應聘者需要具備哪些技能。我建議你問一下你自己下面幾個問題。

• 你需要一個能夠快速迭代的程式設計師，還是細心嚴謹的程式設計師？
• 你想要有人來解決技術問題，還是構建產品？
• 你是否需要一個擁有某個特定技術技能的程式設計師，還是一個聰明的、能夠在工作中學習的程式設計師？
• 理論電腦科學、數學、演算法能力是重要的還是無關緊要的？
• 理解併發、C記憶體模型、HTTP是否重要？

這些問題沒有正確的答案。我們所在的那些成功的公司對這些問題都會有正反兩個不同的答案。但是，最關鍵的是你應該根據自己的需要來做出有目的性的選擇。因此，我們要避免的就是簡單地隨機性地挑選面試問題（或讓每個面試官自己決定）。當這種情況發生時，公司的工程師文化可能會發生偏離，具有某個特定技能的工程師會越來越多，公司會向著不重要的方向發展，而那些不具備這種技能的工程師（但是具備其他重要的技能）會被拒絕。

2. 讓問的問題儘可能地接近真實的工作

聘請的專業程式設計師為了解決一些複雜的大問題可能需要耗費數週甚至數月，但面試官並沒有幾個星期或幾個月的時間來評估一個應聘者。每個面試官通常只有一個小時的時間。面試官看的是應聘者在壓力下快速解決小問題的能力。這是一項與眾不同的技能。它與應聘者本身所具備的技術技能是相關的，但又不完全相關。在制定面試問題時，應儘可能地讓他們之間的差異最小化。

面試中問的問題應儘可能地接近應聘者應聘的那個職位（或者你想要衡量的技能）。例如，如果你關心的是後端程式設計，可以讓應聘者構建一個簡單的API並新增功能，而不是要求他們解決BFS字鏈問題。如果你關心演算法方面的能力，可以讓應聘者通過使用演算法來解決問題（比如，用BST和hashmap來構建一個簡單的搜尋索引，以提高刪除操作的效能），而不是要求他們確定一個點是否包含在一個凹多邊形中。你可以讓應聘者在白板上解決一個小問題，也可以讓他們用真實程式碼來除錯程式，但是，後者相對來說效果更好一些。

也就是說，在白板上進行面試是有爭議的。作為一個面試官，我不在乎工程師是否能夠熟記Python itertools模組。我關心的是他們如何使用迭代器來解決問題。通過讓應聘者在白板上工作，我可以讓他們不必關注語法正確與否，而是專注於邏輯。但是，最終我認為這個論點是錯誤的，因為對於不同的面試形式並沒有給出足夠的理由。你可以讓應聘者在計算機上操作來獲得上面提到的所有的好處，只要告訴他們這個程式碼不需要執行就行了（甚至可以成為一個開放的書面面試，並允許他們用谷歌搜尋任何他們想要的東西）。

重點說明一下，面試過程中問的問題應該要能反映實際的工作。這些問題不應該受外部的依賴，這很重要。例如，要求應聘者用Ruby編寫一個簡單的網路爬蟲看起來就是一個不錯的實際問題。然而，如果應聘者需要安裝Nokogiri（一個Ruby解析庫，安裝起來可能會很痛苦），並且最終用了30分鐘的時間來配置本地擴充套件，那麼這將成為一個可怕的面試。不僅浪費了時間，而且對應聘者的壓力也已經過去了。

3. 問那種不能放棄的並且包含多個部分的問題

對於面試中要問的問題，有另外一個很好的經驗法則，那就是要避免可以“放棄”的問題，例如，避免出現應聘者可以提前在Glassdoor（譯者注：Glassdoor是美國的一家做企業點評與職位搜尋的職場社群網站）上搜索到相關資訊的問題，以防止他們不用動腦子就可以回答出來。這樣就排除了腦筋急轉彎或者任何需要頓悟的問題。同時也意味著所提的問題需要有一系列相互依存的步驟，而不是一個單一的核心問題。另一個有用的方法是問問你自己，你是否能幫助一個陷入難題的應聘者，並且在結束面試的時候，他仍然能夠給你一個積極的印象。對於一個只有一個步驟的問題，如果你不得不給應聘者以大量的幫助，那麼表明他們失敗了。而對於一個包含多個步驟的問題，你可以僅僅幫助他其中的一個步驟，讓應聘者可以回答好剩下的步驟。

這麼做很重要，不僅僅是因為你的問題可能會洩漏到Glassdoor上，而且（並且更重要）因為包含多個部分的問題的雜音更小。好的應聘者會變得緊張而又不知所措。幫助他們並且看著他們恢復情緒是很重要的。應聘者在解決任何一個程式設計邏輯問題時，都可能會產生一個很大的雜音，因為他們最近可能看到過類似的問題，或者是他們的運氣實在太好了。包含多個部分的問題可以消除一些雜音。它讓應聘者有機會看到他們自己努力的成果像滾雪球一樣越滾越大。在其中的某一個步驟上的努力往往會有助於他們解決後面的步驟。這在實際工作中是一個很重要的動力，而如果在面試中捕捉到這一點就能減少雜音。

舉個例子，讓應聘者在終端上實現Connect Four遊戲（有一系列的步驟）可能比要求應聘者旋轉一個矩陣（單單一個步驟）來得更好。而實現k均值聚類（互相依賴的多個操作）可能比確定直方圖中最大的矩形來得更好。

4. 避免太難的問題

如果一個應聘者順利解答了一個非常困難的問題，那麼這相當於告訴了你很多有關他的技能方面的事情。但是，由於問題很難，大多數應聘者都不能很好的解答。那麼期望從這個問題獲得的資訊的多少，就會受到這個問題的難度大小的影響。我們發現，最優的難度要比大多數面試官估計的難度要小得多。

我們現在遵循的經驗法則是，面試官解答出問題的時間應該是他們希望應聘者解答問題所花時間的25％。所以，如果我正在針對一個小時的面試開發新的問題，則我就會要求我的同事（沒有任何警告）能夠在15分鐘內回答出這些問題。同時，上文提到，問題要包含多個部分，並與實際工作相接近，所有這些要求結合在一起，使得最佳的面試問題真的是很直接很簡單。

需要澄清的是，我並沒有要求為了通過率而降低評判標準。我堅決主張對候選者問一些簡單的問題，然後在評估中要檢視應聘者是如何輕鬆地回答問題的。我主張問一些簡單的問題，但是對評判的標準嚴格一點。對於大多數應聘者來說，這樣帶來的壓力更小，這算是額外的好處吧。

舉個例子，要求應聘者建立一個簡單的命令列介面，其命令用於儲存和檢索鍵值對（如果他們完成的很好的話，可以新增一些功能）可能比要求應聘者實現算術表示式的解析器更好。而涉及到最常見的資料結構（列表、雜湊、樹）的問題可能比有關跳轉表、樹堆或其他更模糊的資料結構的問題更好。

5. 對每個應聘者問同樣的問題

面試就是對應聘者進行比較。目標是將應聘者分為能或者不能為公司做出貢獻的兩類人員（如果只是為單個職位僱用人員，則選擇最適合的人）。正因為這樣，向不同的應聘者提不同的問題是沒有道理的。如果你以不同的方式評估應聘同一工作的不同應聘者，就會引入雜音。

我認為，人們之所以繼續以一種隨意的方式選擇問題，是因為面試官喜歡這樣。技術公司的工程師通常不喜歡面試。他們只是偶爾做這種事情，同時，這也讓他們脫離了自己的主業。為了規範對每個應聘者所問的問題，面試官需要花更多的時間來學習這些問題，並討論得分和答案。每當問題改變時，他們都需要重新再來一遍。另外，總是問同樣的問題的確有那麼一點點乏味。

不幸的是，這裡唯一的答案就是要面試官付出自己的努力。一致性是進行有效面試的關鍵，這意味著要求對每個應聘者提出相同的問題，並標準化答案。別無選擇。

6. 考慮使用多套面試題

你應該考慮提供多份完全不同的面試題，這與我之前的觀點是衝突的。在設計面試題時，第一步要考慮的是有關技能方面的事情。然而，某些答案可能會互相之間衝突！例如，你可能需要招聘幾個遵守規則的工程師，但同時又要招幾個非常有創造性的工程師（甚至可能是相同的角色），這都是非常正常的。在這種情況下，應當考慮準備多套面試題。並且，關鍵問題是，你應該準備足夠多的題目來標準化每套試題。這就是我們在Triplebyte公司所做的事情。你可以簡單地詢問每個應聘者他們喜歡哪種型別的面試。

7. 不要讓自己因為證書而產生偏見

證書並不是毫無意義。從麻省理工學院或斯坦福大學畢業、或者在Google和蘋果工作過的工程師，從整體上來說比其他那些沒有這些經歷的工程師表現的要更好一些。但問題是，絕大多數的工程師（包括我自己）都沒有這些經歷。所以如果一家公司太依賴於這些，那麼他們會錯失絕大多數的技術人員。在篩選步驟中給予證書一定的重視程度並不是完全不合理。我們在Triplebyte不會這麼做（我們做的所有的評估100％都是不看他們的背景的）。但是，在篩選時給證書一定的重視程度可能是有意義的。

然而，讓證書來左右最終面試的決定沒有任何意義，而且我們有資料可以證明這種情況。擁有頂尖大學學位的應聘者的面試通過率比沒有名牌大學學位的候選者高出30%。如果面試官知道應聘者擁有麻省理工學院學位的話，他們更願意在面試中寬恕應聘者的錯誤。

這是一種雜音，你應該要避免。最簡單的方法就是在把簡歷提交給面試官之前將學校和公司名稱去掉。有些應聘者可能會提到他們的學校或公司，但我們在面試時並不知道應聘者的背景，而應聘者在技術評估時很少會提及這些。

8. 避免欺負應聘者

面試不僅僅是評估一個應聘者的技能，也是一個團隊在接納一個成員。對於後半句話來說，面試可以認為是一個通過儀式。是的，面試的壓力很大，也讓人討厭，但是我們都經歷了，應聘者也一樣。當應聘者做得不好時，這種情況會更加突出。作為一名面試官，當看到應聘者因為一道簡單的題目而卡住的時候，心裡是沮喪的。你會變得脾氣暴躁。當然，這隻會增加應聘者的壓力。

這就是你應該極力避免的東西。解決的辦法就是對這個問題進行討論並對面試官進行培訓。我們使用的一個竅門是，當應聘者表現得實在很差時，你可以把評估模式轉變為教學模式，評估模式的目標是評估應聘者的技能，而教學模式的目標是讓應聘者理解問題的答案。在心理上做出改變會有很大幫助作用。當你處在教學模式時，就沒有任何理由去隱瞞資訊或是做除了友好以外的其他事情。。

9. 根據應聘者具備的最強技能做決策，而不是平均或最小技能

到目前為止，我只討論了個別問題，而沒有討論最後的面試決策。我的建議是嘗試根據應聘者展示出來的最強技能水平，而不是平均水平或最低水平來做出決策。

這個可能你已經有意或者無意地在做了！做出是否錄用決定的方式是這樣的，每個面試應聘者的人坐在一起開會，如果至少有一個人強烈要求錄用，而且沒有其他人強烈反對，那麼最終就會錄用。而要讓一位面試官強烈的支援他，就是應聘者在面試過程中需要做的事情了。我們的資料顯示，最強技能是與面試最相關的屬性。然而，要被錄用，不能有任何一個面試官發出強烈的反對意見。當應聘者在一個問題上看起來真的很愚蠢的時候，強者的反對意見就會出現。

在這裡我們發現了很多雜音。要成為一名熟練的工程師有很多種不同的方式，但幾乎沒有哪個應聘者可以全部掌握他們。這意味著如果你提出正確（或錯誤）的問題，任何工程師都可能會看起來很愚蠢。應聘者收到錄用通知，那麼說明他至少在某一個領域很牛逼（最強技能），而且在其他領域也不會太差。問題是，這就是雜音。同樣的一個工程師，因為在網路問題上看起來很蠢而沒有通過某一次面試，但他出色地通過了其他的面試，就因為這方面的問題沒有出現。

我認為最好的解決辦法是讓公司專注於最強技能，並且對那些在面試中表現得不太好的人提供更多的幫助。這就是要尋找強有力的理由來肯定應聘者，而不是擔心應聘者薄弱的方面。我不認為這是絕對的。當然，技術領域對於公司而言是至關重要的。但更多地關注最強技能可以降低面試的雜音。

為什麼要進行面試？

我回答的最後一個問題是為什麼要進行面試？我相信一些讀者已經在咬牙切齒地說：“為什麼要為這個破面試考慮那麼多東西？完全可以採用家庭式專案，或者試用就業就可以了！” 畢竟，一些非常成功的公司使用的就是試用就業（讓應聘者加入團隊一個星期），或完全用家庭式專案取代現場面試。試用就業具有很大的意義。在工程師旁邊工作一個星期（或者看著他們如何完成一個實質性的專案）肯定比觀察他們在一個小時內如何解決面試問題能更好地衡量他們的能力。然而，有兩個問題使得試用就業無法完全取代標準的面試：

1. 對於公司來說，試用就業的代價很高。沒有哪個公司會為每個應聘者花一個星期的時間。為了決定誰來試用就業，公司必須採用一些其他的面試過程。

2. 對於試用就業（和大型的家庭式專案），應聘者要付出的代價很高。即使付他們薪水，也不是所有的應聘者都有時間。例如，從事全職工作的工程師可能根本沒有時間來做這個。即使可以，許多人也不會這麼做。如果工程師手裡已經有了其他的錄用通知，那麼他們就不太願意承擔試用就業的不確定性。在Triplebyte的應聘者中，我們很清楚地看到了這一點。許多非常優秀的應聘者（手裡還有其他公司的錄用通知）不會做大型專案或試用就業。

試用就業是提供應聘者的絕佳選擇。我認為如果你有足夠的規模來支援多種招聘方式，那麼新增試用就業這種方式是一個好主意。然而，作為面試的完全替代品是不可行的。

與應聘者談論過去的經驗有時會被用來替代技術面試。看看應聘者是否能在未來做好工作，從邏輯上來講，可以看看他們在過去做了什麼。我們已經在Triplebyte測試了這一點，不幸的是我們並沒有總結出很好的結果。溝通能力（銷售自己的能力）最終成為比技術能力更強的訊號。我們經常會發現口才好的人喜歡誇大他們的作用，而謙虛的人則會淡化他們所做的事情。如果有足夠的時間並問他們足夠的問題，也許就能分清這兩種人。然而，我們發現，在常規面試的時間內，談論過去的經驗並不是面試的一般替代方法。這是打破冷場並理解應聘者的興趣好愛的不錯的方法（並判斷他們的溝通能力）。但這並不是一個切實可行的面試替代方案。

有關程式設計面試的好的方面！

我想以更積極的方式來結束這篇文章。對於面試中出現的錯誤，其實也有不少可取之處。

面試就是直接對技能進行評估。我有一些朋友，他們是老師，他們告訴我說，對老師的面試基本上就是衡量他們的溝通能力（銷售自己的能力）和一張證書。這對於很多專業來說似乎都是如此。矽谷不是一個完美的精英聚集地。但我們至少要嘗試直接考核那些重要的技能，並始終相信，任何有這些技能的人，不管他們的背景如何，都可以成為一名偉大的工程師。證書偏見往往阻礙了這一點。但是，我們在Triplebyte已經能夠克服這個問題，並幫助很多具有非正規背景的人獲得了很好的技術性工作。但是，在其他一些領域，例如，在法律領域，對證書的依賴度就很高。

程式設計師還可以對面試的方式進行選擇。這是一個非常有爭議的話題，我們做了一個實驗，提供了多種不同型別的評估方式，我們發現大多數程式設計師仍然選擇常規的面試。並且我們發現，只有少數程式設計師對採用試用就業或家庭式專案的公司感興趣。無論是好是壞，程式設計面試是大家普遍接受的面試方式。其他型別的評估方式都是偉大的補充，但他們似乎不太可能取代面試作為評估工程師的主要方式。錯誤地引用丘吉爾的話，“除了所有其他嘗試過的方法，面試是評估工程師最糟糕的方法。”

結論

面試很難。人類相當的複雜。從某種程度上來說，在四個小時的面試中判斷一個人的能力是一個愚蠢的行為。我認為保持謙虛很重要。任何面試的過程註定要失敗很多次。人太複雜了。

但這並不是說要放棄面試。嘗試採用任人唯才的面試流程總比不嘗試要好。在Triplebyte，我們的面試流程就是我們的產品。我們集思廣益，然後進行測試，並隨著時間的推移逐步改進。我認為，這就是改進工程師招聘方式的方法。在這篇文章中，我分享了過去兩年裡我們學到的一些大的事情。我很樂意收到反饋意見，並被告知這些想法對其他人有幫助。