No.01
在提出解決方案之前就開始編寫程式碼
出現率：20.66%
問題所在：
在徹底思考好解決方案之前，深入編寫程式碼無疑是得不償失的。沒有完整的方案就開始編碼，當你意識到你所做的事情太複雜或毫無意義時，時間已經所剩無幾。
莽撞而匆忙的行為或許是因為緊張，或許是因為過度自信，切記懸崖勒馬！一邊編寫程式碼一邊找出解決方案其實並不可行，這會耗盡時間，匆忙編寫程式碼的結果是“做得更多”而不是“做的更好”。
建議：
首先需要理清自己的思路，將整個問題分解成簡單的小部分。當準備開始編寫程式碼時，最好先寫出虛擬碼來解析自己的方法。以舉例的方式，來說明演算法中的關鍵步驟。
Only after both you and your interviewer agree that you have a good solution, proceed to implementation.
在開始編寫前，早些提及那些缺乏理性的，粗暴或天真的方案是必要的，這有以下三個原因：
首先，它可以避免尷尬的沉默時刻，讓你有可以描述表達的觀點；同時也有助於找出最佳的解決方案。
其次，不成熟的解決方法有時可以透過最佳化，成為最佳解決方案。
最後，作為一名軟體工程師，主要職責是編寫一個可行的解決方案。正確性優先於效率。
No.02
不重視計算機科學的基本原理
出現率：20.05%
問題所在：
不管喜不喜歡，而今大多數編碼面試仍然圍繞資料結構和演算法（DS＆A）的問題展開。無論是Dropbox，Airbnb，Uber＆Palantir這樣的擬上市初創公司，還是Google，Meta， Amazon，Apple這樣的巨頭公司，都是如此。
You may be an exceptional practical programmer, but if your command of core DS&A is lacking, you’re unlikely to get the job that you want. Yes, this sucks, but that’s reality.
建議：
利用一些時間學習或複習資料結構和演算法（DS＆A）。這不僅可以幫助你度過編碼面試，還可以讓你成為更好的軟體工程師。掌握基本的DS＆A是每一位軟體工程師的基本技能。
No.03
沉默
出現率：15.80%
問題所在：
面試官不是絕地武士，不會讀心。你可能會因為思路不是十分清晰連貫而感到焦慮，但如果不能鼓起勇氣說話，透過面試的希望便十分渺茫了。僅僅在面試開始時，解釋解決問題的方法是不夠的。即使在執行和測試演算法期間，也最好和麵試官保持全程交流。
建議：
誇大我們的想法，對於其他人來說，顯而易見是一種常見的認知偏見，在過度交流方面更是如此。在面試時，向面試官展示你的步驟和推理過程。如果你感到焦慮，不能有效地表達你的想法，可以尋找一些讓自己冷靜下來的技巧。一邊談話一邊編碼對很多人來說並不十分習慣，一個專業的練習平臺是必要的。
No.04
程式語言命令不佳
出現率：12.56%
問題所在：
你可能有很好的解決問題的能力和演算法思維，但如果你不知道所選擇的程式語言的核心結構，功能和語法，那麼這將會造成一定的麻煩。
考官基本不會考察在稀有情況下使用的一些深奧資料的結構介面。但如果你不瞭解基礎的知識點，例如C中的記憶體管理，Java中的繼承，Python中的列表解析或者JavaScript中的閉包，那麼再見，你的面試基本GG了。初學者一般容易犯下這個錯誤，但它也時時發生在擁有深厚理論知識但缺乏實踐經驗的學者身上。
建議：
如果可以選擇，儘量用自己最熟悉的程式語言進行面試。面試官通常是靈活的，可以讓你選擇熟悉的程式語言。如果情況特殊，例如面試必須使用JavaScript的前端職位，那麼就需要做好複習，提前掌握需要的程式語言技能。
Learning from books won’t cut it and you need to get your hands dirty. Program a few projects, contribute to open source, or better yet, do both.
邊學邊練習是真正掌握程式語言的唯一方法。如果你需要一個關於專案的想法，利用Google搜尋查詢將會得到很多資訊。
No.05
不使用測試
出現率：10.33%
問題所在：
因為沒有進行測試執行程式碼，與職位失之交臂。首先，程式碼在某些特定的測試中失敗是很常見的事。經過測試，可以發現錯誤並儘快解決它們。此外，你可能會想出一個面試官沒有想過的原創解決方案。透過舉例說明，展示每一行程式碼中每個變數的變化，讓面試官更容易理解這個解決方案是有效的。
Hiring engineering managers love test cases. In fact, for some of them not using tests is an outright deal breaker even if you reached to the right solution.
建議：
在面試中，建議分三次測試方案。
第一次是在面試官問過你編碼問題之後，使用一個或兩個例子來驗證是否完全理解了這個問題（更多細節參見No. 06）。
第二次是在勾畫出解決方案之後，使用測試用例，透過虛擬碼來引導並驗證其正確性。
第三次是在完成了編寫程式碼後，再次進行測試，以確保沒有任何問題。
No.06
錯誤解讀問題
出現率：9.11%
問題所在：
在所有的問題中，讀題錯誤是最容易避免的。但依然有大約9％的面試者會馬虎以至於誤讀問題。這裡沒有太多需要說明的地方。
If you misunderstood the interview question or made assumptions about the problem statement or input that you shouldn’t have, it’s likely that you’ll fail your interview.
建議：
在面試官解釋完問題之後，第一件事就是用自己的話複述一遍，以證實是否正確地理解了問題。如果弄錯了，面試官會告訴你的。這樣簡單的一步可以避免文不對題的尷尬。
在複述這個問題的同時，可以適當提出幾個簡單的輸入示例，以確保預期結果的正確性。這會讓面試官更容易知道你是否理解了這個問題。
另一項需要注意的是，可以適當做出某些假設。例如，你可以詢問，輸入是否排序，自己是否可以假設輸入是有效的，或是在特定範圍內的。也可以和麵試官一起縷清需不需要針對時間或空間進行最佳化。
No.07
忽略邊緣案例
出現率：8.31%
問題所在：
忽略邊緣案例一定程度上表明面試者解決問題的能力不足。首先，如果演算法沒有處理所有有效的輸入，那麼這個解決方案就是不完整的。其次，因為沒有考慮邊緣情況，錯過了更好的可以消除邊緣情況的演算法。
例如，在填出等式中空出的數字這個問題中，一個簡單的解決方案是從總和（1，…，n）中減去輸入陣列的總和。但是，對於足夠大的'n'來說，解決方案將由於整數溢位而失敗。這個邊緣案例迫使你想出更好的解決方案。透過使用位運算子XOR，可以設計一個不再容易溢位的解決方案。
建議：
圍繞演算法輸入的邊界使用測試。如果演算法在某些邊緣情況下失敗，首先檢查是否可以透過快速增量更改來修復演算法。如果不能，詢問面試官你是否應該處理這些邊緣案例。
在需要處理邊緣案例而你卻毫無頭緒時，嘗試與面試官交流並試圖尋求他們的幫助。
No.08
程式碼不易理解
出現率：7.69%
問題所在：
技術面試不僅僅關乎正確性和效率，也關乎面試者的程式碼風格。你的程式碼也許是有效率的，經得住推敲的，但如果只有你自己能夠理解程式碼，那麼面試結果，十之八九是慘烈的。
Hiring managers look for engineers whose code is legible, maintainable and idiomatic. Code that other team members can pick up from where you left off easily.
這個問題在初學者、語言切換者和程式設計競賽參與者中很是普遍。以下是應該避免的一些造型錯誤：
一.給變數，函式等賦予隨機的，非描述性名稱。例如，對非索引變數使用單個字元名稱，或者呼叫函式'func'。程式設計競賽開發人員尤其需要小心，因為他們習慣於在其程式中使用短名稱，以便更快地編寫程式碼。這在面試中是非常不利的。
二.程式碼風格不一致。每個人都有自己的程式設計風格，但混合隨機編碼標準並不是一個好主意。例如，使用不同的命名方式，或者同時在camp Richard和camp Winnie使用製表符。同樣，如果您將大括號放在同一行上，不要在後面的程式設計時又放在新行中。
三.使用保護性程式碼（例如NULL檢查和許多特殊情況）而不考慮是否必要。這導致程式碼更復雜，更加難以理解和除錯。
建議：
適當保持程式碼簡短。按照常識在適用的地方給出描述性的名字，並在面試期間選擇一種程式碼標準。最好使用慣用的程式碼。否則，面試官可能會懷疑你的程式語言運用的不夠熟練。
軟體工程師的技術面試不但要求技術上的優秀，同樣要求軟技能的優秀。注意，從入門到合格，從合格到優秀是不同的階段，如何絲滑進階？歡迎掃碼回覆【諮詢】進行了解！
* 本文原創於直通矽谷【https://www.zhitongguigu.com】，歡迎尊重版權的轉載。一般轉載請在文章開頭或結尾正確註明以下資訊：作者：直通矽谷 公眾號：直通矽谷訂閱號直通矽谷
直通矽谷，讓科技求職更簡單。