軟體面試實戰指南（第三版）
作者：周思博（Joel Spolsky），時間：2006年10月25日
翻譯：崇斐，時間：2014年7月3日
@laomanong 補註：原文標題是《The Guerrilla Guide to Interviewing》，直譯是“游擊隊的面試指南”，“游擊隊”是相對於“正規軍”（現在大公司流行的面試方法）來說的。Joel 在第三版加上這個詞，意思是說他的方法還不是主流（現在其實很多軟體公司已經在用它了），但是他覺得大公司的方法弊端太多（經理面試，問腦筋急轉彎問題，先入為主的印象分，忽視基本功考察，稀裡糊塗地聘用等），所以不容易招聘到優秀的人才。
以下是正文。
一支由無政府主義者、自由戀愛提倡者和香蕉權利煽動者組成的雜牌軍，將愛之船從巴亞爾塔港劫持走了，並且威脅說，除非滿足他們的要求，否則這艘載有616名乘客和327名成員的船隻將在七天後沉沒。要求是什麼？一百萬沒有做過標記的的小額美鈔和WATFIV[1]的GPL實現，也就是指，著名的WATFIV編譯器。（令人驚訝的是，這些自由戀愛者居然只能找到這麼點與香蕉權利煽動者達成一致的東西。）
作為嘉年華航運公司的首席程式設計師，你必須確認你能否從零開始，在七天內開發出一款Fortran編譯器。你有兩名程式設計師下屬來協助你。
你能做到嗎？
“嗯，我覺得，這取決於……”你答道。寫這種文章的好處之一，就是我可以隨意編造你的發言，而你卻拿我沒辦法。
取決於什麼？
“呃，我的團隊能夠使用UML生成工具嗎？”
這真的很重要嗎？三個程式設計師，七天時間，完成WATFIV。UML工具就一定能搞定嗎？
“恐怕不行。”
好吧，那麼，靠什麼來完成呢？
“我們能有19寸顯示器嗎？能隨便喝Jolt可樂[2]嗎？”
老樣子，這真的很重要嗎？難道你做不做得到是靠咖啡因來決定嗎？
“呃，看來也不行。哦，等等，你說我有兩名程式設計師下屬？”
沒錯。
“他們是誰？”
這真的很重要嗎？
“當然！如果團隊相處不和諧，我們就沒辦法共事。我知道有幾個超級程式設計師能夠用一週時間獨立完成Fortran編譯器，但絕大多數傢伙花上六個月都沒法寫出一個顯示啟動標誌的程式。”
看來我們終於搞明白一些問題了！所有人都會說，人員是軟體專案中最重要的一部分，但沒人能真正確定要做些什麼。如果你想擁有優秀的程式設計師，第一要務就是聘用合適的人才，這也意味著你必須能夠發現誰才是最適合的，而這通常是在面試中完成的。所以這篇文章講的全都是與面試有關的內容。
（現場面試僅僅是招聘程式的一個環節，整個程式從篩選簡歷和電話面試開始。這篇文章只涵蓋現場面試的內容。）
對於每一個應聘者，你應該準備至少六名面試官，其中包括至少五名會與他共事的人（這指的是其他程式設計師，而不是經理）。你知道那種對於應聘者只有簡陋的經理面試，並僅僅以此做出決定的公司嗎？這些公司不會擁有優秀的員工。要在一輪面試中矇混過關實在太容易了，尤其是由非程式設計師面試程式設計師的時候。
即使在六名面試官中只有兩名認為應聘者不值得聘用，也不要聘用他們。這意味著你在面對不需要聘用的人時，可以技術性的在兩輪面試後就結束“整天”的面試，這並不是壞事，但為了避免過於殘忍，最好提前告訴應聘者面試次數。我聽說有些公司允許任何面試官刷掉應聘者。我覺得這太過頭了；我可能會讓任何資深員工刷掉面試者，但並不會只因為一名新來的員工不喜歡就否決掉。
不要嘗試同時面試一群人，這並不公平。每輪面試應該由一名面試官和一名應聘者組成，在一間有一塊白板並且關著門的房間裡進行。基於豐富的經驗，我可以告訴你，如果一場面試中花費不到一個小時，那麼你是無法做出決定的。
在你的面試過程中，你會見到三種型別的人。天平的一端是無知的大眾，他們缺乏這項工作所需的大部分基礎能力。這些人很容易被發現並且淘汰掉，通常只需提兩三個小問題即可。天平的另一端是睿智聰慧的超級明星，他們可以為了好玩，就用NDS的組合語言在一個週末內寫出Lisp編譯器。而在兩者中間，有大量的似乎可以做出貢獻的“可能人選”。竅門就在於找出超級明星和可能人士間的差別，因為祕訣在於你並不想聘用任何一名可能人選。絕不。
在面試的結尾，你需要準備對應聘者做出一個明確的決定。這個決定只有兩種結果：聘用或者不聘用。沒有其他可能的答案。絕對不要說：“聘用他，但別把他放在我的團隊裡。”這很粗魯，並且暗示著對方並沒有聰明到能和你共事，但對於其他團隊的笨蛋來說可能已經足夠聰明瞭。如果你發現你打算說：“聘用他，但別把他放在我的團隊裡”，那麼直接翻譯為“不聘用”就行了。即使你發現某個應聘者足夠勝任你特定的工作，但不適合其他團隊，那也是“不聘用”。在軟體行業，事情變化得太頻繁也太迅速，你需要能夠勝任你交給他們的任何程式設計工作的人。如果因為某些原因，你發現了一名非常非常非常擅長SQL，但完全學不會哪怕任何其他東西的白痴專家，不聘用，否則你就是在用長痛換短痛。
絕對不要說“或許吧，我說不準。”如果你說不準，那意味著“不聘用”。這比你想象得容易。說不準？那就說不！如果你猶豫不決，那意味著“不聘用”。絕對不要說，“呃，我覺得，還是聘用他吧，不過我對此有一點擔心……”這也意味著“不聘用”。把所有不確定的情況都機械式地翻譯為“不”，就沒問題了。
為什麼我那麼固執呢？因為拒絕一個好人選比聘用一個差人選要好太多了。一個差人選會耗費掉大量的金錢和精力，並且讓其他人浪費時間來給他們擦屁股。開除你錯誤聘用的人得花上好幾個月，並且會相當地困難，尤其是他們想和你對簿公堂時。在某些情況下可能完全無法開除任何人。糟糕的員工會破壞優秀員工的士氣。並且他們可能是糟糕的程式設計師但同時卻又是個很好的傢伙，或者他們的確需要這份工作，所以你不忍心開除他們，否者就會犯了眾怒，或者可能是其他任何窘境。總之是糟透了。
從另一方面說，如果你拒絕了一個好的人選，我是說，我覺得有些地方並不公平，但是，嘿，如果他們的確那麼聰明，那不用擔心，他們會有很多好的工作機會的。不用擔心你會因為拒絕太多的人選而找不到人用。在面試過程中，這並不是你的問題。當然，找到優秀的人選是很重要的。但是當你實際面試一個人的時候，要假設還有900人在門外排隊等著面試。不管優秀的人選看起來是多麼難找到，都不要降低你的標準。
好吧，我還沒有告訴你最重要的部分——你如何確定是否該聘用某人？
原則上很簡單。你要找的人必須
聰明，並且
能做事（get things done）。
就這樣。這就是你需要的。記住這些，每天晚上睡覺前都背誦一遍。在簡短的面試中你並沒有足夠的時間來發現更多東西，所以不要浪費時間來嘗試瞭解應聘者滯留在機場時是否保持愉快，或者是真的懂ATL和COM程式設計還是假裝的。
那些聰明但是不做事的人通常都有博士學位，並且在大公司工作，但因為太脫離現實，公司裡沒人會理他們。與其準時完成工作，他們更喜歡反覆思索某個問題中的學術內容。這種人很容易辨別，因為他們喜歡指出兩個南轅北轍的觀點之間純理論性的相似點。舉個例子，他們會說，“電子表格只是程式語言的一個特例”，然後花一週時間寫出一份華麗的白皮書，來闡述電子表格作為一門程式語言時的體現出的計算機語言特性。很聰明，但沒什麼用。另一種鑑定這些人的方法是，當你正準備釋出beta版的那一天，他們常常會端著咖啡杯出現在你的辦公室，想和你進行一場關於JAVA內省與COM類庫之間優劣性的漫長對話。
那些能做事但是不聰明的人會做出一些蠢事，就好像不經過大腦一樣，於是其他人就得來幫他們擦屁股。這讓他們成為公司的淨負債，因為他們不但沒能做出貢獻，反而浪費了優秀員工的時間。這種傢伙會用他們在前一個晚上剛讀到的訪問者模式，而且還是完全理解錯誤的，來重構你的核心演算法，用AdderVistior類（沒錯，還有拼寫錯誤）和VisitationArrangingOfficer單例來代替使用簡單的迴圈完成的陣列累加操作，然後你會發現你的程式碼再也跑不動了。
你該如何在一場面試中發現聰明人？第一個標誌就是你不用反覆進行解釋。你們的交談會很流暢。聰明的應聘者經常會說出一些有見地、有想法、或者很敏銳的觀點。因此面試的重點之一就在於創造一個能讓人展示他們有多聰明的情景。最差勁的面試官則是吹牛大王。這種傢伙從頭到尾都喋喋不休，讓應聘者只來得及說，“沒錯，簡直太對了，我發自內心地認同你的想法。”吹牛大王可能聘用任何人——他們認為應聘者一定很聰明，因為“英雄所見略同！”
第二差的面試官是益智問答者。這種傢伙認為聰明意味著“知道許多東西”。他們會問一大堆瑣碎的程式設計問題，答對了就能得分。舉個搞笑的例子，這有一個世界上最爛的面試題：“在Oracle 8i裡，varchar和varchar2有什麼區別？”這個問題簡直糟透了。知道這種雞毛蒜皮的人和你想要的人之間根本沒任何關聯。誰在乎有什麼區別？你花十五秒時間就能在網上找到答案！記住，聰明並不意味著“知道瑣碎問題的答案”。總而言之，軟體團隊需要的是有才華的，而不是隻有特定技能的人。任何能夠帶到工作中的技能都會從技術層面上在數年內被淘汰掉，所以，最好聘用那些能學會任何新技術的人，而不是那些剛好在現在知道怎麼用JDBC連線MySQL資料庫的人。
但大體上說，儘可能瞭解一個人的辦法就是讓他們說話。向他們提一些開放性的問答題和解答題。
那麼，你會問些什麼？
我的個人面試題庫源自於我在微軟的第一份工作。事實上微軟著名的面試問題有成百上千。任何人都有一套他們自己喜歡的題集。你，同樣的，也能發展出一套自己的題集和麵試風格，來幫你作出聘用/不聘用的決定。下面是一些我成功使用過的技巧。
在面試之前，我會通讀一遍應聘者的簡歷，並且在一張紙片上簡略地記錄面試計劃，這是一系列我打算問的問題。下面是一份程式設計師面試的典型計劃：
- 個人簡介
- 關於應聘者最近從事的專案的問題
- 簡單的程式設計問題
- 指標/遞迴問題
- 你對此是否滿意？
- 你還有其他問題嗎？
我儘可能地避免對面試者產生先入為主的觀念。如果你僅僅因為一個人是麻省理工的博士，在面試開始前就認為他很聰明，那麼不管他們接下來一小時內說了些什麼，都改變不了你一開始的偏見。如果你因為他們讀的是社群大學就覺得他們頭腦簡單，那麼不管他們說什麼都沒辦法改變這個第一印象。面試就像是一架非常非常精密的天平——很難基於一小時的面試來評判某人，這簡直是千鈞一髮。但如果你事先對應聘者有一點點的瞭解，這就像是在天平一側加了一大顆砝碼，那麼面試就白做了。曾經有一次，招聘專員在面試前來到我的辦公室，說：“你會喜歡這傢伙的。”這簡直讓我抓狂。我當時應該說：“好吧，如果你那麼確定我會喜歡他，為什麼不直接聘用他，這樣我就不用浪費時間來進行面試了。”但我當時太年輕也太天真了，所以我還是去面試了。當他說了些不太聰明的東西時，我告訴自己，“哎呀，人都是會犯錯的嘛。”我帶著有色眼鏡來看待他所說的一切。儘管他是個蹩腳的傢伙，最後我還是說，聘用。你知道嗎？其他面試他的人都說，不聘用。所以：不要聽招聘專員說的話；不要在面試之前打聽應聘者的情況；並且，在你們都獨自做出決定之前，絕對不要和其他面試官談論應聘者。這就是科學的思想。
面試的自我介紹階段是為了讓應聘者放鬆。我會問他們是否在飛機上感覺好嗎。我會花大約30秒來告訴他我是誰，還有這場面試會如何進行。我總會再三向應聘者保證，我們只對他們解決問題的方式感興趣，而不是實際的答案。
第二階段是關於應聘者最近從事的專案的問題。比如面試大學生時，就問他們的學位論文（如果有的話），否則就問他們曾經參與過大規模作業，並且樂在其中的課程。比如說，有時我會問：“你上學期學的課程中最喜歡哪門？不一定需要與電腦有關。”而當面試有工作經驗的人時，你可以談一談他們上一份工作中最後的任務。
同樣的，問一些開放性的問題，坐下來慢慢聆聽，偶爾當他們要停下來時說一句“多告訴我一些東西”就行了。
在開放性問題中你應該關注什麼呢？
首先：尋找熱情。聰明人總是對他們的工作充滿熱情。他們談論到這些課題時會非常興奮。他們的語速會加快，整個人生機勃勃。強烈的負面資訊也是個好兆頭：“我的上一個老闆只會用VAX電腦，所以他要求所有東西都在上面做。真是個蠢貨！”有太多的人只是在工作，但並不關心怎麼去做。這種人很難對任何事情提起興趣。
糟糕的應聘者對面試並不在意，在面試時也毫無熱情。應聘者對某件事充滿熱情的徵兆是，當他們談到這件事時，會暫時忘記他們正在面試中。有些應聘者一開始會因為在面試而非常緊張——這很正常，當然，所以我總是忽略掉它。但接下來當你和他們談到單色計算藝術時，他們會變的非常興奮，並且一點都不緊張了。很好，我喜歡這樣熱情的傢伙，因為他們關注於他們所做的事（想看看什麼是單色計算藝術的話，拔掉顯示器電源就行了）。你可以在某些事上質疑他們（試試吧——等他們談到一些可能是對的事，你就說“那不可能是對的”），然後他們會嘗試辯解，即使在五分鐘前滿頭大汗，因為他們是如此的投入以至於忘了你即將決定他們的命運。
其次：優秀的應聘者會在所有層面上都仔細地把事情解釋清楚。我曾經刷掉了一些應聘者，因為他們在談到上一個專案時，沒法用常人能理解的方式來說明它。計算機專業的人經常會認為所有人都知道什麼是貝葉斯法則或者O(log n)。如果他們開始這樣幹了，儘快打斷他們，然後說：“能不能麻煩你，僅僅是練習一下，用我祖母能聽懂的話來解釋下這東西？”這時候許多人依舊會使用專業術語來描述，讓人完全無法聽懂。停！你基本上不會想聘用他們了，因為他們不夠聰明，不明白如何讓他人理解他們的想法。
再者：如果應聘者做的是團隊專案，尋找他們擔任領導角色的跡象。應聘者可能會說：“我們在做X，但老闆要的是Y而客戶要的是Z。”我會問：“那麼你做了什麼？”好的答案可能會是：“我聯合其他組員一起寫了一份提案……”而壞的答案可能會是：“呃，我什麼都做不了。這情況根本無解。”記住，聰明並且能做事。要知道一個人是否能做事的唯一途徑，就是看他們過去是否曾經打算把事情做完。實際上，你可以直接要求他們給你一個例子，說明他們過去曾經扮演領導角色並且把事情完成——比如說，克服某些制度惰性。
不過，面試中的絕大部分時間，應該用來讓應聘者證明他們能夠寫程式碼。
再次嚮應聘者說明，你知道不用編輯器寫程式碼是很難的，你會不介意他們把白板塗得亂七八糟。同樣你得明白不使用編譯器時很難寫出沒有bug的程式，這些問題你都得考慮進去。
在每天的第一場面試裡，我曾經在一開始問一個非常非常簡單的程式設計問題。在dotcom的熱潮時期，我不得不開始這樣做，因為那時有太多人認為HTML就是“程式設計”，然後就跑來面試，而我就需要個辦法來避免在他們身上浪費太多時間。這是一些任何在任的程式猿都能在一分鐘內解決的問題。舉些例子：
- 寫一個函式來判斷一個字串是否以大寫字母A-Z開頭
- 寫一個函式來計算給出半徑的圓的面積
- 將一個數列中的值求和
這些入門級的問題似乎太簡單了，所以當我頭一次提問時，我承認我的確以為所有人都能順利回答。我發現雖然所有人都解出了問題，但他們花的時間卻差別很大。
這讓我想起了為何我不能通過證券交易來維生。
Jared是名證券交易員。他總和我談起他做的有趣的交易。有種東西叫做期權，然後有認購期權、認沽期權和市場陡峭，因此你需要在陡峭化交易時購入，這一切令人費解，但不可思議的是我居然都知道這些詞語的意思，我知道看跌期權的意思（將東西按照一定價格賣出的權利，而不是義務），並且如果你擁有看跌期權而股市上漲，我能在三分鐘內看出會發生什麼，但需要整整三分鐘來確認。而當他告訴我一個更復雜的故事，其中看跌期權只是第一步，故事中還有更多別的部分時，我很快就亂掉了，因為我已經想不過來了（“讓我們來想想看，股市上漲，這意味著利率下降，而看跌期權是賣出東西的權利……”），直到他拿出圖表來向我演練才搞明白。於是我目光呆滯，並且非常難過。雖然我明白任何一個環節，但我不能迅速地瞭解整體。
在程式設計中同樣有相同的情況。如果基礎概念並沒有簡單到讓你不假思索，你就無法進行整體的思考。
Serge Lang，耶魯大學的數學教授，習慣在微積分的第一堂課裡給他的學生出一道相當簡單的數學題，簡單到幾乎所有人都會做，但有的人做得和寫字一樣快，而其他人的紙上卻一片空白。然後Lang教授宣佈，那些解題和寫字一樣快的學生能夠在微積分課程中拿到A，其他人則不行。求解一道簡單代數題的速度可以準確的預測他們微積分的最終成績，這相當於整個學期的作業、測試、期中考和期末考的效果。
你看，如果你不能以100英里每小時的速度飆過簡單的東西，你就沒辦法更上層樓。
但就像我所說的，優秀的程式設計師會站起來，在白板上寫下答案，有時還會加上些奇思妙想（噢！Unicode標準！漂亮！），這隻花了三十秒，現在我得看看他們是否真的優秀，所以我拿出了大傢伙：遞迴和指標。
15年的面試經驗讓我堅信，最優秀的程式設計師能夠輕鬆地同時處理多個抽象層次。在程式設計中，具體意思是他們能毫無壓力地解決遞迴問題（這需要你同時考慮到堆疊呼叫中的多個層次）或者複雜的指標演算法（物件的地址就像是物件本身的抽象表示）。
我終於意識到理解C語言的指標不是一門技能，而是一種才華。在電腦科學的第一年課程中，學期開始時總是有大約200個孩子，曾經在四歲時就用BASIC在他們的電腦上寫過複雜的冒險遊戲。他們在大學裡很輕鬆地學習著C和Pascal，直到某一天教授講到了指標，然後突然間他們學不會了。他們再也搞不懂任何東西。90%的人會退出並且改修政治學，然後他們會告訴朋友因為電腦科學課裡，好看的異性太少了，所以他們才換了專業。不知為何，大多數人看起來天生就缺乏能夠理解指標的腦回路。指標需要一種複雜的雙重間接思考模式，而有的人就是做不到，但對於優秀的程式設計來說卻是非常關鍵的。許多“指令碼高手”從複製JavaScript片段到他們的網站而開始瞭解程式設計，然後開始學習Perl並且從來沒了解過指標，而他們永遠沒辦法寫出你需要的高質量程式碼。
這就是所有你聽說過的這些著名的面試問題的根源，比如“反轉一個連結串列”或者“在一個樹形結構中尋找回路”。
令人悲哀的是，儘管我認為所有優秀的程式設計師都應該能夠處理遞迴和指標，並且這是辨別某人是否是優秀程式設計師的很好的辦法，但事實是在如今，程式語言已經幾乎不再需要這種技藝了。在十年前，很少有電腦科學的學生在沒學過遞迴和函數語言程式設計，以及C或者Pascal的資料結構時就能夠畢業，而如今很可能許多名校都只教Java了。
如今你可能面試到的許多程式設計師，都會認為遞迴、指標，甚至資料結構，都只是低階的實現細節，而這些在如今的許多令人幸福的程式語言中已經被抽象化掉了。“你上次寫排序演算法都是什麼時候的事了？”他們竊笑著說。
但是，我還是不在乎。即使我的急救醫生只需要把電子式心臟除顫器放在我的胸膛上，然後按下大大的紅色按鈕，我依然希望她懂得解剖學。我也希望程式設計師懂得深入到CPU層次進行程式設計，即使Ruby on Rails能夠理解你的想法，然後點三下滑鼠就能架設起完整的Web 2.0社交網站。
即使從表面上看，面試的形式只是讓應聘者在白板上寫程式碼，但我真正的目的是對此進行討論。“你為什麼要那樣做？”“你的演算法的效率怎樣？”“你有沒有忘了些什麼？”“你程式的bug在哪裡？”
這意味著我並不擔心我給出的程式設計問題太過困難。只要應聘者有機會開始解答，我很樂意一路上提供一些小小的線索，或者說小小的踏腳石吧。我會讓一個人，比如說，將一個三角形對映到一個平面上，這是個典型的圖形學問題，我也不介意提示一下三角函式（SOH-CAH-TOA[3]，嘿活計！）。而當我讓他們快一點時，我會稍微提醒下他們用查表法。注意，這些我很樂意提供的提示，僅僅只是瑣碎問題的答案——那些你用Google就能找到的東西。
難免的，你會在他們的函式裡找到bug。所以我們就來到了面試計劃中的第五個問題：“你對這份程式碼滿意嗎？”你也許會想問：“好吧，知道bug在哪兒嗎？”這是典型的糟透的開放性問題。所有程式設計師都會犯錯，這沒啥問題，他們只需要能找出錯誤。使用C的字串函式時，絕大多數大學生都會忘了給新字串加上結尾。使用大多數函式時，他們經常會出現差一錯誤。有時他們還會忘了寫分號。他們的函式處理0長度字串時跑不對，或者會當記憶體分配失敗時產生GPF錯誤……只有在很稀有的情況下，你能遇到一名一次寫完就沒任何bug的應聘者。這種情況下，問題就更有趣了。當你說，“程式碼裡有一個bug”，他們會仔細地重審一遍程式碼，然後你就能看到他們是否能圓滑地說明這份程式碼沒任何問題。
面試的最後一個環節，是詢問應聘者他們是否有什麼其他問題。記住，即使是你在面試他們，一個優秀的應聘者依舊擁有許多工作機會來選擇，他們也在用這一天來確認是否願意與你共事。
有的面試官嘗試用面試者問的問題是否“智慧”來進行判斷。從個人來說，我並不在意他們會問些什麼，因為這時我已經作出了決定。麻煩之處在於，應聘者在一天內得面對五到六個面試官，所以很難讓他們給出五到六個不重複的，而且有見地的問題，所以即使他們沒任何問題，也沒關係。
我總會在面試結尾留出大約五分鐘時間來嚮應聘者推銷這家公司和這份崗位。即使你不打算僱用對方，這也還是很重要。如果你有幸找到了一個非常優秀的人選，在這時你會盡你所能地確保對方願意來與你共事。即使對方是個糟糕的人選，你依舊希望對方喜歡你的公司並且帶著好的印象離開。
啊，我才想到我應該多給你一些糟糕問題的例子。
首先，迴避違法的問題。在美國，在面試時詢問任何有關於種族、信仰、性別、民族血統、年齡、兵役義務、兵役狀況、性取向或者身體缺陷的問題都是違法的。如果簡歷上寫到對方曾經是海軍陸戰隊，即使你想閒聊地問對方是否去過伊拉克，也是不允許的——針對兵役狀況的差別對待是違法的。如果簡歷上寫到對方在海法就讀過以色列理工學院，即使在閒聊時也不能問他們是否是以色列人，即使你只是因為你妻子是以色列人而想聊一聊，或者因為你愛吃炸豆丸子[4]——針對民族血統的差別待遇也是違法的。
然後，迴避任何會讓人覺得你會在意，或者會差別對待的問題，儘管你對這些東西並不在意也不會有差別對待。我能想到的最好的例子是問某人有沒有孩子或者有沒有結婚。這可能會給人一種印象，覺得你認為有小孩的人沒法在工作上投入足夠的時間，或者會跑去請產假。基本上，只問那些與對方應聘的工作完全相關的問題就行了。
最後，迴避腦筋急轉彎，比如用6根同樣長度的棍子搭出4個相同的等邊三角形。或者其他的包含海盜、彈珠和密碼的題目。這些大多是“原來如此！”的問題——知道就會不知道就不會。對於這些問題，答得出來只代表你聽說過這些腦筋急轉彎。所以作為一名面試官，通過判斷對方是否靈機一動，你並不能得知對方是否“聰明/能做事”。
（編注：推薦閱讀：《Google承認那些臭名昭著的智力題對其招聘毫無用處》 ，還有 37 Signals David 的這篇《為什麼我們不用智力題來面試程式設計師？》）
過去，我曾經用過“不可能的問題”，也就是所謂的“模糊問題[5]”。典型的例子就是“西雅圖有多少個鋼琴調音師？”應聘者並不知道答案，但聰明的人不會放棄，他們會很樂意去嘗試，並且估算出合理的數字給你。讓我們想想看，西雅圖大概會有……一百萬人吧？那麼也許1%的人有鋼琴？然後每架鋼琴每隔幾年就得調一次音吧？然後大概需要35分鐘來調音？當然咯，全都錯了，但至少他們在攻克這個問題。“好吧，35分鐘，但是在不同鋼琴間移動需要花掉多少時間呢？”
“很好地切入點。如果鋼琴調音師能提前預約好時間，那麼他們也許能安排好計劃來儘可能減少交通時間。你懂的，是一起把Redmond的所有鋼琴搞定，而不是一天中在520公路來來回回跑三趟。”
一個好的模糊問題能讓你和應聘者進行討論，來幫你評判對方是否聰明。一個糟糕的“原來如此！”海盜問題通常只會讓應聘者盯著你一陣子然後說他們被難倒了。
如果，在面試的結尾，你確認這個傢伙足夠聰明並且能做事，並且其他四個或者五個面試官也同意，那麼你錄取對方應該沒什麼問題。但如果你有任何的疑問，那最好等等看是否有更好的人選。
決定是否聘用應聘者的最佳時機是在面試結束後的三分鐘左右。太多的公司允許面試官等到幾天甚至幾周後才提交反饋資訊。不幸的是，時間過得越久，你記住的東西就越少。
我會讓面試官在面試之後馬上寫下反饋意見，不管是“僱用”還是“不僱用”，並且附上一兩段說明。截止時間是面試結束後15分鐘。
如果你無法作出決定，有一個很簡單的方法。不僱用。不僱用你不確定的人就行。這在頭幾次會有點讓人頭疼——如果我們再也找不到優秀人選了怎麼辦？沒問題的。只要你的簡歷篩選和電話面試進行得不錯，在現場面試中大概會有20%的錄取率。然後當你遇到了聰明的，能做事的人選，你會知道的。如果某人不能令你感到興奮，那就找下一個吧。
[1]WATFIV Waterloo FORTRAN IV WIKI
[2]Jolt可樂 一種程式設計師很愛喝的咖啡飲料 WIKI
[3]SOH-CAH-TOA 西方背誦三角函式的口訣：
Sine(正弦)＝Opposite(對邊)/Hypotenuse(斜邊)
Cosine(餘弦)＝Adjacent(鄰邊)/Hypotenuse(斜邊)
Tangent(正切)＝Opposite(對邊)/Adjacent(鄰邊)
[4]炸豆丸子 中東一帶的料理，也譯作中東蔬菜球、油炸鷹嘴豆餅、沙拉三明治 WIKI
[5]back of the envelope 信封背面打草稿，引申為不正式、不精確，此處譯為模糊的
想知道更多東西嗎？你正在閱讀Joel on Software，這裡年復一年地釋出一些關於軟體開發、軟體團隊管理、使用者介面設計、經營成功的軟體公司和有關橡膠鴨子的瘋言瘋語。
關於作者。我是Joel Spolsky，Fog Creek Software的共同創始人之一，這是一家坐落在紐約的能夠給予程式設計師優良待遇的同時仍能保持利潤豐厚的公司。程式設計師擁有獨立辦公室，免費午餐，每週工作40小時。客戶只需要為喜歡的軟體付款。我們創造了Trello，超級輕量級的專案管理平臺；FogBugz，啟發式的缺陷管理軟體，為了幫助優秀的團隊開發卓越的軟體而設計；以及Kiln，讓資源控制更簡易。我也是Stack Exchange的共同創始人之一以及CEO。更多關於我的資訊。