小白收藏！在編程面試之前，應(yīng)該如何進(jìn)行相應(yīng)的準(zhǔn)備？
本文的作者經(jīng)歷過100多場面試，而且也擔(dān)任過50多場面試的面試官，我們一起來看一看他從面試者與面試官雙向的角度總結(jié)出的面試經(jīng)驗(yàn)舉個(gè)例子：編寫一個(gè)函數(shù)，將整數(shù)（比如100）轉(zhuǎn)換成“one hundread”。我發(fā)現(xiàn)，是否掌握了處理復(fù)雜數(shù)據(jù)結(jié)構(gòu)的編程技巧，與實(shí)際工作中的長期表現(xiàn)之間幾乎沒有聯(lián)系。通常在日常工作中，你只需要完成基本的工作。技巧1：澄清問題面試者是否注意到了問題的范圍？這個(gè)數(shù)字有多大，是否可以為負(fù)數(shù)？如果是動(dòng)態(tài)語言，則“只考慮數(shù)字的情況嗎？小數(shù)和分?jǐn)?shù)呢？”絕大多數(shù)的實(shí)際問題都是模棱兩可的，深入挖掘基礎(chǔ)的問題，澄清范圍，這一點(diǎn)非常關(guān)鍵。技巧2：討論各種可行的方式，總結(jié)出大致計(jì)劃優(yōu)秀的面試者不會(huì)上來就直接編寫代碼，他們會(huì)解釋自己的方法和思維模型。這意味著他們愿意在動(dòng)手編寫代碼之前，與他人合作，探討可行的方式。這個(gè)時(shí)候，你可以利用白板，或者在紙上畫出來也可以。大多數(shù)的實(shí)際問題都需要團(tuán)隊(duì)達(dá)成一致。能夠與他人交流你的想法，說明每種方式的優(yōu)缺點(diǎn)，這一點(diǎn)非常重要。很多大問題都沒有正確答案，你需要權(quán)衡利弊。能夠統(tǒng)一取舍很重要。技巧3：使用自己熟悉的環(huán)境在白板上編寫代碼其實(shí)并不好，白板上的算法與實(shí)際的日常工作有很大的區(qū)別。在coderpad.io中編寫代碼也很麻煩，因?yàn)樗鼈儧]有自動(dòng)補(bǔ)齊，不會(huì)自動(dòng)整理格式。絕大多數(shù)工程師都有自己的IDE：vscode、sublime、vim等。我發(fā)現(xiàn)，讓面試者使用自己熟悉的環(huán)境，他們的表現(xiàn)往往會(huì)更出色。當(dāng)然，這個(gè)環(huán)境依然是面試專用的環(huán)境，他們?nèi)匀挥袝r(shí)間的壓力，但是這更接近實(shí)際的工作。我做了一項(xiàng)A/B測試，針對同一個(gè)問題，讓面試者使用他們的電腦，共享屏幕，然后分別使用coderpad.io和sandbox.io。結(jié)果發(fā)現(xiàn)，在前端開發(fā)的問題中，使用sandbox.io的面試者的表現(xiàn)更好，因?yàn)樽璧K他們盡快開始編程的問題更少。面試者使用自己電腦，共享屏幕，克隆代碼庫，這也是一個(gè)很好的技巧。coderpad.io能做的事情很少。通過讓面試者克隆代碼庫，可以看出面試者是否能夠快速適應(yīng)一個(gè)不熟悉的代碼庫。在Google的面試中，他們讓我在Google文檔中編寫代碼。這種做法一點(diǎn)都不好。根據(jù)我的經(jīng)驗(yàn)，Stripe的面試過程不錯(cuò)。在面試中，你可以將GitHub代碼庫checkout出來，然后在自己的電腦上，用自己最喜歡的IDE打開代碼。技巧4：寫代碼 -> 運(yùn)行 ->調(diào)試編寫完一段小代碼后，你應(yīng)該試著運(yùn)行一下，看看能否得出正確的結(jié)果。面試者可以通過這個(gè)迭代找出小錯(cuò)誤，從而在面試中有更好的表現(xiàn)。有的面試者一直在寫代碼，從來都不運(yùn)行，直到面試結(jié)束。結(jié)果，最后運(yùn)行的時(shí)候，代碼編譯不過去或出錯(cuò)。表格測試也是一個(gè)很不錯(cuò)的技巧。你可以編寫一個(gè)數(shù)組：[[輸入,輸出],[輸入,輸出],[輸入,輸出],...]，然后傳遞給一個(gè)簡單的測試函數(shù)�？吹綔y試用例和代碼復(fù)雜度的變化，面試官也會(huì)很高興。我們必須通過編程問題和接近實(shí)際的工作環(huán)境來測試候選人。同時(shí)，我們應(yīng)該更加重視之前的經(jīng)驗(yàn)。話雖這么說，面試并不能代表一切，有時(shí)候我們需要花費(fèi)一兩年的時(shí)間，才能深入理解整個(gè)代碼庫，因此我們必須將眼光放長遠(yuǎn)。
