我曾在一次面試中要求一個很有經驗的嵌入式軟件開發人員寫出一個反轉一段字符串并輸出到屏幕上的程序。他在這個題目上掙扎了很久。這個家伙是個很神奇的人。你給他一些沒用的零件，他能建造一個機器人，并能用程序控制它在屋里走來走去。他曾經參與過研制衛星，并且這個衛星現在正在軌運行。他只用左腦都比我能干。但是對于這個題目他卻從來、從來沒機會干過：在屏幕上顯示什么東西。

　　有些人就有這種技能，能在面試中問出正確的問題，發現優秀的程序員。而有些人卻害怕提問，畏首畏尾，問一些從網上拷貝下來的問題，自己沒主見，只會跟隨其他面試官的意見。但面試對于大多數開發人員來說是一項很基本的技能。一次失敗的招聘會給一個組織造成很嚴重的長期的后果，因為很水的雇員會把其他很水的人也帶進公司。另一方面，把優秀的應聘者拒之門外對公司也是一種傷害。

　　一場技術性的面試至少包括三個部分。在第一部分里，我們要做的是看應聘者的簡歷上寫的是否符合實際情況。在第二部分里，我們要評估一下候選者究竟有多少實際經驗。最后，我們要用一些問答選項或編程問題來測試這些經驗。

　　第一部分：測試簡歷的真實性

　　有一次我跟一位同事面試一個候選人。當面試完之后，我覺得這個候選人還可以，但不是十分出色。可我的同事看起來很不滿意。“他撒謊，他說他會XXX技術，可很顯然他根本沒有做過這種技術。絕對不能要這種人。”雖然這XXX技術對我們公司并不是很重要，“因為他撒了這個慌，”我的同事繼續說，“我就不會相信他在簡歷上寫的任何東西了。”

　　應聘人員應該在簡歷中用一種很積極的色彩來描繪自己。然而，這種積極的描繪應該有個度，過了這個度，就表達的不正確了。在上面的例子中，我并不和我的同事一樣覺得這個事很嚴重，因為我事先就假設了，簡歷上的任何東西都是假的，除非被證明。如果簡歷上說，“擅長于XXX技術”，那么我就認為這個應聘者可能僅是知道XXX技術這個名字。

　　如果簡歷上說，“在一個開發多線程股票交易系統的團隊里工作，”那我就會認為應聘者可能只是為這個系統挑選了一下背景的顏色。我的要求一向不嚴格，除非碰到了一位有十年工作經驗、已經不再寫代碼的家伙。如果有人說他開發了OpenOffice軟件的文本格式化工具，或擁有哲學博士學位，那我們就很容易假設他們有什么技能了。假設一無所有。一切都要證實。

　　對于簡歷上每條相關的描述，我會首先估摸一下應聘者的實際情況。然后，我通過下面的交談來證實。

• 開發過一個實時操作系統作為練習項目。
  你工作的團隊有多大？15個成員？哦，那么，你實際上負責哪部分的？消息隊列？很好！請描述一下一個高優先級的任務向一個低優先級的任務發送消息時會發生什么情況？
• 完全自主開發了一套為無線安全系統使用的音頻傳輸協議。
  你的團隊有多少人？只有你？哦，你是如何測試的？你為什么不使用RTP呢？
• 給XXX引擎修復Bug。
  請你描述一下你曾發現過的一個特別有挑戰性的bug，以及你是如何修復它的。

　　第二部分：發現實際的經驗

　　擁有更多的經驗是一個優秀人才的很好的指標。有經驗的開發人員都是從犯錯誤中成熟的。他們知道何時該，何時不該使用設計模式。他們有第六感，能感覺到需求的哪一部分需要修改，哪一部分要保持原樣。他們知道何時該偷懶，何時該考究。是真實的經驗讓優秀的開發者和平庸的開發者之間的差距大的無法跨越。

　　并非所有的經驗都是等效的。很有可能，對于某個人，他通過多年的工作，在很多的任務中寫或重新無數的代碼，犯了許多的錯誤，就能獲得扎實的技能。而另一種情況，一個人會在十年的時間里只在一個項目里修改了一行代碼，沒有學到任何新的東西。

　　發現隱藏的時間

　　很多偉大的程序員都是在他們大學的第二年就開始編程了。當他們離開學校時，他們就已經有了幾年的工作經驗了。還有，有些很神奇的程序員在他們很小的時候就開始學習編程的藝術了。我也認識好幾個人在他們十幾歲或更小時就寫出來一些不算小的程序了。這些信息你是在簡歷上找不到的，需要你在面試中把它們引誘出來。

• 你是怎么進入到軟件開發這一行的？
• 你曾經學過的第一種編程語言是什么？

　　經驗的密度

　　很多神奇的程序員只是在他們工作的時間里編碼。這很好，工作生活很平衡，你沒有理由不雇傭這樣的人。然而，在工作和學習之余做一些個人的編程項目是一個優秀的人才的很好的指標。有業余編程經驗的應聘者很明顯有更豐富的經驗，更適合公司。沒有個人項目？這里有其他幾點也能做這方面的指標：

• 在很小的團隊或小組里工作。
• 參與過很多各種各樣的項目。
• 對一個大型項目的各個抽象層面上都有很詳細的了解。
• 在一個項目組里作為主要開發者。

　　第三部分：驗證經驗

　　在對應聘者有了一個基本的真正經驗水平的感覺后，就開始對他們進行重要的實際編程經驗的驗證了。幾分鐘的時間對于一個真正的測試肯定是很不充分的，但也只有這樣了。我們可以通過對編程開發的各個領域進行提問來認識應聘者對這些知識掌握的深度和廣度。當然了，你對應聘者技能水平的看法會由于你自身的經驗水平而有所偏向。對于你不太熟悉的領域你不可能對答案做出正確的判斷。所以我們一般同時會有好幾個面試官。

工作職務的不同會有不同的面試主題。然而，下面幾個領域是很常見的：

• 數據結構和算法
• 多線程
• 字節操作
• 內存分配
• 對象，繼承，設計模式
• 遞歸
• 匯編知識和程序運行原理

　　我選擇的每個領域都有一個精心挑選的很基礎的問題（“什么是一個信號？”）。問題很基礎，只要應聘者在這個領域做過一些工作就能回答上這些問題。每個領域都有一些其它的較深入的問題。候選人對這些問題的回答能證明他們到底是不是專業。例如，如果你問一個有經驗的嵌入式軟件開發人員如何把0×4c轉化成二進制，他寫出一個4×16+12，這就不是很對了。

　　編碼問題

　　在完成了上面的步驟后，我通常就已經能認定了這個候選人是否能過關，如果還有困難，那編碼問題會幫我掃除最后的障礙。這個很重要，即使在電話面試里也不能漏過。為了行之有效，在面試之前，你要好好的思考和計劃要提出的編碼問題。問錯誤了，回答也就沒意義了。

　　首先，問題的選擇必須基于應聘者的工作經驗之上。如果你想起來3D飛機，想把所有問題都圍繞著它進行，這樣會有很妙的問題。但你還是省省吧，吃午飯時跟同事說說還行。如果招聘的工作跟3D圖形沒一點關系，那這個候選人就肯定被不公平的排除掉了。

　　問題必須精確的表達出來。“寫出一個用來移動一摞卡片的函數”，這個表述就十分的含混不清。要給出功能性標題，避免誤解，這種事情經常發生。如果你不小心，面試者有可能回答的是一個比你提出的問題更難或者更簡單的問題，而不是你想要問的。如果回答的是更難的問題，那還好，除非難題讓他目瞪口呆。如果回答的是更簡單的問題，那沒有什么用處。為了防止浪費大量的時間，在他們答題的幾分鐘后問一下他們的答題綱要，看看他們的理解是否在正確的方向上。

　　更進一步

　　上面的指導并不能解決所有問題。這些主要是針對工作經驗。你也許會錯過一些沒有多少經驗但有非常大的潛力的優秀程序員。特別是當面試官想通過一些不用編碼的難題來考察應聘者解決問題的能力的時候。

　　這里所說的這些面試技巧都是要基于一種假設、可能性、內部直覺。假設候選人是一個很出色的開發人員。那一個出色的開發人員應該具有哪些品質呢？你沒法直接的測量這些品質，所以你需要想：一個具有這些品質的優秀開發人員對這樣一個特定問題進行快速回答的可能性是多少？你不可能通過面試對一個候選人進行100%正確的評價，但通過盡量周全的提問，你會做到很接近這個結果。

　　[英文出處]：Finding awesome developers in programming interviews