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

舉個例子：編寫一個函數(shù)，將整數(shù)（比如100）轉(zhuǎn)換成“one hundread”。我發(fā)現(xiàn)，是否掌握了處理復(fù)雜數(shù)據(jù)結(jié)構(gòu)的編程技巧，與實際工作中的長期表現(xiàn)之間幾乎沒有聯(lián)系。通常在日常工作中，你只需要完成基本的工作。

技巧1：澄清問題

面試者是否注意到了問題的范圍？這個數(shù)字有多大，是否可以為負數(shù)？如果是動態(tài)語言，則“只考慮數(shù)字的情況嗎？小數(shù)和分數(shù)呢？”

絕大多數(shù)的實際問題都是模棱兩可的，深入挖掘基礎(chǔ)的問題，澄清范圍，這一點非常關(guān)鍵。

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

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

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

很多大問題都沒有正確答案，你需要權(quán)衡利弊。能夠統(tǒng)一取舍很重要。

技巧3：使用自己熟悉的環(huán)境

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

我發(fā)現(xiàn)，讓面試者使用自己熟悉的環(huán)境，他們的表現(xiàn)往往會更出色。當然，這個環(huán)境依然是面試專用的環(huán)境，他們?nèi)匀挥袝r間的壓力，但是這更接近實際的工作。

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

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

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

技巧4：寫代碼 -> 運行 ->調(diào)試

編寫完一段小代碼后，你應(yīng)該試著運行一下，看看能否得出正確的結(jié)果。面試者可以通過這個迭代找出小錯誤，從而在面試中有更好的表現(xiàn)。有的面試者一直在寫代碼，從來都不運行，直到面試結(jié)束。結(jié)果，最后運行的時候，代碼編譯不過去或出錯。

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

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

原文鏈接：https://nojvek.substack.com/p/how-to-make-coding-interviews-better

聲明：本文為 CSDN 翻譯，轉(zhuǎn)載需注明來源。