像專業人士那樣聊天

在深入代碼之前，大部分面試官都喜歡聊聊你的背景。他們想知道：

關于編程的元認知。你有考慮過如何才能更好地編程嗎？（譯者注：元認知（Metacognition）或譯為后設認知，這個名詞由 Swartz 及 Perkins 發明及定義，即“認知的認知”或“知識的知識”。簡言之，就是對自己的認知過程（包括：記憶、感知、計算、聯想等各項）的思考。）

自主精神/領導能力。你看到你的工作完成了嗎？就算你不必這樣做，你會主動修正不對的事情嗎？

溝通。他們會和你聊聊技術上的問題是有用的，還是痛苦的？

你至少應該準備好下面中的一項：

你解決過技術問題中一個有趣的例子

你克服人際沖突的一個例子

領導能力或自主精神的例子

你在過去項目中應該做什么的故事

你最喜歡語言的一些細節，以及關于你喜歡和不喜歡說的語言上的一些事情

關于公司產品或業務的問題

關于公司工程戰略的問題（測試，Scrum等）

好好準備相關材料。你要展示你做過最自豪的事情，你很希望了解他們正在做什么，而且你對語言和工作流程有一些自己的想法。

溝通

一旦涉及到編程的問題，溝通是關鍵。在過程中需要幫助但可以清楚與人溝通的候選人，要比那些可以輕而易舉解決問題的候選人更加難得。

理解它是哪一類問題。問題有兩類：

編程。面試官希望看到你解決問題，并且可以寫出整潔和有效的代碼。

聊聊而已。面試官只是想讓你說點什么。這些問題通常要么是高層次的系統設計（“你如何設計 Twitter 的備份？”），要么是瑣碎的事情（“JavaScript 中 hoisting 是什么？”）。有時候瑣事是為了引出一個“真正的”問題，比如，“我們如何能快排一個整數數組？好的，現在假設我們不再使用整數而是……”

如果面試官在進入“真正的”問題之前，只是想很快得到一個類似閑聊的回答，而你卻開始編寫代碼了，她會感到失望。只需要問一句，“我們要為它編寫代碼嗎？”

讓人覺得你們是一個團隊的。面試官想知道和你一起解決問題會是什么樣子的，所以要讓面試官覺得你是樂于合作的。用“我們”來代替“我”，比如，“如果我們采用一個廣度優先搜索，我們會很快得到一個答案?！比绻氵x擇在紙上還是在白板上編寫代碼，最好選擇白板。這樣你就可以坐在面試官的旁邊，面對著問題（而不是和她隔著一個桌子）。

說出你的想法。我是認真的。“讓我們試著這樣做——但我還不確定它是否會起作用?！?，如果你被卡住了，就說出你的想法。說說什么可能會有用。說說你認為什么東西可以工作，以及為什么它不工作。這也適用于瑣碎的閑聊問題。當被要求解釋 JavaScript 閉包時，“它跟范圍有關，而且是在函數中實現”，這樣的回答就可以讓你拿到 90% 的分數。

說你不知道。如果你碰到一個事實（例如，特定語言的邊邊角角，一個涉及分析運行時的難題），不要不懂裝懂。相反應該說“我不確定，但我猜測是這樣，因為……”，這個『因為』包括通過展示其它選項的荒謬性來排除它們，或者從其它語言或問題中找到類似的例子。

放慢步調。不要自信地脫口而出一個答案。如果它是正確的，你仍然需要解釋它，如果它是錯誤的，就會顯得你很魯莽。你并沒有因為速度快而贏得什么，相反更可能會因為打斷她或急于得出結論而惹惱面試官。

擺脫困境

你有時會被卡住。放松。這并不意味著你已經失敗了。記住與找到正確答案的能力相比，面試官通常更加關注從不同角度探索問題的能力。就算希望渺茫，也要繼續探索不放棄。

畫圖。別浪費時間光在腦袋里面想 —— 在黑板上思考。畫幾個不同的測試輸入。用手畫出如何獲得想要的輸出。然后思考將你的方法轉換成代碼。

解決一個更簡單的問題。不知道如何找到集合中第四大的項目？先思考如何找到最大項，再看看你能否改變一下方法。

先寫一個簡單和低效的方法，再想辦法去優化它。使用暴力的方法。盡一切努力得到答案。

更加大聲說出你的想法。說出你知道的。說說你認為什么可能會工作和為什么它行不通。你可能會意識到它確實有用，或者一個改進的版本會游有用?；蛘吣憧赡軙玫揭粋€提示。

等待提示。不要一臉期待地盯著面試官，只需要停下來“想一下” —— 你的面試官可能已經決定給你一個提示，只是在等待一個時機，避免影響到你。

考慮空間和運行時間的限制。如果你不確定是否能優化解決方案，大聲說出你的想法。例如：

“我至少要查看所有的項，所以我不能再優化了?！?/p>

“暴力的辦法就是測試所有的可能性”

“這個答案將包含 n^2 個項，所以我至少要花這么多時間?！?/p>

把你的想法寫下來

你很容易讓自己陷入混亂。你先集中精神把想法寫下來，最后才去關心細節。

調用輔助函數并進行下去。如果你不能很快想到如何實現一部分的算法，不論大小都跳過它。呼叫一個命名合理的輔助函數，聲明“這將會完成某事”，并進行下去。如果輔助功能不重要，你完全可以不去實現它。

不要擔心語法。只要略過它就好了。如果必須的話請轉換成英語。只需要說你會回頭看它的。

給自己留下足夠的空間。你后面可能要在兩行之間添加代碼或注釋。從白板的頂部開始，在每一行之間留下一個空白行。

為最后的檢查做好標記。別擔心你的循環應該是 “《” 還是 “《=” 。你可以做一個標記提醒自己最后去檢查。只要把整體算法寫下來。

使用描述性的變量名稱。這樣會花一些時間，但會防止你忘記代碼正在做的事情。使用 names_to_phone_nums_map 代替 nums。在命名中暗示類型。返回布爾值的函數應該以 “is_ ” 開頭。擁有一個列表的變量應該以“s”結尾。選擇你能理解的標準并堅持下去。

當你完成后，記得做好善后工作。

你輸入一個例子，手動過一遍你的方法，并大聲說出你的想法。當程序運行時，你寫下變量保存的值 —— 在腦袋里做這些不會給你帶來任何加分。這樣可以幫你查找問題，并且可以消除面試官對于你正在做什么的疑惑。

查找一開始的錯誤。你應該在循環中使用“《=”而不是“《”？

測試邊界情況。包括空集、單個元素集合或負數等等。加分項：提一下單元測試！

不要覺得麻煩。有些面試官并不在意這些善后步驟。如果你不是很確定這一點，可以這樣說：“我通常會用一些邊界條件來測試代碼 —— 接下來我們要這么做嗎？”

實踐

最后，處理實際問題是無法替代的。

用紙和筆來編寫代碼。誠實地面對自己。剛開始可能會覺得很棘手。這沒什么。如果你現在能克服這種棘手的問題，等到真正面試的時候，就不會顯得笨手笨腳了。

我們遇到的實際問題反映了面試的流程，即當你陷入困境時會得到提示，當你的算法可以進一步優化時也會得到鼓勵。