技術面試時，程序員需要什麼樣的編程測試？

良好的招聘流程抵萬金，本文中就來和你探討下如何設計招聘流程，以及聰明的僱主應該避免哪些做法。

作者 | Mike Hearn

譯者 | 彎月，責編 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下為譯文：

在論壇Reddit的/r/ programming板塊上，有200多萬名成員。其中大多數帖子只是一些評論，熱門的帖子有多達100-200條的評論。但是搜索「面試」（interview），你會看到更多的帖子。

https://www.reddit.com/r/programming/

許多開發人員都很反感編程測試，上面的所有文章都對於應聘軟體工程師時必須進行編程測試的現狀感到悲痛，沒有任何一個人敢站出來為這種做法辯護。

但在本文中，我打算討論一下如下方面：

• 編程測試的必要性；

• 列舉一些最好避免的常見做法；

• 解釋為什麼面試中總是會出現一些毫無意義的演算法題，而不是「真正的」編程。

在我的職業生涯中，我面試過300多位開發人員，而且還設計了現在公司的主要面試流程，所以我覺得在這個主題上我還有一些話語權。我們的團隊每天都會面試開發人員，良好的招聘流程抵萬金，所以本文並不是教你如何設計招聘流程，本文只想探討一些候選人厭煩的做法（而且他們的這種情緒合情合理）以及聰明的僱主應該避免哪些做法。

首先，我們公司如何招聘？目前為了構建以開源比特幣為基礎的分散式資料庫，我們正在全球各地招聘各個技術崗位的人員。首先，在開發人員的面試過程中，我們會要求你快速審核一段代碼（大約5分鐘），接下來是30-60分鐘的視頻面試+屏幕共享，你可以從自己家中接受面試，並用你喜歡的編輯器和語言編寫一段代碼，最後是面對面的面試——與團隊和高級管理層的面試。有時編程測試還包括設計和「探討」問題，具體取決於候選人的背景以及工作崗位：這部分的面試不僅僅是編程。我們認為這套流程非常奏效，而且效率很高（至少與某些招聘流程相比！）。

注意：本文中提到的問題都不是我們會在實際中提問的問題，只是想給你一個大致的印象。

首先，讓我們來看看面試中應該避免哪些方面。

面試官應該避免哪些方面

雖然有些公司會在招聘流程中採用如下方式，但我不建議這樣做：

• 「機器人面試」與自動評估。沒有人喜歡成為一名面試官，所以很多團隊希望將招聘的工作外包出去。但是我們非常簡短地嘗試了一下這種做法，結果證明這種方法根本無法與人為的評估相提並論，更重要的是，要求候選人參加面試時尊重他們寶貴的時間是一種基本的禮貌。我感覺要求候選人拿出時間來參加面試，而公司卻沒有付出相同的時間，這本身就是不尊重對方。面試官花一個小時與候選人面試，表明他們非常重視對方和自己的時間。通過「面試考題」網路應用自動化不可靠的面試，只會讓你付出另一種代價。我們感覺高級工程師都會（肯定會）拒絕做這種面試。

• 白板面試。雖然多年來這種做法被廣泛採用，但是如今筆記本電腦和屏幕共享無處不在。更為自然的編程是在編輯器上，通過鍵盤，並藉助搜索引擎和編譯器。通過視頻通話的面試可以讓候選人使用自己的工具，在家中使用自己的計算機進行編程。遠好過站在一個小小的會議室里，讓某人用白板筆寫代碼。

• 一整天的面試。許多公司希望對開發人員進行一整天的面試，通常需要5-8次單獨的面試，這對於有工作的開發人員來說太難了。相反，利用午休時間進行遠程的面試，就不需要候選人請假了，所以他們更有可能完成整個過程。我個人認為，8次面試也不一定會比兩次面試的結果更好。

• 大規模的編程任務。雖然最近我們也開始要求候選人先做一個簡單的編程任務，但是這個任務不涉及編寫任何代碼，可以在幾分鐘內完成。我聽說有些公司要求考生在面試時間之外，寫真正的一套代碼。同樣，這也不尊重對方的時間，很多人會拒絕這樣做。

• 臨場提問。設計提問的問題很困難，你希望候選人做好準備，不是嗎？因此，你也應該做好準備。

• 修改真正的bug或實現真正的功能。顯而易見如果候選人沒有授權的話，你會陷入版權的問題，除此之外你也沒辦法重複這個任務，沒辦法確保問題總是合時宜，也沒辦法確保你可以看到良好的編程技巧的範圍（例如，該功能可能只需要複製/粘貼一些現有代碼，然後做輕微的改動）。而且你只是為了現有的Java代碼庫而招聘Java開發人員，或為現有的Ruby代碼庫而招聘Ruby開發人員：如果你僱傭熟練的開發人員，讓他們在工作中學習工具，那麼這種面試就沒有任何效果。

上面是招聘中應該避免的一些方面，但在實際的面試中，我們還是應該讓開發人員現場編程。下面讓我們來談談為什麼這個要求雖然不受歡迎，卻很普遍。

許多候選人不喜歡編程測試。有人矇混過關，還有由於面試題設計糟糕而引發大量誤解，從而導致候選人憤恨不平。沒有人喜歡因為刻板的面試過程而導致他們無法展現自己真正的技術力。

Google：90%的工程師在使用我寫的軟體，但我卻因沒能在白板上解出一道二叉樹的問題而被拒。

明明知道自己可以勝任，卻慘遭拒絕的經歷會給心理帶來沉重的陰影，特別是當面試的過程宣稱很科學很準確的情況下。

因此，不採用這種面試方式，而採用比較傳統的談論以往經驗的公司可能會佔據優勢。然而，從微軟等公司流行起來的編程測試已經成為了普及度很高的標準，而且現在很少有軟體公司可以僅憑電話面試就下offer。這是為什麼？

編程測試的必要性

看著實習生鼓起勇氣參加第一次編程測試，我總是覺得很有趣。首先是亮晶晶的大眼睛，無辜震驚的表情，然後咆哮。

候選人怎麼可能用一種語言開始編碼，中途才發現他們不了解這種語言，應該用另一種語言從頭重新開始呢？在簡歷中寫明有10年經驗的人怎麼可能不會用自己的編輯器建立一個新項目呢？候選人怎麼可能花30分鐘生成隨機數，卻以失敗告終呢？這太不可思議了！

經歷過這些歷史時刻的前輩笑了，他們會告訴你：「並非不可思議。讓我給你講個故事吧……」

在20世紀90年代，微軟推出了科技行業的結構化面試，該流程就是著名的腦筋急轉彎「為什麼下水道的井蓋是圓的？」以及編程難題，例如「在白板上用C語言反轉鏈接列表」。Joel Spolsky根據微軟的流程撰寫了一篇關於這種面試形式的文章「軟體人員面試教戰守則」（https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/）。2000年這篇文章發表後，該流程很快就被很多創業公司採納，其中就有一家名叫Google的小公司。

Joel Spolsky反思微軟推動的世界趨勢。這是非結構化面試的一大進步，但他並沒有滿足於此。不幸的是，他提議的替代方案是適用於招聘實習生。

但我認為，Imran Gohry提出的FizzBuzz問題（https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/）助長了這種面試流程的人氣，同時2007年Jeff Atwood的博文「為什麼程序員無法編程？」（https://blog.codinghorror.com/why-cant-programmers-program/）也引起了廣泛的關注。Jeff在他的博文中說：

任何事都有個開始。但令我感到不解和震驚的是，所謂的程序員申請工作的時候，卻無法編寫最簡單的程序。對於那些以軟體為生的人而言，這無疑是一記響亮的耳光。

Dan Kegel是一位曾與我在Google以及在Wine項目中共事的受人尊敬的同事。2006年，他在「如何招聘」一文中說：

大多數申請人，即使是那些擁有碩士學位和計算機科學博士學位的申請人，在面試中編寫基本的程序時也會失敗。例如，我在面試中遇到過的畢業生答不出：「寫一個從1到10的循環」或「用十六進位表示F後面的數字是多少」等問題。

負責面試的開發者們很容易把這些故事寫的很誇張，因為這樣可以顯得他們比接受面試的人更強。我想在這裡澄清事實並非如此，每個負責組建團隊的人很快就會習慣那些非常善於面試卻連最簡單的程序都寫不出的人。

人們普遍認為，公司之所以會進行編程測試，是因為他們喜歡迷戀演算法的書獃子，他們想找到最具學術精神的候選人，並希望成為下一個Google。然而事實並非如此。各個公司之所以會進行編程測試，是因為他們遇到過許多面試候選人紙上談兵的本領很強，但卻無法按照要求編寫出程序。完全不行。

如果你是一名求職者，那麼做到下列幾項就可以讓你脫穎而出：

• 如果你懂一門編程語言，那麼就在面試中使用這門語言。我猜在簡歷中寫明懂C++的候選人中，有50%都拒絕在面試的時候編寫程序（但是他們願意使用更簡單的語言）。

• 掌握開發工具。如果你是Java開發人員，那麼就應該知道如何在你選擇的IDE中創建新項目，編寫一些代碼，運行代碼，然後展示程序創建的輸出。你還應該知道如何編寫和運行測試，以及使用調試器。

• 如果對方要求你帶自己的工具參加面試，那麼就照做。不要在面試的過程中安裝東西。

• 掌握基礎知識：集合、輸入輸出、字元串操作、循環、數據類型。如果你是一名優秀的程序員，那麼就知道實際應該掌握哪些知識（我面試過的Scala程序員在面對一個非常明顯的問題時全軍覆滅。）

• 掌握你打算在面試中使用的語言。不要因語法或類型安全的普通錯誤而陷入困境。

如果你覺得上述都很基本，那麼就歡迎來開發人員面試的世界來看看吧。

編程測試很重要的原因還有一個。技術嫻熟的工程師都明白這個問題，而且他們不想加入一個隨便什麼人都能進的團隊。強大的招聘流程不僅僅是候選人給面試官留下好印象的機會，而且也是候選人感受面試官的機會。有些與我合作過的優秀人才之所以被他們的工作吸引就是因為面試非常有難度。在效率、漏掉優秀的人才以及有人矇混過關之間尋求平衡是構建軟體公司的藝術。

儘管如此，大多數從候選人的角度寫的糟糕的面試故事其實都不是來自那些面試失敗的人。大多數人對編程測試感到惱火，是因為他們覺得他們在面試中需要解決繁瑣且沒有意義的怪問題。

為什麼演算法問題必不可少？

編寫排序函數，反轉二叉樹，圖搜索。

求職面試讓人感覺又重回了大學。這麼多年來實際編程的經驗突然間都被拋到腦後，就好象你再次坐在演講廳里，證明你對理論課程的掌握，實際上這些問題已經早就讓那些喜歡閱讀高德納的開發人員解決了。

我在討論區見到的最常見的解釋就是老闆是白痴。其次最常見的解釋是，老闆們都希望成為Google，而Google確實需要計算機科學專家，而其他公司都不需要。但無論如何，這些公司都採用了Google的招聘流程，並希望藉此成為億萬富翁。

其實，真正的理由很簡單。當你坐下來為開發人員撰寫面試問題時，你必須滿足許多限制才能寫出一個好問題。而滿足所有這些限制的問題最後往往都看起來像「演算法」問題。

面試的目的是儘快獲取候選人的信息。一個好的面試問題並不一定要代表日常工作。為了解釋清楚這一點，想像一下飛行員的面試。在有了基本的了解之後，理應詢問候選人在各種緊急情況下該做什麼。緊急情況並不代表飛行的日常工作，但安全很重要，因此沒有人會指責面試官提出無關緊要的問題。然而，在軟體面試中卻出現了這樣的問題。

既然我們的目標是儘快獲取候選人的信息，那麼我們的限制是什麼？

首先，要完成的程序必須短小精悍。除非你想整個面試就問一個問題，否則這個問題應該是一個稱職的開發人員在30分鐘內完成的問題。30分鐘你根本寫不了多少代碼。這重限制已經排除了大多數能帶來實用價值的「真實」程序。

其次，這個程序必須單獨完成，沒有複雜的設置或網站特定的知識。花費在解釋問題上的時間每多一秒，候選人展示技術力的時間就少一秒。有時我看到網上論壇里有人評論說：「這個公司是傻X，他們使用的是標準的商業網路應用程序，卻不讓我寫REST API，非要讓我編寫自己的排序函數。」但是編寫一個「寫一個REST API」形式的問題，並通過這個問題實際驗證候選人能否成功通過面試，這項工作非常困難。這個API應該幹些什麼？數據從哪裡來？你是希望連接到某個資料庫，還是通過文件提供數據，抑或者將其保存在內存中？等等。理想情況下，面試的問題應該在30秒以內解釋清楚。有些公司確實會提這樣的問題，但他們只想招聘懂得特定選擇框架的開發人員，而且該框架已經自動完成了所有的樣板代碼。但在我們公司，我們想招聘各種背景和專業的開發人員，因此我們必須堅持在沒有任何特定框架或技術的情況下，仍然可以照常回答的問題。

第三，這種方法實際上可以表現出候選人是否懂得編程。編寫幾個返回一些假HTML的函數不能證明什麼，但至少證明候選人可以使用循環、集合、類、以及輸入輸出，還熟悉他們的標準庫（我的意思是大致了解編程技術，而不是說他們記住了每個API）。

第四，這種方法可以給優秀的候選人提供脫穎而出的機會。上述我提到的基礎看起來可能非常基礎。但這並不意味著我們公司的門檻很低。一個良好的編程測試問題需要掌握一定的深度，讓優秀的候選人可以快速高效地創建一個比新手更好的解決方案。面試官通過了充分的練習，即使每個人面對的都是同一組問題，他們也知道如何區分經驗豐富的開發人員和初學者。

最後，你需要一些證據，證明候選人可以解決一個沒有明顯解決方案的問題，讓他們自行思考答案，而不是手足無措。這類問題的具體性質並不重要，只需保證候選人無法用以前見過的方法解決。這是面試過程中最模糊的部分：這對測試候選人的思維能力有什麼真正的意義？這也是排除「利用他人的代碼解決我的問題」的方法，儘管這常常是實際工作中的正確方法。

簡短、易於解釋、僅使用基本語言功能，解決方案既可以是最基本的，也可以有一定的深度，而且還不至於千篇一律。我認為所有這些都是招聘到一個稱職的團隊成員的基礎問題，但是滿足這些條件的問題必然最後會成為沒有代表性的演算法難題。這些問題的目的不是想要考察你是否真的記得計算機科學課程中晦澀難懂的演算法（你可能永遠也不會在實際工作中使用），而只是為了讓你編寫一些包含大部分基礎知識的代碼的契機。

所以不要過於關注你的答案是否具有理想的計算複雜性，至少在第一次嘗試中沒必要。面試官可能並不在意。相反，你應該快速出色地編寫乾淨且沒有bug的代碼。然後，如果有多餘的時間的話，再去優化。

總結

由於缺乏全球認可的認證機構以及對具體技術技能的需求，招聘開發人員的過程比某些專業更為嚴格。

多年來，從僱主的角度來看，招聘的流程已經得到了極大的改善。對於那些習慣於這種面試的候選人來說，這種方式可以招聘到更均衡的團隊，避免有人濫竽充數，儘管有關這種方式的抱怨也很普遍。

儘管如此，我依然看到無論我們在該行業中付出多大的努力，招聘仍然具有很大程度的隨機性。經過精心設計的面試流程可以改善這種隨機性，這也是我們的努力方向。但是，鑒於解僱一個不合格的人的成本之高，漏掉優秀的人才總好過讓人矇混過關，因此才有了這些面試的悲慘故事：一些有真正實力的人才因為機械的流程而被拒。正如Spolsky提出的面試實習生的替代方案一樣，儘管這種流程存在各種缺陷，但也是一個無人能及的系統。

原文：https://blog.plan99.net/in-defence-of-the-technical-interview-966f54a58927

本文為 CSDN 翻譯，轉載請註明來源出處。

【End】

2019.8.9-8.11（周五-周日），華為將於廣東東莞舉行<HDC2019> 華為開發者大會！全球開發者歡聚今夏！5G落地，萬物互聯升起！華為鴻蒙新進展亦會揭曉！在這個最好的時代，我們期待與你共同譜寫全場景智慧化的新篇章！早鳥票298元起！購票請掃描下方二維碼。

?IoT 打響安防保衛戰！

?Mac 被曝存在惡意漏洞：黑客可隨意調動攝像頭，波及四百萬用戶！

?如果微軟開發了 Android，會有何不同？

?FreeWheel是一家怎樣的公司？| 人物誌

?長點心吧年輕人，利率不是這麼算的！我用Python告訴你虧了多少！

?乾貨 | 20個教程，掌握時間序列的特徵分析（附代碼）

?Libra 騙局來了! 受害者會是你嗎?

?實測！華為鴻蒙比 Android系統快60%！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！