我最近收到一封來自印度讀者的郵件，讓我就技術面試談下看法。關於這個話題，本文再現了我在 2004 年寫的一篇文章。（注意，這是我在參與到 C# 團隊之前寫的，因此充滿了 C++ 的感覺）
下次在 FAIC，我將就同樣話題轉載另一篇文章。
我偶爾為我的團隊和其它 Visual Studio 團隊的開發崗位面試應聘人員。關於微軟的面試情況，有太多的人寫了太多的文章，因此我不再贅述。我今天想提的是，給面試開發崗位的應聘人員提供一些建議。這肯定不是完整的——我想重點談談面試的一個重要方面。
應聘開發人員：如果你看過這方面的資料，你就明白，大部分面試都涉及到在白板上寫代碼。一句忠告：在白板上寫代碼是有難度的。多加練習！
難的部分原因在於，你不具備平時寫代碼所擁有的智能感知、語法著色或其它工具。我理解，我會注意到的。我不介意當你想寫 memset (&b, 0x00, cb) 時卻寫成了memset (&b, cb, 0x00)——我也不記得這個語法。我不介意你是否忘記了半成品或犯了其它的語法錯誤。我不是要尋找當即能夠寫出語法正確的、完美代碼的人；這根本不是代碼練習的初衷。我在試著弄清楚你是怎樣解決問題的。
對我而言，這很容易看出來你是有著良好的問題解決技巧、且善於組織的人，不錯。留下足夠空間——你或許需要深入某些代碼行。一邊慢慢寫、寫清楚，一邊解釋你在做什麼。如果代碼干淨、組織良好、清晰、模糊最少、語法正確，我們兩個就更容易分辨出代碼是否設計良好、沒有 bug。經過一些簡單的測試用例——不要只是扔出某些代碼說“搞定，沒問題了！”
面試者表現出來的、大多數代碼問題不需要任何“Aha！”式的領悟或火箭科學式的算法。沒人會要求你實現一個帶有 4-5 種不同的龍格－庫塔法【注1】方程求解。我們將要求你實現一個哈希表或在帶有“bar”的字符串裡替換每一個“foo”的實例。Eric Carter【我當時的經理和合著者】的辦公室有一本《C++編程習題與解答》，因為它是面試問題的寶典。有一場技術面試？挑選一本入門級的編程文本，隨機挑選一些問題，在白板上搞定。嘿嘿，我會立即隨機浏覽一下。下面是從這本書不同地方摘錄的一些簡單問題：
null。template上面隨便一條都是高度經典的編程問題。在你對它們說“這個簡單！”之前，請在寫代碼之前想想你從這些問題描述中遺漏了什麼：
字符串指針：它指向哪種字符編碼？7-bit ASCII chars、UTF-8、UTF-16、或某種 ANSI 編碼？你打算要求應聘人員，或者你打算假設你正在為以前就有的某種操作系統編寫 C 代碼，它不存在包含中文字符的字符串？提示：微軟為 PDP-11 機編寫了非常少的 C 代碼。類似地，程序員從來不必處理非羅馬字符集。
小於操作符：你不得不處理了非最簡分數的情形了嗎，比如 2/4 ？不合法的分數，比如 2/0 呢？你能夠假設關於數字的大小嗎？
你正在打亂數組：你注意到了黑客是否能夠預測其次序？我們需要加密長度的隨機性，或者可重現的偽隨機？這是用於涉及金錢的在線撲克游戲、還是一種算法的測試用例？等等。
如果不把這些問題搞清楚，就無法很好地設計，也就無法愉悅地編寫生產環境的高質量代碼。
應聘人員經常在關注代碼上犯錯誤，就像代碼本身憑空存在一樣。這是非常不現實的臆測！代碼不但要組織精良和正確，而且還要可維護、可測試、且解決一個真正的客戶問題。當你去面試時，在寫代碼的時候，要考慮：
這不是說，當聽到“字符串”就不自覺地想到 char * 的人應該被排除在外。但是，如果你知道 BSTR 的存在，我就更加確信你簡歷上寫的“精通 COM 編程”！還有，我明白，剛走出校門的應聘人員經常在這種“真實世界”的考慮上欠缺經驗；我將放寬這部分要求，以關注他們天生的智力、代碼天賦和長期潛力。
最後，讓我重申，技術面試是很難的，甚至聰明人有時候也會搞錯。在我面試全職工作時，兩個團隊沒有雇傭我！不過這是另一個故事了。
