14 年經驗程式設計師的吐槽：如何招不到程式設計師？
【導讀】：咦，怎麼是招不到程式設計師？標題沒寫錯麼？嗯，沒寫錯，國外程式設計師 Nikita 最近寫了一篇文章《How NOT to hire a software engineer》，吐槽大公司在招程式設計師的一些不合理的做法。
一起來看看他是從哪些方面吐槽的？吐槽的是否有道理？
我不是大公司的招聘專家，但我是一個有 14 年工作經驗的程式設計師，對小公司招聘還是有較多經驗和一點常識。
早在 2013 年，我為 AboutEcho 組織了一次非常成功的招聘活動，最終招聘了 9 名高階工程師。
這讓我有信心來聊聊如今網際網路巨頭招程式設計師的做法。
（插圖來自 Yulia Prokopova）
1、不要面試時追求最佳解決方案
當求職者到達面試現場時，面試官給出一個問題，並希望在 2 分鐘內得到解決。如果花的時間更長，他們就會開始擔心，至少會要求你做點什麼。
我能理解，畢竟他們只有 45 分鐘，他們有很多事情想和求職者一起經歷。
我不能理解的是，面試官是根據求職者在 2 分鐘內想出的解決方案的質量來評判。因為那不是人類創造力的工作方式。想出很多點子很容易，但期望最佳點子總是第一個出來就很奇怪了。即使是天才，也無法在幾分鐘給出世界上的最佳解決答案。
創造力是評估和過濾你所想到的想法的能力。如果你們真的對此感興趣，為什麼不讓求職者來比較和評估多種解決方案呢？然後判斷求職者是否能夠評估解決方案的效能？求職者是否能清楚看到所有的優點和缺點？
如果要求在幾分鐘內想出最好的解決方案，你們測試的是運氣，僅此而已。你們是在僱傭幸運的員工嗎？還是招能力的員工？
2、不要在面試中問謎題
如何檢查連結串列是否有迴圈？一個 N 維的盒子能裝進另一個 N 維的盒子裡嗎？你能在沒有第三個變數的情況下交換兩個變數嗎？如何找到兩艘行進中的船之間最短的距離？
別誤會我的意思，這些謎題很有趣，討論起來很有趣，解決方法也很有見地。我以前還是個孩子的時候，我就喜歡看《Mathematical Recreations and Essays》。
然而，不管謎題有多有趣，它們只是一些軼事。謎題的性質是，你要麼知道答案，要麼不知道。它沒有告訴你其他任何事情。它與未來的表現無關，與聰明、能力或其他任何事情無關。知道一個特定的答案，並不意味著你可以採取通用和可預測的方式去解決實際問題。它告訴你的唯一一件事是，當某人與他人分享一個解決方案時，那這個人已經有了一種解決方案。不多也不少。就夠了。
（蠟燭燒斷繩子之前，你會如何自救？）
3、接受其他選擇/解決方案
這在某種程度上是意料之中的，但大公司似乎仍然在這方面失敗了。如果求職者提出了另一種解決方案，這是面試官學到一些東西的機會。如果提出的解決方案不可能實現，或者不太好，這也是一個深入討論的好機會。
儘管如此，我還是因為曾經提出過一個同樣複雜的替代解決方案而被 pass 了（而且我揹負著一場關於“解決問題的真正方法”的講座）。另一次面試時我引入了一個特定的解決方案，面試官急迫地忽視我所有考慮到的，只想討論他認定的解決方案，後來面試官對我的反饋是“沒啥印象”。
沒有人知道所有的事情。放開心態，傾聽他人，多思考。是的，即使你在面試他人。
4、容忍瑕疵
由於某種原因，單位元組溢位（Off-By-One）錯誤被廣泛認為是 CS 中最難的問題之一，幾乎每個人都會犯此類錯誤。錯誤是程式設計師生活的一部分，並不是你可以擺脫掉的。優秀的程式設計師知道該怎麼做。程式設計師的素質，並不取決於他/ TA 犯的錯誤有多少。
現在，如果你只選擇那些在面試中沒有出錯的人，你就能得到一群總是能寫出完美程式碼的程式設計師。你只是不知道當他們不可避免地犯錯誤時，他們會怎麼做。
所以犯錯其實是件好事，因為你會了解到求職者是如何消除錯誤的。不要只看到錯誤，而是要看求職者是如何處理錯誤的:
-
簡單的程式碼
-
分治
-
自檢
-
不變數
-
斷言
-
編譯和執行
-
測試
噢，不好意思，最後兩項。我都忘了你們在面試時不會讓求職者執行程式的。那你們還指望什麼呢？
5、讓我測試！
說真的，在白板上寫程式有什麼用？
我的意思是，我寧願在面試時討論演算法，討論抽象的東西更有效率。
但是在白板上寫程式，真正的程式？甚至不用執行？這樣有什麼意義？
獲得程式碼初稿，僅僅是程式設計整個過程的十分之一，接下來是編譯、檢查、調優、測試、評審等等。我們在開玩笑吧？這些是任何程式設計師工作流程的基本部分。程式碼只有在經過所有流程之後才適合檢視，而不是在此之前。
這就好比你讓一個畫家畫馬，然後在第一次畫的時候，當你看到四條線代表腿的時候，讓 TA 停下來，然後判斷。你會對 TA 有多少了解呢？
6、深入點吧
整 5 個簡短的面試題呢？還是搞 2 個長點的面試題？
有了 5 個題，你就有了 5 個獨立的意見，這比 2 個好。但 45 分鐘能挖多深呢？實踐表明，45 分鐘僅僅編寫 20~30 行程式碼並問幾個非常簡單的問題（複雜度是多少？如何測試它？）
下一個面試官只是簡單地重複同樣的過程，和前一個面試官一樣。這並不夠，一點也不夠。
為什麼不寫 2 個呢，但要寫得很全面？午飯前 1 個，午飯後 1 個？3 個小時也不算多，但至少你有機會了解求職者如何測試程式碼、如何更改程式碼、如何處理需求——所有這些都是前後相關中進行的，而不是每 45 分鐘就重新開始。
有了這麼多時間，你甚至可以讓 TA 把程式碼編寫成一個系統的一部分，而不僅僅是一個抽象的演算法任務，並瞭解 TA 在現實世界中的表現。
如果你想要更多的意見呢？讓多名面試官在一個房間裡，然後讓他們辯論。
7、多瞭解求職者的背景
我的意思是，我有 14 年的工作經驗。我很樂意談談函數語言程式設計、分散式系統、一致性、複用（replication）、協作文字編輯、CRDTs、並行架構、UI框架、團隊流程、產品設計和使用者體驗。我在這些領域都有實踐和研究經驗。它們都或多或少與我面試過的網際網路巨頭有直接的利益關係。
有人問過我這些問題嗎？沒有。
我得到的面試題是“假如你有一個函式，要用一個列表……”，連續 5 次。5 個學校級水平的面試題，能給你們一個足夠深刻的印象麼？我讀科曼等人的文章有多透徹？公平地說，你也很少被問到這些問題。
相反，要根據求職者的經歷來調整面試。談談 TA 擅長什麼。那你們將有機會提出更深入的問題，瞭解更多關於 TA 的經驗水平和 TA 能為公司帶來的好處。
8、無縫流程
方向錯了？推遲票？需要特別安裝 Adober 閱讀器才能開啟的調查問卷？廉價的超極本配著不熟悉的鍵盤佈局，基於 Web 的糟糕編輯器，沒有任何快捷方式。打擾一下，我這還是在全球知名 IT 公司的辦公室面試嗎？
在我遇到的中，一個面試官每天要安排 5 次面試。每天 5 個人，乘以公司面試官的數量。想象一下，所有求職者都對這個過程感到有點沮喪。日復一日，年復一年。
你可能認為這無關緊要，還得視情況而定。電視劇《Louie | 路易不容易》中有一集，一個喜劇演員發現房門上自己名字被拼錯了。所以他爭辯道： 是的，這是一個容易犯的錯誤，但也是一個容易糾正的錯誤。
是的，我相信任何人都能做得更好。
結語
如果你所在公司在招軟體工程師，大公司的那套常規做法不是你的「朋友」。 常識、公平、寬容、真正的興趣和開放的心態，這些才是你的「朋友」。
好好招聘咯!