本文的作者經歷過100多場面試，而且也擔任過50多場面試的面試官，我們一起來看一看他從面試者與面試官雙向的角度總結出的面試經驗。
01
面試
從提交申請到正式入職，通常我們會經歷3-5次面試。首先是HR經理的電話面試，接著還有幾場技術面試。一位求職人員在一家公司的面試中花費的時間平均為8個小時左右。面試的目的是為某個職位尋找合適的技術人員，並從他們身上獲取高於薪資的價值。
根據形式不同，一場面試通常需要45分鐘～1個半小時。我的一位經理曾說：“你必須搞清楚面前這個人是否值一輛蘭博基尼，因為公司每年在這個人身上投入的資金超過了一輛蘭博基尼，即20萬～30萬美金（包括辦公室租金+各項福利）。”
我經常問自己，我們可以透過求職者身上的哪些特質判斷出他將有長期的良好表現？我選對人了嗎？
02
免責宣告
雖然我經歷過100多場面試，而且也擔任過50多場面試的面試官，但是這個資料量遠遠不夠。再者，我們很難透過短短一個小時的面試判斷某個人是否能夠在接下來幾年中給出優異的表現。很多時候，不是因為求職者不夠優秀，而是公司未能很好地引導他們，或未能讓他們發揮出最佳水平。
求職者只有在面試中有十分出彩的表現，才能取得成功。面試失敗的時候，我得到最多的答覆是：“我們沒有從你身上看多太多亮點。”
03
哪些因素有助於取得面試成功？
在我看來，最有利的因素有三個：
良好的人品；
適合的技術經驗；
解決難題的能力。
簡歷
作為面試官，一般我都會在面試前仔細閱讀兩遍簡歷。作為面試者，我很討厭那些根本不看我簡歷，卻佔用我的時間的面試官。通常，在簡歷中寫：“努力工作，注重結果”之類的言辭，基本沒什麼用。為了突出自己，你必須更具體：“我參與了專案X，在其中負責工作Y，最後取得了結果Z。”
如果求職者在簡歷中寫明GitHub連結，我就會去看他們的GitHub，看看他們都構建了哪些產品。即便他們不是程式設計高手，但至少證明他們能夠寫程式碼，而且能夠與其他人合作，完成工作。
推薦
如果你信得過某個人，那麼他的話在你這裡一定很有分量。尤其是當你給某人寫推薦信時，一定要說清楚：“你是否曾經與這個人共事，你覺得他能夠勝任這項工作嗎？”而作為面試官，我也會打電話給推薦人，問問他們：“他的表現如何？你願意再次和他合作嗎？”
以上是面試之前需要做好的準備，下面我們來看一看實際的面試。
04
程式設計面試
根據我的經驗，能否給出正確答案與在工作中是否有良好的表現，二者之間的聯絡並不大。然而我發現，面試者找到解決方案的方式之間有一些共同點。
舉個例子：編寫一個函式，將整數（比如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：寫程式碼 -> 執行 ->除錯
編寫完一段小程式碼後，你應該試著執行一下，看看能否得出正確的結果。面試者可以透過這個迭代找出小錯誤，從而在面試中有更好的表現。有的面試者一直在寫程式碼，從來都不執行，直到面試結束。結果，最後執行的時候，程式碼編譯不過去或出錯。
表格測試也是一個很不錯的技巧。你可以編寫一個數組：［［輸入，輸出］，［輸入，輸出］，［輸入，輸出］，。。。］，然後傳遞給一個簡單的測試函式。看到測試用例和程式碼複雜度的變化，面試官也會很高興。
05
總結
我們必須透過程式設計問題和接近實際的工作環境來測試候選人。同時，我們應該更加重視之前的經驗。
話雖這麼說，面試並不能代表一切，有時候我們需要花費一兩年的時間，才能深入理解整個程式碼庫，因此我們必須將眼光放長遠。
