程式設計師面試技巧總結

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

閒聊

在深入程式碼之前，大多數面試官喜歡聊聊你的背景。他們想知道：

• 你對編碼認知。你是否知道如何編寫好程式碼？
• 個人能力/領導力。你是否經歷過整個工作流程？你是否修復過並不怎麼正確的東西，即使你並不需要這麼去做？
• 溝通。和你交流技術問題是有用的還是痛苦的？

你應該至少說明以下中的一個：

• 你曾解決的一個有趣的技術問題
• 你曾克服的一個人際衝突
• 顯示領導力或個人能力的例子
• 你曾在以往專案中做出的貢獻
• 最喜歡的語言的一些瑣事，對這種語言你做了什麼，以及你不喜歡它哪裡
• 有關公司產品/業務的問題
• 關於該公司的工程策略（測試，Scrum，等等）

熱愛技術。表達你對你所做的一切感到驕傲，你對自己的選擇充滿自信，你對語言和工作流有著自己的看法。

溝通

涉及到編碼問題的時候，溝通是關鍵。一個在工作時需要幫助卻能和人正確溝通的求職者比那些能輕鬆解決問題的求職者甚至更好。
瞭解這是哪種問題。有兩種型別的問題：

1. 編碼。面試官希望你能針對問題寫出簡潔高效的程式碼。
2. 閒聊。面試官希望能和你聊一聊。話題通常是（1）高水平的系統設計（“如何克隆Twitter？”）或（2）瑣事（“Javascript中的hoisting是什麼意思？”）。有時候這些瑣事中也會引入“實際”問題，例如，“如何迅速排序整數列？好的，如果不是整數，是其他型別的呢…… ”。

如果你開始編寫程式碼，並且面試官並不想多說廢話，只想儘快過渡到“實際”問題，那麼如果你羅哩叭嗦太多的話，她可能會覺得厭煩。不妨直接問，“是不是為這個問題寫程式碼？”

讓人感覺你有團隊精神。面試官想知道和你一起工作是什麼感覺，會有什麼問題，所以要讓他們看到你的團隊合作性。使用“我們”來代替“我”，例如，“如果那個時候我們做廣度優先搜尋的話，就能及時/準時得到解決方案。”如果讓你選擇在紙上還是在白板上編碼的話，選白板。這樣，你就可以接近面試官，直接面對他提出的問題（而不是和她在桌子兩邊遙遙相望）。

把自己的想法大聲說出來。不是開玩笑，比如說：“我不知道這樣做是否有效——但請讓我試一試。”如果你不知道怎麼辦，不知道這個問題該如何解決，那麼就說一說你現在的想法。說一說你認為怎麼做可能會有效。說一說你認為哪些會有用，以及為什麼沒用的原因。這同樣適用於瑣碎的閒聊問題。當面試官要求你解釋Javascript閉包的時候，“這與範圍有關，不妨把它放到一個函式中”可能會讓你得到90％的分數。

不知為不知。如果正在談論的話題（例如，具體的語言事務，具體的瑣事，執行時分析）的確是你不曾涉獵的內容，那麼不要不懂裝懂。相反，你可以直接說：“我不知道，但我猜$thing，因為……”，因為後面可以通過分析排除其他選項，還可以拿其他語言或問題做例子。

說話不要不經大腦。不要自信地將答案脫口而出。如果是正確的，那麼你還是需要時間來考慮如何解釋，如果是錯的，那會顯得你衝動魯莽。你不是在和人比速度，而且你這麼做更有可能因為打斷她的話或者妄下結論而惹惱她。

擺脫困境

有時候你會陷入僵局。放鬆。這並不意味著你已經失敗了。請記住，面試官通常更在乎的，是你能否巧妙地從幾個不同的角度去揭示問題，而不是一根筋走到底地堅持正確答案。

畫圖。不要浪費時間在腦袋裡思考，可以畫到板上。畫出幾個不同的測試輸入。畫出你如何手動如願得到所需的輸出。然後想想將你的方法轉換成程式碼。

解決問題的簡單版本。不知道如何找到集合中的第4大條目？那麼想想如何找到第1大條目，然後試試能否沿用這種方法。

寫一個簡潔低效的解決方案，然後對其進行優化。竭盡全力。盡一切可能的方法得到某種答案。

講講自己的思路。講一講你知道什麼。講一講你認為什麼可能工作以及為什麼無效的原因。你可能突然會意識到它實際上是可以工作的，或修改版本是有效的。也有可能，你會得到提示。

等待提示。不要用期待的眼光盯著面試官，但可以有短暫的“思考”時間——面試官或許已經決定給你個提示也說不定呢，等待她的提示以免打斷她。

考慮空間和執行時的界限。如果你不知道你是否可以優化解決方案，那麼就說出來。例如：

“我必須至少看看所有的條目，我做不到時間複雜度比O(n)還好的了。”
“蠻力方法才能檢驗所有的可能性。”
“答案將包含n^2資料項，所以我必須至少花費N^2的時間。”

寫下你的思路想法

憑空地想很容易自我矛盾。把你的想法寫下來，然後再去考慮細節。

呼叫幫助函式，繼續前進。如果你不能或多或少地馬上想出如何實現演算法，那就跳過它。寫一個命名合理的呼叫函式，例如：“this will do X”，然後繼續下一步驟。如果幫助函式非常微不足道，你甚至可以將它忽略。

不要擔心語法。不妨一笑而過。如果你非要考慮語法，那就還原到英語。只要向面試官說明稍後會回來整理即可。

預備足夠的空間。你可能後面會想要在程式碼行之間新增程式碼或筆記。從白板的頂部開始寫，並在每一行之間留一條空白。

最後寫一個重頭檢查的標誌。不要擔心你寫的for迴圈是否應該有“<”或“<=”。在程式碼的最後畫個勾選提醒自己最後再檢查一遍。先按自己的思路走。

使用描述性的變數名。想名字需要時間，但可以防止你忘記自己寫某段程式碼的目的。使用names_to_phone_nums_map而不是nums。在名稱中說明型別。返回布林值的函式應該以“is_ *”，儲存列表的Vars應該以“s”結尾。標準化很有意義。

完成之後的整理

瀏覽解決方案，大聲地講，輸入一個例子。當程式執行時記錄下變數儲存的值——如果你只是記在腦子裡，不會讓你贏得任何加分。這有助於你發現bug和消除面試官的困惑。

尋找差一錯誤。你的for迴圈是不是應該使用“<=”來代替“<”？

測試邊緣情況。措施包括空集合，單專案集合或負數。加分點：提一提單元測試！

不要惹人厭煩。有的面試官可能並不在意這些整理步驟。如果你不確定，可以這樣說，“我通常會檢測一些邊緣情況——那麼我們接下來是不是做這個呢？“

實踐

最後，執行實踐問題是沒有捷徑的。

好記性不如爛筆頭。對自己誠實。用筆寫可能一開始會讓你覺得彆扭。但是如果你現在就能克服這個難題，那麼當面試的時候，你就不會覺得笨拙和不順手了。

本文中的實踐問題只是提供了每個面試過程的線索要點，沒有真正的金科玉律，在真正面試時還需實際問題實際解決。最後，祝大家面試成功。