編者按：多年以來，白板面試已經漸漸變成了行業入門的標準。那究竟什麼是白板面試呢？這其實指的是在面試時不依賴外部參考，直接在白板上手寫程序。Google、Amazon等知名科技公司都在採用白板面試的方法面試應聘者。然而，業界對於白板面試卻有諸多吐槽。究竟白板面試存在哪些問題呢？業界在僱用人才時又能採取什麼其他的替代方案嗎？本文編譯自Medium平臺上原文名為《Let’s talk about whiteboarding interviews and the possible alternatives》的文章。
白板面試在業界被詬病已久，這已經不是什麼新鮮事兒了。
不管是在Twitter、Medium還是LinkedIn上，你都能很容易地找到大家對此的諸多吐槽和抱怨。「招聘流程已然崩潰」的說法被頻繁使用，以至於大家覺得這都是套話了。
不幸的是，業界對這種面試方式的不滿並未得到應有的重視。
儘管大家異口同聲地表示出對白板面試的憤怒，「白板」依舊是軟體工程師崗位面試時採用的主要方式。部分原因也許在於，開發者們雖然能迅速表達自己的憤怒，但卻不能及時提供更優的替換選擇。
那有什麼更好的替代方案嗎？
最近，這一問題一直盤桓在我的腦海裡。四周前，我獲得了第一份全職軟體工程師的工作。雖然我還沒有參與招聘流程，但我最終會去參與的。
一個月之前，我還是求職者的身份，我很清楚面試流程有時候會有多不靠譜。未來輪到我參與招聘的時候，我希望自己能夠準確且客觀地評價我未來的同事。
這種尷尬的處境讓我開始思考如下兩個問題：
1. 白板面試是最佳選擇嗎？
2. 如果不是，那有什麼更好的替代方案嗎？
在本篇博文中，我將對上述兩個問題進行闡述。有一點要說明，這是基於我自己面試經歷總結出來的個人觀點。
我會採用一種真正意義上的軟體工程式解決方案去應對這個問題，達到儘可能得客觀：審視所有選擇並且權衡利弊。
白板面試是最糟糕的選擇嗎？
解決此問題的第一步就是要仔細審視白板面試的利弊。
優點：
1. 快速且不用投入太多精力。
2. 不限定特定語言或領域。
3. 你（通常）知道預期結果是什麼樣的。
4. 社區支持（Glassdoor、LeetCode、Pramp等）。
缺點：
1. 運氣是很重要的元素（算法博彩）。
2. 不一定會測試工程能力的高低。
3. 偏向年輕的工程師和應屆畢業生。
對於需要工程師熟練掌握CS基本知識、對算法要求不高、不依賴於多Library庫工程的公司來說，白板面試是最合適的選擇。
SpaceX、MacOS/Windows以及Facebook的React都是由這類工程師開發的。如果你是想在這些公司求職，那麼你很有可能會碰到白板面試。
作為求職者，我很喜歡白板面試。我知道面試內容大概是什麼。大多數的算法問題都是關於以下這幾個內容：
Arrays/Strings （數組/字符串）Binary Trees （二叉樹）Linked Lists （鏈組）DFS/BFS （深度優先算法/廣度優先算法）Backtracking （回溯法）Dynamic programming （動態規劃）
提前知道這些就意味著我可以有針對性地進行學習。還有很多學習工具可供選擇。事實上，技術性面試準備已經「自立門戶」，形成一個專門的行業了。
可也正因如此，白板面試並非適用於所有公司。面試成功與否很大程度上歸結為運氣、記憶力以及能否花大量時間進行學習。
並非所有人都能為了掌握算法持續這麼長時間的學習。
我很幸運自己能夠做到這一點，並在競爭中脫穎而出。但我比其餘所有的工程師都優秀嗎？可能吧，但我並不確定白板面試是否是揭露誰是優秀工程師最好的方式。
如果我們開始質疑白板面試的效用，又有哪些更好的替代方案呢？
讓我們來了解一些替代方案吧。
通過電腦進行編程挑戰
優點：
1. 可以使用電腦，獲得一個熟悉的開發環境。
2. 可以通過共享屏幕遠程完成編程挑戰。
3. 擁有白板面試的所有優點。
缺點：
1. 對句法和代碼運行能力要求要為嚴苛。
2. 編程環境以及插件會起到重要影響。
3. 和白板面試一樣的缺點。
與白板面試相比，在筆記本電腦上進行編程挑戰沒什麼太大差別，它沒有前者那麼嚴苛。
求職者可以使用自己的電腦。他們還可以遠程參與編程挑戰或結對編程。
我注意到編程挑戰通常比白板面試要簡單一些。我在面試過程中被提問的大部分問題都涉及到字符串處理或是簡單的算法，任何有經驗的工程師都不需要專門為此花時間進行學習。
這種方式的缺點在於過多強調實用性。
在我找工作期間，我碰到過兩次Coin Change （硬幣找零）的試題。一次是在白板面試中，還有一次是在編輯器中。
在白板面試中，我主要是去解釋我的解決方案。在我的筆記本電腦上，我需要寫出邊界情況的測試並且保證我的解決方案是有效的。
我之所以喜歡白板面試，部分原因也是在於它的寬容性。沒人會去用編譯器運行你寫的函數。只要面試官能理解你的思路，編程看上去沒太大問題，你就能得到滿分。
但是編程挑戰就不同了。
有些人也許會說，強調實用性更好，這是因為我們工程師就是拿錢做事。這一論點沒問題，但公司支付我們薪資，並非是要求我們在30-45分鐘之間內完成任務呀。
還是祈禱你在面試的時候不會緊張吧。一個很小的bug可能會導致測試失敗或是需要你花費好幾分鐘時間修補漏洞，這很可能就決定了你是否能通過面試。
編程挑戰和白板面試也面臨著相同的問題，它們大多都是基於算法的。
鑑於實用性帶來的附加壓力，即便你是在熟悉的開發環境下，問題也很有可能會變得很複雜。如果你本身就不喜歡算法問題，編程挑戰也不比白板面試更好。
帶回家完成的測試
優點：
1. 你可以穿著睡衣幹活。
2. 通常會給一周時間完成項目。
3. 可以使用自己的編輯器和開發環境。
4. 這可以成為一個新的代表作品。
5. 通常比白板面試更有趣。
缺點：
1. 難度梯度可能會發生大幅變動。
2. 相比編程挑戰，這往往要花費更多時間、投入更多精力。
3. 可能會受限於特定領域語言。
4. 由於競爭，可能會導致功能蔓延。
5. 並不能代表每天的工作情況。
很多工程師都喜歡回家完成測試。任務上交的時間節點通常較為靈活，求職者也可以在真正意義上進行編程。與站在白板前寫代碼並被別人無聲評判相比，程式設計師會喜歡這種方式也不出為奇。
但是，回家完成測試也有很大的弊端。
首先，這種測試易於控制。
許多公司都是在GitHub舉辦測試的。在GitHub搜索框中輸入「挑戰」或「測試」，你能得到很多測試信息。一些精明的求職者就能擁有大量時間去事先進行調查研究，從而搶佔先機。
這並非是抱怨，更多算是一種提醒。
真正的問題在於，你很容易找到參與挑戰的其他選手的答案並且進行複製。很多工程師都會在GitHub主頁上保留自己回家測試的結果。
你甚至可以自己試一試。在GitHub搜索框裡輸入「<XX公司> Challenge」，看看你能得到什麼搜索結果。
我住的地方很靠近Etsy在布魯克林的總部，我好奇自己能不能找到這家公司測試的一些答案。搜索「Etsy Challenge」，顯示出有四個結果。如果你搜索「Etsy Test」，你會得到更多搜索結果。
誠然，公司也會更改自己的測試項目。但由於細節信息的洩露，隔幾個月就要更換一次面試流程，這也是挺麻煩的一件事。
其次，完成這些挑戰所需花費的時間和挑戰難度也存在很大差異。
在我上一次找工作的時候，我需要回家完成四份項目。有三家公司都表示它們給的項目只需要花費3-5個小時即可完成。
但是每一個項目，我都花費了好幾天時間。
之所以會這樣，主要原因在於這些挑戰都是針對特定領域的。這需要你花費數小時時間搜索應用程式接口文檔和新技術。
第四家公司的挑戰本可以在一周時間內輕鬆完成，但它只給了我兩天時間。我需要開發一個支持斜槓命令（slash command）的聊天應用程式。
這是一個很有意思的項目，但為了完成它，這兩天時間內我需要放下其他事情，專心完成測試。
如果一個求職者足夠幸運，能夠同時面試多家公司的話，那麼光是完成這些挑戰就可以相當於是一份全職工作了。
此外，職業開發者們還需要處理遺留的代碼庫並且在截止期限前完成任務。一周長的新項目並不能很好地評判求職者在快節奏的環境中表現情況如何。
總的來說，我喜歡將回家完成測試作為最初檢測求職者能力的方式。不過任務內容必須與求職者申請的崗位相關，且任務完成時間不能過長。
基於項目或是合同對租賃
優點：
1. 有機會和求職者/團隊共事。
2. 帶薪工作。
3. 能夠接觸到真實的項目。
3. 公司會基於你和團隊的合作情況對你進行評定。
缺點：
1. 耗時長。
2. 沒有就業擔保進行工作。
3. 作為承包人沒有醫療保障福利。
4. 在談判中將求職者置於不利地位。
基於項目的面試很少見，但是有不少公司是選擇這種方式的，比如說Basecamp以及Automatic。我能理解它們為什麼採取這種方式。
這種面試可以最為準確地評判一個人的技能並且可以由團隊成員進行評價。公司會直接和這部分求職者共事，觀察他們是如何應對團隊中的任務的。
求職者也有機會了解公司並決定這種環境是否是自己喜歡的工作氛圍。
雙贏。乍看上去似乎是如此。
不過說了這麼多，作為求職者，我絕對不會參與基於項目的面試或去任職合同對租賃崗位。這種方式弊遠大於利。
任何工作的頭幾個月都是最艱難的。你要適應一個新的團隊、新的文化、新的代碼庫。現在想像一下你在不知道自己最終能否獲得工作的情況下做項目，那是什麼感受。
我的一個好朋友最近參與了Automatic的面試並表示壓力很大。從你和同事的相處方式到你問的問題，一切都會被別人評判。在這樣的環境下，你就會問出一些「愚蠢的問題」。
更糟糕的是，在三個月之後，他就被開了。還好，這事沒能影響他的自尊心。他很清楚自己的能力，並且會鼓起勇氣繼續前行。我不確定自己或是很多其他工程師能否和他一樣如此坦然接受這件事。
此外，合同也讓求職者在談判過程中處於一個不利的地位。原先，談判中的一個籌碼就是你可以選擇離開。
而在合同對租賃到期時，求職者已經沒有什麼談判的籌碼了。他們手頭上也沒有其他公司給的offer。他們已經為了項目投入了數十個甚至於數百個小時的時間（取決於合同周期）。
即便這不是他們理想的選擇，其他人也會鼓動他們去爭取這個職位。還有一個選擇，那就是重新回到求職大軍中去。
這一點是沉沒成本悖論的最佳詮釋（如果人們已為某種商品或勞務支付過成本，那麼便會增加該商品或勞務的使用頻率，這一定義強調的是金錢及物質成本對後續決策行為的影響）。
也許白板面試不是最理想的選擇，但在我選擇嘗試基於項目的面試之前，我寧願先參加個一百次白板面試再說。
那麼到底哪一種方式是軟體工程師崗位面試的最佳選擇呢？
答案你也許已經猜到了，那就是：視情況而定。
利弊權衡似乎主要是圍繞速度、精力以及準確性。每一種方式都或多或少得捨棄了某個方面。這其實還是取決於各個公司自己對利弊的評判。SpaceX和紐約的小型初創企業相比，面試流程肯定是不一樣的。
有一點是毋庸置疑的，那就是SaaS公司如果想要評判工程師的技能，那就只需要讓求職者寫出動態規划算法即可。它們不必跟風谷歌。
如果我要為DigitalOcean裡自己的團隊設計招聘流程的話，那我就會結合回家完成測試以及編程挑戰/組隊練習。我會通過提問環節以及系統設計挑戰來評估他們對於可利用性以及分布式系統的理解。
好消息是，我的團隊已經開始這樣做了。DigitalOcean的面試流程雖然不簡單，但還算公平，這也是我選擇接受其offer的原因。事實也表明，他們已經完成了自我審視的步驟，找到了公平評估求職者的方法。
如果你有什麼喜歡的面試方法，也可以在評論中告訴我。
最後，對於那些期待面試流程發生變動的程式設計師來說，你們可以試著提出一些新的想法。我見到很多程式設計師沒完沒了得抱怨白板面試，但在拿到工作offer之後也不曾想過做出改變——因為需要耗費諸多精力才能改變這一流程。
千萬別成為這樣的人。
停止抱怨。
找到解決方案。
編譯組出品。編輯：郝鵬程