最近有一個關于技術面試的發現：很多簡歷漂亮的應試者面試的失敗率其實很高。有這么幾個失敗模式：思路糊涂、解題方向迂回，毫無分解地把所有邏輯扔在一個大函數里面，最后代碼錯誤連篇（比如說把數組的指數和內容搞混、off by one、if 不用 else、漏掉幾個if case什么的），或是缺乏測試的概念。這些誤區如果有點準備或是培養一些好的面試習慣，其實是可以避免的。

不同公司的面試目的不太一樣。類似于Google和臉書的大公司喜歡在白板上考算法和數據結構，其實也就是你的算法101課有沒有上好。類似于Stripe和Clever的小公司喜歡考你的專項（如網絡前端、移動端、或者運維大數據什么的），也讓你自帶電腦當場寫能編譯能運行能測試的app。其實這是因為大公司往往都有很龐大而復雜的系統、所以技術決定中效率很重要，同時也有大把有經驗的員工可以慢慢培養你上手（比如臉書就有6周的bootcamp、谷歌前3個月也會給你一個專門拿來上手的bootcamp項目）。小公司則需要你立刻馬上能寫出能用的東西，所以會看重你會不會用他們的技術展，以及能自己在沒人帶的情況下能否寫出可用并靠譜的代碼。當然各種公司也會根據職位、需求、和心情（也就是當天一共有那些面試官能面）調整面試的種類和考點。

每個公司都有自己的面試風格，他們到底看重什么樣的技能和什么樣的人，以及以往都面過什么樣的題，你大可在glassdoor上面搜一下。當然每一個公司有那些利弊和面臨哪些問題，glassdoor上面也有。很多小公司其實很重視讓應試者提問的面試環節，特別是在后期面試的時候。因為這能看出來你到底有多了解你面的公司以及他們的市場，他們也會由此判斷你到底是真心想去呢，還是只想多拿一個offer以便跟別人談談價。

舉個例子，有一種Coding面試。它的目的不是考算法，是考你能不能想明白一道邏輯相對比較復雜的題，寫出正確易讀的代碼，并且顯示出對測試和邊緣情況有良好的直覺。適合面coding的題目大約有兩種：一種是模擬某種體系或游戲（某紙牌游戲或桌游、模擬某種簡單的流程），需要你充分理解一個相對復雜體系并且選擇合適的數據結構去表現它。另一種是一個運用很多語言基礎并有很多邊緣情況的題，如數組和字符串的處理分析運用和正則表達式。目的是考你對你自己選擇的語言的熟悉度、也考你對測試和邊緣情況的習慣和直覺。為什么重視這個？也許是因為每一個沒有考慮到或者測試到的bug或者邊緣情況會導致幾個月后有人很多晚上不能睡覺。

這種面試有這么幾種常見的失敗原因：

思路問題

沒思路直接寫代碼，然后代碼變成巨大一坨的nested while / for loop和好幾個實際上重疊的cascading if，最后自己被自己寫的東西繞暈。其實你最該做的第一件事就是確保你正確理解了面試官給你的題目。一種失敗模式是應試者解一個多玩家游戲，花了大量時間去寫出2玩家版的精確代碼，但是要最終寫n玩家版的時候發現2玩家的版本完全不能generalize。這種情況其實可以不糾結于立刻寫代碼，可以花點時間確保你的解題思路正確、從而確保你的代碼分解比較合理，然后整段代碼很好讀。

光說不寫。這里的失敗模式是應試者做一個關于字符串運用的題，糾結了半天這個字符串到底是要從頭開始parse還是從尾開始parse，到底是要用遞歸（recursion）還是用while loop，到底要在哪個level of abstraction分成兩個不同的函數，最后扔出了一堆聽起來很高大上可是這個簡單的題目根本用不到的算法和數據結構的名詞可是扯了30分鐘就是沒寫出一行代碼來。其實從頭parse還是從尾parse，本質上沒那么大的區別。雖說能簡單iterate的東西你用遞歸有那么一點點非主流但只要你代碼干凈也沒人會歧視你。重點是30分鐘后白板上沒有代碼，你說出一朵花來也沒有用啊……

代碼可讀性、測試、和邊緣情況

代碼中off by one, array out of bounds, missing if cases, division by zero, empty string其實都是很容易犯的錯誤。我們自己容易看不清，但是經常看我們寫代碼的人經常比較容易可以看得到。所以你一個函數寫完的時候，最好自己讀一遍看看有沒有這些bug。最好不用面試官提醒你就自己改掉，如果全部代碼寫完了，最好也不用人提醒，自己拿一個輸入的例子把代碼過一下，看看有沒有漏掉的邊緣情況和bug。如果你覺得沒有，最好也把你所有的假設重申一下，確保你跟面試官在同一條線上。比如假設你假定輸入必須是正數而面試官沒有給你這個假設的話，他就會認為這是你漏掉的邊緣情況。函數和變量的命名，其實不要求你在白板上長篇大論，畢竟時間少寫字慢。可是要避免的一種情況是自己把自己繞暈，然后在代碼里面出錯。這里的一個例子是應試者把數組的指數叫i，數組的內容叫curr。本來要i%1000，可是每次都寫成curr%1000，但curr其實是個字符串。這樣的無心之錯不是不可以有，但是如果太多，也許體現的是你函數和變量的命名有點問題，自己把自己繞暈了。這一類型的問題大多是小問題，有一兩個無傷大雅，然而基本上是個減分的效果，積小成多，太多了也就致命了。

祝好運。