領英上有不少公司CEO，聲稱可以在五分鐘內通過簡單的對話甄別出合適的候選人，實際是違科學。本文將揭示面試開發(fā)者的科學之道。

我對領英上那些大言不慚的帖子快要失去耐心了，帖子里一位剛出道的科技公司CEO這樣說道："我不需要對候選人進行為期一周的面試和多次的評估，只需要與候選人進行對話，就可以在大約五分鐘內判斷他們是否可以勝任這份工作"。

事實果真如此嗎？非也。盡管較短的面試是個不錯的選擇（過長的面試可能會嚇跑最搶手的候選人），但事實證明，"邊喝咖啡邊談話"式的面試很糟糕，它的結果并不比隨機選擇來得更好。

我們從那些CEO身上看到的并不是非凡的直覺或者社交技能，其實只是鄧寧-克魯格效應（Dunning-Kruger effect），是一種認知偏差，能力欠缺的人有一種虛幻的自我優(yōu)越感，會錯誤地高估自己的真實能力，而且他們越差，高估的程度就越高。面試就是被研究得最充分的例子之一。不經過提前準備，世界上沒有一個人可以在五分鐘左右的對話中評估出某人的工作技能，即興對話并不是面試，僅能達到見面聊天的效果。然而，有些雇主仍堅持認為，這是挑選出優(yōu)秀候選人的最高效的方式。

一次又一次的研究表明，這樣的做法是錯誤的。天馬行空，沒有體系的面試會大大增加各種偏見，給面試官的個性發(fā)揮敞開大門，并最終大幅降低招聘的準確性，結果可能比跳過面試隨機挑選還更糟糕。更嚴重的是，錯誤的候選人可能會造成公司上百萬美元的經濟損失，并導致項目的大幅延期。

編程考察和能力證明

對于程序員來說，糟糕的面試尤其讓人沮喪。而編程則是一項特別純粹，能證明自己能力的考察項。你僅僅通過肉眼，無法評估一座橋的質量或者一頓飯的準備工作量，但是代碼就不一樣，他特別純粹，所見即所得，好或者壞一目了然。不需要過多復雜的設置，候選人就可以展示自己實時編寫優(yōu)雅代碼的能力。然而，許多公司卻反其道而行之，經常提出一些與他們正在招聘的工作完全無關的奇葩題目。

我們大多數(shù)人都有過切身的體會。你正在面試你的第一份程序員工作，而面試官卻想知道元素周期表上的哪個元素最能體現(xiàn)你的個性；你是一位資深的前端開發(fā)，但是在長達一小時的面試時間里，卻都是一些"坑爹"測試題，比如closures(閉包)和hoisting(變量聲明提升)的用法；你從零開始搭建過多個.Net應用，但面試官卻希望你反轉二叉樹；你已經為Linux內核代碼做出貢獻，但現(xiàn)在你必須猜測出面試室內可以容納多少個乒乓球。這一切都讓你覺得崩潰。

在當前程序員炙手可熱，工資飛漲的市場環(huán)境下，這樣的現(xiàn)象令人不解。越來越多的公司為了提升吸引力，允許遠程辦工，部分初創(chuàng)的科技公司還提出一周只工作四天的優(yōu)厚待遇，獵頭更像詐騙犯一樣瘋狂地想聯(lián)系到我們。但是如果被錄用的候選人不能勝任這份工作，這一切不都白費了，那為什么公司不愿在招聘階段花費更多的投入呢？

優(yōu)化后的面試流程

下面讓我們來談談理想的編程面試應該是什么樣子，如果你的工作是寫Java代碼，那么流程可能是這樣的：

1. 在第一次接觸候選人時，披露薪資范圍和福利情況

2. 提前查閱候選人的簡歷，了解他們的Java專業(yè)度或者開源經驗(任何其他的編程語言也類似；Groovy和Kotlin可以類比)

3. 在現(xiàn)實環(huán)境中觀察候選人近一小時的Java編碼情況，并根據(jù)預先制訂的、與工作相關的維度對他們進行評分，如問題解決、空值安全、錯誤處理、可讀性、命名規(guī)范、封裝度等

4. 進行規(guī)范化、標準化的評估，考察候選人對JVM和基本命令行工具的熟練情況

5. 讓候選人知道什么時候可以接到后續(xù)通知

就是這樣，拒絕天馬行空的"文化面試"，拒絕"小組測驗"，拒絕"編譯器優(yōu)化測驗"，拒絕讓候選人在業(yè)余時間從頭開始搭建一個15小時的項目。你只要正常評估他們的某項工作技能就可以了。

當然，這并不是說我認為編碼能力(或者其他一項技能)是候選人唯一重要的事。誠然，你想雇傭到可靠、聰明、誠實和善良的人，但你必須將自己的要求限制在可知的范圍內，就工作面試而言，選擇沒有很多。大多數(shù)應聘者在求職面試中表現(xiàn)得很虛偽，其中絕大部分的人會撒謊。即使假定應聘者很誠實，十有八九的人還會有面試焦慮。如果你想真正了解某人在工作中的表現(xiàn)，你根本不能依賴面試，那些都不是他們真正的樣子。當然了，如果你看到任何不良的信號，比如對待接待人員十分無禮，你大可以直接扔掉他們的簡歷，不過這也通常很少見。

這也是招聘的固有弊?。好嬖嚥]有我們想像中那么強大。許多雇主嘗試使用軟技能和人格測驗的面試方法。但是，任何超出實際、不可衡量的指標通常都是一種錯覺，盡管看上去令人信服。2013年的一項研究表明，即使候選人的回答是隨機挑選的，面試官也會對候選人產生高度自信的印象！人們傾向于相信第一印象，無論他們是否準確，這都會造成招聘過程中的失誤。任何僅通過直覺了解其他人的測試方法，都會降低結果的準確性，唯一可以準確衡量的只有任務能力。

測試編程能力的方法

這樣說來，如果現(xiàn)場編程是我們能做的最好選擇，那么衡量編程技能的理想方法是什么？不少商業(yè)產品如LeetCode，提供了一套編碼平臺，并配有許多預先設計好、可以自動評分的任務用來測試候選人。盡管他們比常規(guī)的方法要好得多，但我們并不打算推廣。你想一下，你的團隊整天都在做針對性的、有現(xiàn)實意義的面試評測，你為什么要采用另一家公司的通用評測方法，并且還是付費的？最近一次我在設計編程測試題時，就從我的日常工作中選擇了一段比較優(yōu)秀(不是"膠水代碼")但不涉及任何公司業(yè)務的代碼，對其進行調整以便能自己獨立運行，并將函數(shù)簽名復制到LINQPad(一個.net的代碼運行平臺)平臺上，而候選人的任務與我的工作需求很相似，要求實現(xiàn)這個函數(shù)。當他們完成時，我就知道他們是否可以勝任這份工作，基本上沒有比這更具實際意義的評測方法了。

此外，到目前為止，我經歷過體驗最好的面試流程，是與一家初創(chuàng)公司簽訂了一份為期一周的合同(一些公司稱之為"試鏡")，在這一周里我與他們的團隊合作，他們給我分配任務，我克隆了他們的倉庫代碼，用了幾個晚上的時間編寫并提交了PR(Pull Request)，團隊的其他成員給出了反饋意見，我根據(jù)反饋修改代碼以達到他們的標準，最后他們將代碼合并，并按我的時薪標準支付了薪水。盡管我最終沒有接受他們的offer，但大家實現(xiàn)了雙贏——他們完成了一些額外的工作，而我得到了薪水。如果我接受了，通過一周的工作，證明了我的技能和團隊合作能力不會有任何問題。多年后，如果我仍要找工作，這家公司仍在我的候選名單上，因為這種面試方式相當靠譜。

也許這種方式不是你認為的面試，但我要說這比面試好得多。你能想象花費5分鐘與CEO們閑聊然后決定面試結果有多可笑嗎，這些CEO甚至都不會編碼。

出于安全或者公司規(guī)定等原因，一些團隊可能無法采用上述這種面試方法，在這種情況下，你應該盡量保證面試流程的統(tǒng)一。如果你不能讓面試看起來像是工作，至少讓每次面試都遵循相同的流程體系，并且在相同的指標上比較候選人。

幫助候選人達到最佳狀態(tài)

一套標準統(tǒng)一，方法科學的面試流程也可以進行靈活的調整。每個候選人都有不同的要求，不必為了標準化，被一些與面試指標無關的事項損害到個人或者團隊。例如，免疫力較低的候選人要求選擇遠程面試以保證他們的健康；有身體或者神經疾病的候選人期望分段面試以便休息，而不是一場三小時的面試馬拉松，這樣他們可能會表現(xiàn)得更好；一些有面試焦慮的候選人可能需要在面試前一兩分鐘與面試官建立友方關系，而對于其他人來說，他們寧愿跳過這部分閑聊環(huán)節(jié)。你應該始終根據(jù)候選人的需要來調整面試的環(huán)境或者節(jié)奏，像這樣的調整是雙贏的，因為這樣讓每個候選人都有機會展示出他們最佳的狀態(tài)。如果你想找到最好的候選人，你就需要根據(jù)他們的最佳狀態(tài)來判斷。

此外，面試也是一個雙向選擇的過程，你在評估候選人，候選人也在評估你的公司和團隊。如果因為候選人提出一些要求，而這些要求不在標準流程之內就拒絕他們，那是得不償失的。

你希望獲取到客觀的、可比較的面試指標，候選人則希望獲到合理的便利和幫助，那么如何調解這對矛盾呢？可以采用軟件設計上的一條著名規(guī)律，即穩(wěn)健性原則："對自己的工作要保守一些，對別人接受的事情要開放一些"。在面試中應用這一原則，那么你應該在標準化和相關技能的考察方面表現(xiàn)得保守，而在候選人需要幫助的方面表現(xiàn)得自由開放一些。這樣，兩全齊美，你既能獲取到想要的指標數(shù)據(jù)，候選人的表現(xiàn)也不會被不必要的條條框框限制住。

總結

經過數(shù)十年的研究表明，結構化的、真實的、聚焦工作內容的面試才是黃金法則。所以，當你決定使用計劃外的面試流程，或者某些無法量化的評估指標時，你應該問自己，我是不是想選出一位不合適的候選人。

當然，有時候仍然會看走眼，讓不合適的候選人混水摸魚，但這是無法避免的事。最好的面試機制也只能保證結果大部分是準確的。所以不要害怕偶然的失誤，而再依靠直覺去評估候選人，計算機還偶爾會死機呢，但人們能回到手寫筆算的時代嗎？

科學的招聘機制也許是公司相對于競爭對手而言最大的優(yōu)勢，而要做到這一點，最佳的途徑就是專注于你能考核能量化的指標。

譯者介紹

李騰輝，51CTO社區(qū)編輯，目前在一家東南亞互聯(lián)網金融獨角獸擔任資深Java工程師，負責金融借貸平臺架構設計及核心建設工作，對互聯(lián)網金融架構、微服務體系有較深入的研究，期望在互金領域持續(xù)深耕。

原文標題：The science of interviewing developers，作者：Isaac Lyman

鏈接：

https://stackoverflow.blog/2022/05/23/the-science-of-interviewing-developers/