在過去的歲月中，我不但參加過很多場程序員面試，也親手舉辦了許多。我清楚的知道搞砸面試的眾多因素。最糟糕的情況就是，面試官通過一些晦澀難懂的技術知識以顯擺自己的聰明睿智。

[[135543]]

“錯了！原因是將它類型強制轉化為十六進制！“ [“呵呵”，笑著用手指了指]

這件事曾真實地發生在我身上。至今讓我記憶猶新。雖然最后他們還是愿意雇傭我，但我婉言拒絕了。這樣的互動對雙方都是一種折磨：不但封閉了應聘人員的技術思維，也讓面試官獲取不了他們真正需要的信息。

最好的編碼測試可以讓應聘人員和面試官一下子就明白將來共事的感覺和情境。所以，專業的編碼面試應該具備以下三個特點：

1.開放式對話

良好的編碼面試所提出的問題應該是開放式的，不受限制的。為什么呢？我們需要從對話中了解開發人員的喜好、風格和知識。我們的目標不是為了了解瑣碎 小事，而是要對該應聘人員如何解決問題有一個整體的把握。具體的技術問題不應該放到編碼面試中來，它們應該屬于之后的技術面試。

編碼測試的真正價值所在，是尋找一個真正的愛好者。

但也不必矯枉過正。

比如說，我對職業棒球大聯盟一無所知。然而，關于犯規、投球以及罰球線我也能講得頭頭是道。如果不進行開放式對話的話，你或許就會給我打上“對棒球 了解甚深”的標簽了。但是，一旦你像一個真正的球迷一樣跟我討論棒球，或者找一個內行人來，那用不了20秒，我大概就會露馬腳了：你會發現，我知道的只是 一些規則，一些皮毛。

編碼面試也應當如此。你的知識是不是只停留在表面，要像照妖鏡一樣立馬現出原形：不是因為我問的是棘手的問題，而是因為一旦我們討論起創造性的解決 方案，是金子的才會發光。當然應聘人員偶爾說一句——“我不知道”也是完全可以接受的（總比信誓旦旦地給出錯誤答案要好！）。但是，如果應聘人員不能對他 們的解決方案說出個子丑寅卯來，那就必然不是一個真正的愛好者。這也是為什么對話的目的并不局限于單純的測量知識層面上。

2.模擬現實

允許應聘人員選擇技術和方法。他們的選擇能說明很多問題。如果你正在尋找JavaScript開發人員，而對方恰巧通過創建服務器來呈現解決方案， 那就值得好好地談一談。允許應聘人員選擇自己慣用的IDE。允許他們谷歌不知道的東西，就像他們在現實生活中那樣。盡量模擬現實情境。在白板上用鉛筆寫代 碼是不現實的。它會導致優秀人才的壓力從而增加遺漏人才的風險。

接下來就讓我在我的IDE上搞一個小時？呵呵，這也不現實。

相反，考慮到結對編程對實際問題的重要性，你也不必特意難為應聘人員。不妨將對方當成是幫你解決問題的同事。在此過程中，你還可以看到他如何使用IDE，搜索了哪些內容，以及攻克的重點是什么。

如果你正在創建一個標準化的測試，那么請確保它與崗位是相關的。例如，如果你正在為醫療行業構建Web應用，那么編碼測試就應該是使用Web應用程 序來解決醫療相關的問題。一個好的編碼測試能夠讓人預覽今后的日常工作。無論是應聘人員還是面試官都應該對彼此成為同事有著美好的期許。

3.不要設定正確答案

創建一個簡單的編碼測試是很容易的，比如說， 反向字符串，計算斐波納契數，或者打印fizzbuzz。但從這些鏈接上面我們可以發現，這些問題都是沒有價值的。因為它們不鼓勵對話，也不能代表我們在工作中需要解決的實際問題，而且谷歌或百度一下，答案就有了。

當然，你也可以在測試時禁止網上搜索，但是，請記住，一個良好的編碼測試應該力求模擬真實的工作場景。在編碼時禁止訪問谷歌就像不允許廚師翻閱食譜 一樣，都是很逗比的行徑。事實上，良好的編碼面試應該是開放式的，沒有局限的，同樣也沒有所謂的“正確答案”。這樣一來，不但解決方案不容易在網上找到， 還可以討論應聘人員所選方法的優缺點。

就是這樣。也不是那么難，對吧？