本文的作者經歷過100多場面試，而且也擔任過50多場面試的面試官，我們一起來看一看他從面試者與面試官雙向的角度總結出的面試經驗

舉個例子：編寫一個函數，將整數（比如100）轉換成「one hundread」。我發現，是否掌握了處理複雜數據結構的編程技巧，與實際工作中的長期表現之間幾乎沒有聯繫。通常在日常工作中，你只需要完成基本的工作。

技巧1：澄清問題

面試者是否注意到了問題的範圍？這個數字有多大，是否可以為負數？如果是動態語言，則「只考慮數字的情況嗎？小數和分數呢？」

絕大多數的實際問題都是模稜兩可的，深入挖掘基礎的問題，澄清範圍，這一點非常關鍵。

技巧2：討論各種可行的方式，總結出大致計劃

優秀的面試者不會上來就直接編寫代碼，他們會解釋自己的方法和思維模型。這意味着他們願意在動手編寫代碼之前，與他人合作，探討可行的方式。這個時候，你可以利用白板，或者在紙上畫出來也可以。

大多數的實際問題都需要團隊達成一致。能夠與他人交流你的想法，說明每種方式的優缺點，這一點非常重要。

很多大問題都沒有正確答案，你需要權衡利弊。能夠統一取捨很重要。

技巧3：使用自己熟悉的環境

在白板上編寫代碼其實並不好，白板上的算法與實際的日常工作有很大的區別。在coderpad.io中編寫代碼也很麻煩，因為它們沒有自動補齊，不會自動整理格式。絕大多數工程師都有自己的IDE：vscode、sublime、vim等。

我發現，讓面試者使用自己熟悉的環境，他們的表現往往會更出色。當然，這個環境依然是面試專用的環境，他們仍然有時間的壓力，但是這更接近實際的工作。

我做了一項A/B測試，針對同一個問題，讓面試者使用他們的電腦，共享螢幕，然後分別使用coderpad.io和sandbox.io。結果發現，在前端開發的問題中，使用sandbox.io的面試者的表現更好，因為阻礙他們儘快開始編程的問題更少。

面試者使用自己電腦，共享螢幕，克隆代碼庫，這也是一個很好的技巧。coderpad.io能做的事情很少。通過讓面試者克隆代碼庫，可以看出面試者是否能夠快速適應一個不熟悉的代碼庫。

在Google的面試中，他們讓我在Google文檔中編寫代碼。這種做法一點都不好。根據我的經驗，Stripe的面試過程不錯。在面試中，你可以將GitHub代碼庫checkout出來，然後在自己的電腦上，用自己最喜歡的IDE打開代碼。

技巧4：寫代碼 -> 運行 ->調試

編寫完一段小代碼後，你應該試着運行一下，看看能否得出正確的結果。面試者可以通過這個疊代找出小錯誤，從而在面試中有更好的表現。有的面試者一直在寫代碼，從來都不運行，直到面試結束。結果，最後運行的時候，代碼編譯不過去或出錯。

表格測試也是一個很不錯的技巧。你可以編寫一個數組：[[輸入,輸出],[輸入,輸出],[輸入,輸出],...]，然後傳遞給一個簡單的測試函數。看到測試用例和代碼複雜度的變化，面試官也會很高興。

我們必須通過編程問題和接近實際的工作環境來測試候選人。同時，我們應該更加重視之前的經驗。話雖這麼說，面試並不能代表一切，有時候我們需要花費一兩年的時間，才能深入理解整個代碼庫，因此我們必須將眼光放長遠。

原文連結：http://nojvek.substack.com/p/how-to-make-coding-interviews-better

聲明：本文為 CSDN 翻譯，轉載需註明來源。