“谷歌式”面試真心是讓人又愛又恨，它糟糕透了：好的應聘者落選，壞的應聘者背背答案就能通過，呵呵。

這是真的。

但是，這也是真的：所有的面試過程都很糟糕。

以往的經(jīng)驗

論點：“我們應該根據(jù)他們以往的經(jīng)驗來決定要不要聘用他們。他們以往的成就？他們給曾經(jīng)就職的公司帶去了哪些價值？這才是肯定他們是否優(yōu)秀的最好的辦法。”

問題：

• 你不是在根據(jù)他們曾經(jīng)的行為做判定，而是在根據(jù)他們?nèi)绾蚊枋鲎约旱男袨樽雠卸ā＃ㄟ@類問題的回答是可以通過培訓的。相信我，我已經(jīng)教過很多人，讓這些原本很有可能會以失敗告終的應聘者成功上任。）

• 應聘人員可能會夸大他們做的事情，使其聽起來更令人印象深刻。

• 應聘人員可能不會將他們的所做的成績歸功到自己身上（將功勞推給團隊，或者沒有很好地說明項目為什么很難）。特別是女性和負責人更趨向于將他們的個人成就歸因于團隊，雖然原因各不相同。

最佳做法：

• 談得更深。不接受表面化的答案。

• 關于開發(fā)中的個人貢獻，要重點關注技術挑戰(zhàn)，而不是關于領導力，沖突等方面的問題。要注意回答者說話的藝術，因為哪怕其實個人貢獻并不大，也可以把話說得很漂亮。

引薦

論點：“你應該聘請被引薦的人，聘請那些同事推薦的人。但是請確保一定要徹底檢查這些引薦。”

問題：

• 只雇用你曾經(jīng)共事過的人無法很好地規(guī)?；?。

• 一個平庸的應聘人員也可以讓其他人幫他講好話。這就會導致我們無法去偽存真，所以你不能冒險使用這樣的招聘策略。

• 如果應聘人員還在職，你也不能和他們目前的雇主對質(zhì)。

最佳做法：

• 審核推薦信。要保持懷疑的態(tài)度?？赡苓@個應聘人員很棒，但他的推薦信上面啥也沒說。也有可能一個平庸的應聘者卻有著好話連篇的推薦信。

• 如果是現(xiàn)任員工的推薦，也不要冒險啟用。還是先驗證了他與大家之間能否密切合作再說。

Github&作品樣本

爭論：“查閱應聘人員的Github或作品樣本。這種方式可以讓你知道他們真正能做什么，以及他們在現(xiàn)實世界中是如何工作的。”

問題：

• 不能擴展。很多人不愿意投入工作以外的編程工作，或做了，但并不想公之于眾。

• 容易排除和忽略女性開發(fā)人員。她們肩負著更多的家庭責任，因此往往沒有更多的時間投入到工作以外的編碼項目。

• 作品樣本展示的是當前的代碼質(zhì)量，看不出他們受到的培訓。許多人（尤其是那些經(jīng)驗較少或從來沒有工作于一家擁有嚴格的編碼指導原則的公司的開發(fā)人員）可能寫出來的代碼很馬虎。但這并不意味著他們就一定是糟糕的編碼人員。稍微培訓一下就可以改善他們的編碼風格。

• 這種方法很難識別智力/解決問題能力。

最佳做法：

• 可以看看他們的代碼，但是要有保留地接受對代碼風格的解釋。將根本性的問題從可修復的問題中劃分出來。

• 如果你有大量的招聘需求，那么就不要僅依賴這個條件。你會排除很多求職者。

• 要注意這種方法的局限，比如說看不到智力/解決問題的能力。

家庭作業(yè)

爭論：“要想評估他們的真正能力，可以給他們一個家庭作業(yè)或項目。這不但可擴展，而且模擬了真實情況。”

問題：

• 很多應聘人員不會去做長時間的家庭作業(yè)，特別是那些有著其他責任或其他工作選擇的開發(fā)人員。

• 求職者可以從朋友那兒獲取幫助，特別是如果碰到棘手的算法部分。所以不要指望他給你的成果可以真正代表他的能力。（這并不意味著你就不能使用這種方法，你只是不能完全依賴這種方式而已。）

• 和上面碰到的問題一樣，你無法知道應聘人員真實的代碼風格。

最佳做法：

• 公平對待應聘人員。平衡實用和時間的要求。如果你給的是一個時間較長的項目，它就應該在很大程度上可替代面試。請注意，這也意味著你會失去那些有著其他責任的應聘人員。

• 1-2小時這樣簡短的測試就非常好，就能夠用來剔除掉那些問題解決能力和編碼能力弱的開發(fā)人員。不過這可以作弊，所以在實際的面試中你也需要自我評估。

• 通過培訓和指導將編碼的根本問題從可修復的問題中區(qū)分出來。

知識

爭論：“開發(fā)人員需要具備一定的學識。如果不了解自己的領域，那就可能會導致出現(xiàn)大量的bug和其他有害之處。顯然的，知識和經(jīng)驗是有價值的！”

問題：

• 好的開發(fā)人員通常會在工作中去學習新的編程語言。如果你有輕松學習新知識的技能，那么你就能在眾多候選人中脫穎而出。

• 如果一個程序員標 榜自己是特定的編程語言使用者，那么他解決問題的能力通常更弱。所以這是一個糟糕的屬性。優(yōu)秀的開發(fā)人員不太愿意將自己定性為“Java開發(fā)者”或 “PHP開發(fā)人員”，更愿意自稱是開發(fā)人員。可能他們現(xiàn)在使用的是某種特定的語言，但是他們知道他們還會去學習下一種語言。（不過，他們可能會說自己是一 個前端開發(fā)人員或后端開發(fā)人員。）

最佳做法：

• 掌握知識是一個艱難的過程。如果你打算學習某種特定的語言或技術知識，那就應該去學習真正的專業(yè)知識。可以輕松掌握的知識通常是沒有用的知識，因為不但是你，其他人在工作中也可以學會。有一個例外是，缺乏基本知識會讓你的工作亮起紅牌。

• 評估一下你是否真的需要特定語言的專業(yè)人才。大多數(shù)中大型企業(yè)都是不需要的。因為開發(fā)人員會在工作中學習編程語言。所以其實你有足夠多的人才來滿足你的需要。

解決問題/算法+白板編碼

爭論：“想找聰明的開發(fā)人員。聰明的人才能做好開發(fā)工作。”

問題：

• 你希望應聘人員能夠具備某些關于數(shù)據(jù)結(jié)構(gòu)和算法的知識，雖然這些知識在實際工作中并不常用到。

• 很多應聘人員會提前學習很多內(nèi)容，因為他們知道面試要問的問題逃不出這些。在這種情況下，你其實評估不了解決問題的能力，因為你考察的只是重復回放算法的能力。

• 很多開發(fā)人員在面試時會很緊張。所以他們可能會面試失敗，即使他們或許真的可以依靠自己來解決這些問題。

• 白板編碼是不現(xiàn)實的。沒人會在白板上寫代碼，這種方式導致代碼人員犯一些在工作中不一定會發(fā)生的錯誤。此外，白板編碼又慢又讓人痛苦。

最佳做法：

• 你問的問題應該是具有挑戰(zhàn)性和不尋常的。不要問一些常見的問題。

• 面試官提出的算法問題不應該僅僅是正確性的問題。提出問題的目的是評估應聘人員解決問題的能力，所以如果你想真正見識他們的實力，應該看他們是如何解決難題的。不要提一些顯而易見的問題。

• 白板編碼非常慢，又會導致很多錯誤。不要讓應聘人員在代碼中寫一些對評估沒有用的細節(jié)內(nèi)容。你也可以提供筆記本電腦，如果應聘者覺得更舒適的話，當然這也有其不足之處。

• 不使用只有單一難點或障礙的問題。這樣才能多方位地考察應聘人員的實力。

• 想一些你希望應聘人員知道的數(shù)據(jù)結(jié)構(gòu)、算法和概念問題，并盡可能公平。二叉搜索樹和廣度優(yōu)先搜索就相對公平；實現(xiàn)紅黑樹則不是。此外，面試官提出的問題不應該超越大范圍知識。盡可能地讓那些不具備計算機科學知識（或已經(jīng)畢業(yè)很長一段時間）的應聘人員都有一個公平的機會。

• 知道什么時候你確實需要專業(yè)知識。有些技能是很難掌握的，即使那人真的很聰明。

都是糟糕的面試，那有沒有不糟糕的？

上面講述的所有的面試方法都有問題。是的，沒錯，都有問題。

很多頂級企業(yè)還大量采用算法式面試，當然許多其他公司也采用了別的過程方法。

但是，都很糟糕，都有問題。

那么……你能做什么？

接受一點：任何面試方法都是有缺陷的，都是糟糕的。

所以，我們需要找出最不那么糟糕的一種。然后好好實現(xiàn)。

這意味著：

1. 確定你需要哪些技能（掌握起來是否現(xiàn)實）。各個技能的權重？真正的問題？你能給予什么幫助？

2. 確定你如何（或者是否要）評估每種技能。什么樣的問題或方法會有效？（你也可以選擇多種方法。）

3. 這種方法有什么問題？如何減輕這些問題，至少部分問題？

4. 創(chuàng)建一個與這種方法保持一致的面試培訓計劃。

5. 通知應聘人員你的期望。他們需要知道自己將要面對什么。

這么做，雖然你的過程還是不夠完美——也永遠達不到完美——但絕對會比以前更好。

譯文鏈接：http://www.codeceo.com/article/programmer-broken-interview.html
英文原文：Developer Interviews are Broken, and You Can't Fix It