我最近收到一封來自印度讀者的郵件,讓我就技術面試談下看法。關於這個話題,本文再現了我在 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 編程”!還有,我明白,剛走出校門的應聘人員經常在這種“真實世界”的考慮上欠缺經驗;我將放寬這部分要求,以關注他們天生的智力、代碼天賦和長期潛力。
最後,讓我重申,技術面試是很難的,甚至聰明人有時候也會搞錯。在我面試全職工作時,兩個團隊沒有雇傭我!不過這是另一個故事了。