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

這是真的。

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

以往的經(jīng)驗(yàn)

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

問題：

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

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

• 應(yīng)聘人員可能不會(huì)將他們的所做的成績(jī)歸功到自己身上（將功勞推給團(tuán)隊(duì)，或者沒有很好地說明項(xiàng)目為什么很難）。特別是女性和負(fù)責(zé)人更趨向于將他們的個(gè)人成就歸因于團(tuán)隊(duì)，雖然原因各不相同。

最佳做法：

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

• 關(guān)于開發(fā)中的個(gè)人貢獻(xiàn)，要重點(diǎn)關(guān)注技術(shù)挑戰(zhàn)，而不是關(guān)于領(lǐng)導(dǎo)力，沖突等方面的問題。要注意回答者說話的藝術(shù)，因?yàn)槟呐缕鋵?shí)個(gè)人貢獻(xiàn)并不大，也可以把話說得很漂亮。

引薦

論點(diǎn)：“你應(yīng)該聘請(qǐng)被引薦的人，聘請(qǐng)那些同事推薦的人。但是請(qǐng)確保一定要徹底檢查這些引薦。”

問題：

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

• 一個(gè)平庸的應(yīng)聘人員也可以讓其他人幫他講好話。這就會(huì)導(dǎo)致我們無法去偽存真，所以你不能冒險(xiǎn)使用這樣的招聘策略。

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

最佳做法：

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

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

Github&作品樣本

爭(zhēng)論：“查閱應(yīng)聘人員的Github或作品樣本。這種方式可以讓你知道他們真正能做什么，以及他們?cè)诂F(xiàn)實(shí)世界中是如何工作的。”

問題：

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

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

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

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

最佳做法：

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

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

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

家庭作業(yè)

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

問題：

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

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

• 和上面碰到的問題一樣，你無法知道應(yīng)聘人員真實(shí)的代碼風(fēng)格。

最佳做法：

• 公平對(duì)待應(yīng)聘人員。平衡實(shí)用和時(shí)間的要求。如果你給的是一個(gè)時(shí)間較長(zhǎng)的項(xiàng)目，它就應(yīng)該在很大程度上可替代面試。請(qǐng)注意，這也意味著你會(huì)失去那些有著其他責(zé)任的應(yīng)聘人員。

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

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

知識(shí)

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

問題：

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

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

最佳做法：

• 掌握知識(shí)是一個(gè)艱難的過程。如果你打算學(xué)習(xí)某種特定的語言或技術(shù)知識(shí)，那就應(yīng)該去學(xué)習(xí)真正的專業(yè)知識(shí)。可以輕松掌握的知識(shí)通常是沒有用的知識(shí)，因?yàn)椴坏悄?，其他人在工作中也可以學(xué)會(huì)。有一個(gè)例外是，缺乏基本知識(shí)會(huì)讓你的工作亮起紅牌。

• 評(píng)估一下你是否真的需要特定語言的專業(yè)人才。大多數(shù)中大型企業(yè)都是不需要的。因?yàn)殚_發(fā)人員會(huì)在工作中學(xué)習(xí)編程語言。所以其實(shí)你有足夠多的人才來滿足你的需要。

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

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

問題：

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

• 很多應(yīng)聘人員會(huì)提前學(xué)習(xí)很多內(nèi)容，因?yàn)樗麄冎烂嬖囈獑柕膯栴}逃不出這些。在這種情況下，你其實(shí)評(píng)估不了解決問題的能力，因?yàn)槟憧疾斓闹皇侵貜?fù)回放算法的能力。

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

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

最佳做法：

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

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

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

• 不使用只有單一難點(diǎn)或障礙的問題。這樣才能多方位地考察應(yīng)聘人員的實(shí)力。

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

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

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

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

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

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

那么……你能做什么？

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

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

這意味著：

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

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

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

4. 創(chuàng)建一個(gè)與這種方法保持一致的面試培訓(xùn)計(jì)劃。

5. 通知應(yīng)聘人員你的期望。他們需要知道自己將要面對(duì)什么。

這么做，雖然你的過程還是不夠完美——也永遠(yuǎn)達(dá)不到完美——但絕對(duì)會(huì)比以前更好。

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