糟糕的程式設計師面試

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

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

這是真的。

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

以往的經驗

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

問題：

• 你不是在根據他們曾經的行為做判定，而是在根據他們如何描述自己的行為做判定。（這類問題的回答是可以通過培訓的。相信我，我已經教過很多人，讓這些原本很有可能會以失敗告終的應聘者成功上任。）
• 應聘人員可能會誇大他們做的事情，使其聽起來更令人印象深刻。
• 應聘人員可能不會將他們的所做的成績歸功到自己身上（將功勞推給團隊，或者沒有很好地說明專案為什麼很難）。特別是女性和負責人更趨向於將他們的個人成就歸因於團隊，雖然原因各不相同。

最佳做法：

• 談得更深。不接受表面化的答案。
• 關於開發中的個人貢獻，要重點關注技術挑戰，而不是關於領導力，衝突等方面的問題。要注意回答者說話的藝術，因為哪怕其實個人貢獻並不大，也可以把話說得很漂亮。

引薦

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

問題：

• 只僱用你曾經共事過的人無法很好地規模化。
• 一個平庸的應聘人員也可以讓其他人幫他講好話。這就會導致我們無法去偽存真，所以你不能冒險使用這樣的招聘策略。
• 如果應聘人員還在職，你也不能和他們目前的僱主對質。

最佳做法：

• 稽核推薦信。要保持懷疑的態度。可能這個應聘人員很棒，但他的推薦信上面啥也沒說。也有可能一個平庸的應聘者卻有著好話連篇的推薦信。
• 如果是現任員工的推薦，也不要冒險啟用。還是先驗證了他與大家之間能否密切合作再說。

Github&作品樣本

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

問題：

• 不能擴充套件。很多人不願意投入工作以外的程式設計工作，或做了，但並不想公之於眾。
• 容易排除和忽略女性開發人員。她們肩負著更多的家庭責任，因此往往沒有更多的時間投入到工作以外的編碼專案。
• 作品樣本展示的是當前的程式碼質量，看不出他們受到的培訓。許多人（尤其是那些經驗較少或從來沒有工作於一家擁有嚴格的編碼指導原則的公司的開發人員）可能寫出來的程式碼很馬虎。但這並不意味著他們就一定是糟糕的編碼人員。稍微培訓一下就可以改善他們的編碼風格。
• 這種方法很難識別智力/解決問題能力。

最佳做法：

• 可以看看他們的程式碼，但是要有保留地接受對程式碼風格的解釋。將根本性的問題從可修復的問題中劃分出來。
• 如果你有大量的招聘需求，那麼就不要僅依賴這個條件。你會排除很多求職者。
• 要注意這種方法的侷限，比如說看不到智力/解決問題的能力。

家庭作業

爭論：“要想評估他們的真正能力，可以給他們一個家庭作業或專案。這不但可擴充套件，而且模擬了真實情況。”

問題：

• 很多應聘人員不會去做長時間的家庭作業，特別是那些有著其他責任或其他工作選擇的開發人員。
• 求職者可以從朋友那兒獲取幫助，特別是如果碰到棘手的演算法部分。所以不要指望他給你的成果可以真正代表他的能力。（這並不意味著你就不能使用這種方法，你只是不能完全依賴這種方式而已。）
• 和上面碰到的問題一樣，你無法知道應聘人員真實的程式碼風格。

最佳做法：

• 公平對待應聘人員。平衡實用和時間的要求。如果你給的是一個時間較長的專案，它就應該在很大程度上可替代面試。請注意，這也意味著你會失去那些有著其他責任的應聘人員。
• 1-2小時這樣簡短的測試就非常好，就能夠用來剔除掉那些問題解決能力和編碼能力弱的開發人員。不過這可以作弊，所以在實際的面試中你也需要自我評估。
• 通過培訓和指導將編碼的根本問題從可修復的問題中區分出來。

知識

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

問題：

• 好的開發人員通常會在工作中去學習新的程式語言。如果你有輕鬆學習新知識的技能，那麼你就能在眾多候選人中脫穎而出。
• 如果一個程式設計師標榜自己是特定的程式語言使用者，那麼他解決問題的能力通常更弱。所以這是一個糟糕的屬性。優秀的開發人員不太願意將自己定性為“Java開發者”或“PHP開發人員”，更願意自稱是開發人員。可能他們現在使用的是某種特定的語言，但是他們知道他們還會去學習下一種語言。（不過，他們可能會說自己是一個前端開發人員或後端開發人員。）

最佳做法：

• 掌握知識是一個艱難的過程。如果你打算學習某種特定的語言或技術知識，那就應該去學習真正的專業知識。可以輕鬆掌握的知識通常是沒有用的知識，因為不但是你，其他人在工作中也可以學會。有一個例外是，缺乏基本知識會讓你的工作亮起紅牌。
• 評估一下你是否真的需要特定語言的專業人才。大多數中大型企業都是不需要的。因為開發人員會在工作中學習程式語言。所以其實你有足夠多的人才來滿足你的需要。

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

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

問題：

• 你希望應聘人員能夠具備某些關於資料結構和演算法的知識，雖然這些知識在實際工作中並不常用到。
• 很多應聘人員會提前學習很多內容，因為他們知道面試要問的問題逃不出這些。在這種情況下，你其實評估不瞭解決問題的能力，因為你考察的只是重複回放演算法的能力。
• 很多開發人員在面試時會很緊張。所以他們可能會面試失敗，即使他們或許真的可以依靠自己來解決這些問題。
• 白板編碼是不現實的。沒人會在白板上寫程式碼，這種方式導致程式碼人員犯一些在工作中不一定會發生的錯誤。此外，白板編碼又慢又讓人痛苦。

最佳做法：

• 你問的問題應該是具有挑戰性和不尋常的。不要問一些常見的問題。
• 面試官提出的演算法問題不應該僅僅是正確性的問題。提出問題的目的是評估應聘人員解決問題的能力，所以如果你想真正見識他們的實力，應該看他們是如何解決難題的。不要提一些顯而易見的問題。
• 白板編碼非常慢，又會導致很多錯誤。不要讓應聘人員在程式碼中寫一些對評估沒有用的細節內容。你也可以提供膝上型電腦，如果應聘者覺得更舒適的話，當然這也有其不足之處。
• 不使用只有單一難點或障礙的問題。這樣才能多方位地考察應聘人員的實力。
• 想一些你希望應聘人員知道的資料結構、演算法和概念問題，並儘可能公平。二叉搜尋樹和廣度優先搜尋就相對公平；實現紅黑樹則不是。此外，面試官提出的問題不應該超越大範圍知識。儘可能地讓那些不具備電腦科學知識（或已經畢業很長一段時間）的應聘人員都有一個公平的機會。
• 知道什麼時候你確實需要專業知識。有些技能是很難掌握的，即使那人真的很聰明。

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

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

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

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

那麼……你能做什麼？

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

所以，我們需要找出最不那麼糟糕的一種。然後好好實現。

這意味著：

1. 確定你需要哪些技能（掌握起來是否現實）。各個技能的權重？真正的問題？你能給予什麼幫助？
2. 確定你如何（或者是否要）評估每種技能。什麼樣的問題或方法會有效？（你也可以選擇多種方法。）
3. 這種方法有什麼問題？如何減輕這些問題，至少部分問題？
4. 建立一個與這種方法保持一致的面試培訓計劃。
5. 通知應聘人員你的期望。他們需要知道自己將要面對什麼。

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