像專業人士那樣聊天
在深入程式碼之前，大部分面試官都喜歡聊聊你的背景。他們想知道：
- 關於程式設計的元認知。你有考慮過如何才能更好地程式設計嗎？（譯者注：元認知（Metacognition）或譯為後設認知，這個名詞由 Swartz 及 Perkins 發明及定義，即“認知的認知”或“知識的知識”。簡言之，就是對自己的認知過程（包括：記憶、感知、計算、聯想等各項）的思考。）
- 自主精神/領導能力。你看到你的工作完成了嗎？就算你不必這樣做，你會主動修正不對的事情嗎？
- 溝通。他們會和你聊聊技術上的問題是有用的，還是痛苦的？
你至少應該準備好下面中的一項：
- 你解決過技術問題中一個有趣的例子
- 你克服人際衝突的一個例子
- 領導能力或自主精神的例子
- 你在過去專案中應該做什麼的故事
- 你最喜歡語言的一些細節，以及關於你喜歡和不喜歡說
的語言上的一些事情 - 關於公司產品或業務的問題
- 關於公司工程戰略的問題（測試，Scrum等）
好好準備相關材料。你要展示你做過最自豪的事情，你很希望瞭解他們正在做什麼，而且你對語言和工作流程有一些自己的想法。
溝通
一旦涉及到程式設計的問題，溝通是關鍵。在過程中需要幫助但可以清楚與人溝通的候選人，要比那些可以輕而易舉解決問題的候選人更加難得。
理解它是哪一類問題。問題有兩類：
- 程式設計。面試官希望看到你解決問題，並且可以寫出整潔和有效的程式碼。
聊聊而已。面試官只是想讓你說點什麼。這些問題通常要麼是高層次的系統設計（“你如何設計 Twitter 的備份？”），要麼是瑣碎的事情（“JavaScript 中 hoisting 是什麼？”）。有時候瑣事是為了引出一個“真正的”問題，比如，“我們如何能快排一個整數陣列？好的，現在假設我們不再使用整數而是……”
如果面試官在進入“真正的”問題之前，只是想很快得到一個類似閒聊的回答，而你卻開始編寫程式碼了，她會感到失望。只需要問一句，“我們要為它編寫程式碼嗎？”
讓人覺得你們是一個團隊的。面試官想知道和你一起解決問題會是什麼樣子的，所以要讓面試官覺得你是樂於合作的。用“我們”來代替“我”，比如，“如果我們採用一個廣度優先搜尋，我們會很快得到一個答案。”如果要你選擇在紙上還是在白板上編寫程式碼，最好選擇白板。這樣你就可以坐在面試官的旁邊，面對著問題（而不是和她隔著一個桌子）。
說出你的想法。我是認真的。“讓我們試著這樣做——但我還不確定它是否會起作用。”，如果你被卡住了，就說出你的想法。說說什麼可能會有用。說說你認為什麼東西可以工作，以及為什麼它不工作。這也適用於瑣碎的閒聊問題。當被要求解釋 JavaScript 閉包時，“它跟範圍有關，而且是在函式中實現”，這樣的回答就可以讓你拿到 90% 的分數。
說你不知道。如果你碰到一個事實（例如，特定語言的邊邊角角，一個涉及分析執行時的難題），不要不懂裝懂。相反應該說“我不確定，但我猜測是這樣，因為……”，這個『因為』包括通過展示其它選項的荒謬性來排除它們，或者從其它語言或問題中找到類似的例子。
放慢步調。不要自信地脫口而出一個答案。如果它是正確的，你仍然需要解釋它，如果它是錯誤的，就會顯得你很魯莽。你並沒有因為速度快而贏得什麼，相反更可能會因為打斷她或急於得出結論而惹惱面試官。
擺脫困境
你有時會被卡住。放鬆。這並不意味著你已經失敗了。記住與找到正確答案的能力相比，面試官通常更加關注從不同角度探索問題的能力。就算希望渺茫，也要繼續探索不放棄。
畫圖。別浪費時間光在腦袋裡面想 —— 在黑板上思考。畫幾個不同的測試輸入。用手畫出如何獲得想要的輸出。然後思考將你的方法轉換成程式碼。
解決一個更簡單的問題。不知道如何找到集合中第四大的專案？先思考如何找到最大項，再看看你能否改變一下方法。
先寫一個簡單和低效的方法，再想辦法去優化它。使用暴力的方法。盡一切努力得到答案。
更加大聲說出你的想法。說出你知道的。說說你認為什麼可能會工作和為什麼它行不通。你可能會意識到它確實有用，或者一個改進的版本會遊有用。或者你可能會得到一個提示。
等待提示。不要一臉期待地盯著面試官，只需要停下來“想一下” —— 你的面試官可能已經決定給你一個提示，只是在等待一個時機，避免影響到你。
考慮空間和執行時間的限制。如果你不確定是否能優化解決方案，大聲說出你的想法。例如：
- “我至少要檢視所有的項，所以我
不能再優化了。” - “暴力的辦法就是測試所有的可能性”
- “這個答案將包含 n^2 個項，所以我至少要花這麼多時間。”
把你的想法寫
你很容易讓自己陷入混亂。你先集中精神把想法寫下來，最後才去關心細節。
呼叫輔助函式並進行下去。如果你不能很快想到如何實現一部分的演算法，不論大小都跳過它。呼叫一個命名合理的輔助函式，宣告“這將會完成某事”，並進行下去。如果輔助功能不重要，你完全可以不去實現它。
不要擔心語法。只要略過它就好了。如果必須的話請轉換成英語。只需要說你會回頭看它的。
給自己留下足夠的空間。你後面可能要在兩行之間新增程式碼或註釋。從白板的頂部開始，在每一行之間留下一個空白行。
為最後的檢查做好標記。別擔心你的迴圈應該是 “<” 還是 “<=” 。你可以做一個標記提醒自己最後去檢查。只要把整體演算法寫下來。
使用描述性的變數名稱。這樣會花一些時間，但會防止你忘記程式碼正在做的事情。使用 names_to_phone_nums_map 代替 nums。在命名中暗示型別。返回布林值的函式應該以 “is_ ” 開頭。擁有一個列表的變數應該以“s”結尾。選擇你能理解的標準並堅持下去。
當你完成後，記得做好善後工作。
你輸入一個例子，手動過一遍你的方法，並大聲說出你的想法。當程式執行時，你寫下變數儲存的值 —— 在腦袋裡做這些不會給你帶來任何加分。這樣可以幫你查詢問題，並且可以消除面試官對於你正在做什麼的疑惑。
查詢一開始的錯誤。你應該在迴圈中使用“<=”而不是“<”？
測試邊界情況。包括空集、單個元素集合或負數等等。加分項：提一下單元測試！
不要覺得麻煩。有些面試官並不在意這些善後步驟。如果你不是很確定這一點，可以這樣說：“我通常會用一些邊界條件來測試程式碼 —— 接下來我們要這麼做嗎？”
實踐
最後，處理實際問題是無法替代的。
用紙和筆來編寫程式碼。誠實地面對自己。剛開始可能會覺得很棘手。這沒什麼。如果你現在能克服這種棘手的問題，等到真正面試的時候，就不會顯得笨手笨腳了。
我們遇到的實際問題反映了面試的流程，即當你陷入困境時會得到提示，當你的演算法可以進一步優化時也會得到鼓勵。