軟體人員面試教戰守則(第三版) The Guerrilla Guide to Interviewing (version 3.0)

無政府主義者、自由之愛(free-love)擁護者還有替香蕉爭取權利的人組成了一個雜牌軍，在墨西哥瓦亞塔港綁架並開走了愛之船，而且威脅如果七天內不答應他們的要求，就會讓616名乘客和327名船員隨船一起沈沒。歹徒的要求？無記號的一百萬美元小鈔，以及一套依 GPL 授權實作的 WATFIV (也就是尊貴的 Waterloo Fortran IV 編譯器)。(自由之愛的人和香蕉權利派一致同意的事這麼少，實在是令人驚訝。)

你身為嘉年華航運公司編程部門的主程式師，必須決定是否能無中生有，在七天內交出一套 Fortran 編譯器。現在你底下有兩個程式員可以幫忙。

你做得到嗎？

你回答：「好的，我想想，這要看狀況...」寫這種文章的好處之一，就是我可以隨意地編造你講的話，你拿我沒辦法。

看什麼狀況？

「嗯，我的團隊會用 UML 產生工具嗎？」

這真的有差嗎？三個程式員，七天，Waterloo Fortran IV。用 UML 工具就能搞定嗎？

「我想是不行的。」

好，那麼又要看什麼狀況嗎？

「我們會有19吋的螢幕用嗎？所有人都有喝不完的 Jolt 可樂(譯：咖啡因超高的飲料，是美國程式師最愛)嗎？」

又來了，這有差嗎？你做不做得到要靠咖啡因來決定嗎？

「我想也是。噢，等一下。你說我有兩個程式員？」

沒錯。

「他們是誰？」

有差嗎？

「當然有差！如果團隊無法和睦相處，我們就永遠不能一起工作。而我知道有幾個超級程式員，他們自己就能在一週內做出一個Fortran編譯器，我也知道很多的程式員，給他們六個月也寫不出列印啟動標題的程式。」

現在我們有點搞頭了！

人是軟體專案中最重要的部份，這種話每個人都在講，可是沒有人能真正確定要做些什麼。如果你想要擁有好的程式員，第一要務就是要「請」到對的程式員，也就是說你必須能辨別出誰是對的程式員，而這通常都是在面試過程中完成的，所以本章全都在談面談。

(面對面的面談只是雇用過程中的一環，整個過程始於履歷篩選和電話篩選。這篇文章只涵蓋面對面的面談。)

每個被雇用的人選都應該至少和六個人面談，六個人裡至少要有五位會和應徵者共事的人(也就是其他程式員而非經理)。你知道那種只靠幾位老鳥(salty)經理和應徵者面談，一試定生死的那種公司嗎？這些公司裡頭不會有非常優秀的工作人員。要瞞過一場面試實在太容易了，特別是由非程式員面試程式員時更是如此。

如果六次面談中有兩人認為對方不值得用，就不要錄取。這表示當你不打算錄用某位應徵者時，在兩次面談後就可以技術性地結束「整天」的面試，這並不算是壞事。不過為了避免流於殘酷，最好不要事先告訴對方要面談的次數。我還聽過有些公司允許任何一個面試官把人選刷掉。我覺得這有點太過頭了；對我來說，或許可以容許讓資深人員刷掉應徵者，不過不會只因某個新進人員不喜歡而否決。

不要嘗試同時和一大群人面談。這樣做並不公平。每場面談都應該只有一位面試官和面試者，並在一間有白板而且有門可關的房間內進行。我基於豐富的經驗可以告訴你，如果一場面試花不到一小時，是無法做出決定的。

你在面談時會看到三種人。在天平的一端是無知的大眾，他們連這份工作最基本的技能都沒有。這種人很容易辨別剔除，通常問兩三個簡單的問題就解決了。天平的另一端是光采奪目的超級明星，他們只是因為好玩，就在任天堂DS遊樂器上運用組合語言，在一個週末裡寫出lisp編譯器。而在兩者中間，有大量似乎可以有某些貢獻的可能人士(maybes)。其中的竅門就是找出超級明星和可能人士之間的差異，因為秘訣就在於你並不想雇用任何一位。絕對不會。

在面談結束時，你必須準備好對該人選作出明確的決定。這個決定只能有兩種可能結果：錄用或是不錄用。沒有其他的答案。絕對不要說：「錄用，但我的團隊不要。」這是很粗魯無禮的，暗示對方不夠聰明沒資格和你共事，不過對其他團隊的笨蛋來說可能夠聰明了。如果你發現自己很想說「錄用，但我的團隊不要。」，請直接把這句話翻譯成「不錄用」那就萬事OK了。即使某個人選就你特定的工作很適合，但不太適合另一個團體，這也是「不錄用」。軟體產業的變化太頻繁又太快，所以你需要那種任何編程工作都可以勝任的人。如果基於某種原因，你發現一個非常非常擅長SQL，但是完全無法學習其他主題的白痴學究，不錄用。否則就會就是拿長痛去換短痛。

絕對不要說「或許吧，我不確定。」如果你不確定，就表示不錄用。這其實比你想像中容易。不確定嗎？就直接說不吧！如果你不置可否，就表示「不錄用」。絕對不要說「嗯，我想應該是錄用吧，不過我對某些地方有點在意...」那也等於是「不錄用」。把所有胡扯都機械式地當作「不要」，那就沒問題了。

為什麼我那麼堅持這一點呢？因為錯失好人選比錄用不適合的人要好太多了。不對的人會耗用很多錢和精力，還會讓其他人浪費時間去修正所有的問題。錄用錯人要開除得花上好幾個，而且會非常的困難(當他們決定對簿公堂時更是格外麻煩)。在某些情況下也有可能完全無法開除任何人。不好的員工會破壞好員工的士氣。而且他們可能是個爛程式員，同時卻又是個真正的好人或是極度需要這個工作，所以你根本不忍心開除他們，不然就是一開除就會犯眾怒，或是其他種種的窘境。反正很慘就是了。

反過來說，如果你否決了一個好人選，我是指我認為有些地方不太公平，不過如果他們真的這麼聰明就不用擔心，他們有很多好的工作機會可以挑。別害怕會因為拒絕太多人而找不到人用。這在面談過程中並不是你的問題。當然找到好的人選非常重要。不過當你實際面試某人時，要假裝門外還有900個人排隊等著和你面試。不管優秀人選似乎有多麼難找，也不要降低你的標準。

好了，我還沒有告訴你最重要的部份：如何知道是否要錄用某人？

原則上很簡單。你要找的人必須

1. 聰明，而且
2. 能把事做完。

就這麼簡單。你要的就是這兩句話。背起來。每天睡前複誦一遍。簡短面談的時間很短，不足以發現其他資訊，所以別浪費時間去嘗試瞭解，應徵者滯留在機場時能否保持心情愉快，或者他們是真懂ATL與COM程式設計還是假裝的。

聰明但不能把事做完的人通常擁有博士學位，而且在大公司裡工作，不過由於他們完全脫離現實，所以公司裡沒人會理他們。對他們來說，與其準時完成工作，還不要去反覆思索某個問題的學術性。這種人不難辨別，由於他們喜歡指出兩個天南地北的概念之間在純理論上的相似點。舉例來說，他們會說「試算表實際上只是程式語言的一個特例。」然後他們會把工作放下，花一星期去寫一篇驚世駭俗的白皮書，討論試算表作為程式語言時的理論計算語言特性。聰明，不過沒什麼用。辨別這種人有另一個方法，他們常常會在你要趕出beta版的那一天，手裡端著杯咖啡出現在你的辦公室，想要開始一場有關Java introspection與COM type library間優劣的長篇對話。

會把事做完但不聰明的人會像沒想過一樣做出蠢事，於是事後別人就得替他們擦屁股。這使得他們成為公司的淨負債，因為他們不但沒有貢獻，還吃掉了其他好員工的時間。他們會前一晚才剛讀到Visitor pattern，而且完全誤解其意義，卻決定要用它來重整你的核心演算法，結果本來用來累加陣列內容的簡單迴圈，被改成一個Addervistior類別(沒錯，還會拼錯字)和一個VisitationArrangingOffice singleton，而你的程式也不會動了。

你要如何在面談中察覺聰明這回事呢？頭一個徵兆就是你不必再三地說明事情。對話會很流暢地進行。應徵者經常會說出某些很有見地有思想或是心思敏銳的話。所以面談的重點之一就在於建立情境，讓某人能向你展示他有多麼聰明。愛吹牛的人是最差勁的面試官。這種人在面談時都在胡扯，應徵者只來得及說「是的，這實在是對極了，我衷心的同意你的看法。」吹牛專家什麼人都會錄用；他們認為應徵者一定很聰明，因為「他的想法和我很像！」

益智問答型的面試官是第二糟的。這種人認為聰明表示「知道很多事實」。他們只會問一堆瑣碎的編程問題，答對就加分。純粹好玩提一下世界上最爛的面試問題：「Oracle 8i裡的varchar和varchar2有何差別？」這是個爛問題。會知道這種芝麻小事的人和你真正想用的人完全不會有任何關聯。誰會在乎有什麼差別？你只要約15秒就可以在線上找到答案！記住，聰明並不等於「知道瑣碎問題的答案」。總而言之，軟體團隊是要雇用有才華而非會某種特定技能的人。畢竟所有能用在工作上的特定技能，就技術而言都會在數年內過時，所以最好雇用能學習任何新技術的人，而不是此刻剛好知道如何讓JDBG和MySQL資料庫溝通的傢伙。

不過大體來說，要深入瞭解一個人的方法就是讓他說話，要提出開放性的問題與難題。

那麼你要問些什麼呢？

我個人的面試問題庫源於我前一家公司微軟。事實上著名的微軟面試問題有好幾百個。每個人都有他們最喜歡的問題集。你也會發展出自己的問題集以及個人的面談風格，幫助你作出錄用/不錄用的決定。下面列出一些我曾經成功用過的技巧。

在面談之前，我會細看應徵者的履歷，並在紙片上簡略寫一份面談計畫。其實只是一串我想要問的問題。下面是面試程式員時典型的計畫。

1. 開場白
2. 有關應徵者最近所從事專案的問題
3. 簡單的編程問題
4. 指標/遞迴問題
5. 你滿意嗎？
6. 你有其他問題嗎？

我會非常小心避免讓自己對應徵者有先入為主的觀念。如果你在面試前，只因為某人是MIT的博士就認為他很聰明，那麼不管他接下來一小時說了什麼，都改變不了你一開始的偏見。如果你因為人們讀社區大學，就覺得他們一定頭腦簡單，不管他們說什麼也無法克服一開始的印象。面談就像是台非常非常精密的天平：很難基於一小時的面談評斷某人，而且可能似乎左右為難(like a very close call)。不過如果你事先多知道應徵者的一點點小事，就相當於在天平一邊加了一個大砝碼，而面談也就白做了。曾經有一次，招募人員在面談前來我的辦公室。她說：「你會愛上這個傢伙的。」這種事真是讓我生氣。我當時應該要說：「嗯，如果你這麼確信我會愛上他，你何不直接錄取，這樣也不用浪費我的時間去面談了。」不過當時年輕又天真的我還是去了。當他說了些不怎麼聰明的東西時，我腦袋裡就想著：「哎呀，這一定是失誤。」我戴著美化一切的眼鏡去看他所說的一切。雖然他是個糟糕的人選，我最後卻說了錄取。知道後來發生什麼事嗎？其他面試官通通都說不錄用。所以囉：別聽招募人員的；在面談前不要去探聽應徵者；而且在你們都獨立下決定之前，絕對不要和其他面試官談論應徵者。這就是科學方法。

面談的開場白階段目的在於讓應徵者放鬆。我會問他們在飛機上好不好。再用約30秒介紹我是誰以及面試會如何進行。我總是會對應徵者再三保證，我們只在意他們解問題的過程，實質的答案並不重要。

第二部份是有關應徵者最近所從事專案的問題。面試大學生時就問他的學位論文(如果有的話)，不然就問他們曾修過，而且真正投入做過大規模作業的課程。舉例來說，我有時候會問：「你上學期修過的課裡最喜歡那一門？什麼課都可以，不一定要跟電腦有關。」而在面試有工作經驗的應徵者時，可以談談他們前一個工作中最後做的事。

同樣要問開放性的問題，然後靜靜地聆聽，偶而在他們要停下來時來一句「關於這件事多告訴我一些」就可以了。

在問開放性問題時要找些什麼呢？

首先是尋找熱情。聰明人熱愛他們所做的專案，在談到的時候會變得非常興奮。他們說起話來會變快而且生氣勃勃。負面的強烈情緒也是個好徵兆：「我前一個老闆只會用VAX電腦，所以什麼事都想在上面做。真是笨蛋！」有太多的人就只是在做事，其實並不在意事情會怎樣。像這種人就很難會對什麼事有興趣。

不好的人選根本不在意，在面談時也完全不會爆發熱情。應徵者是否對某些事有熱情，可以注意某個確實的徵兆。當他們談到那件事時，會暫時忘記自己正在面試。有時候應徵者開始時會因為面試而很緊張，這當然是正常的，而我通常也都會忽略不去在意。不過稍後當他談到單色計算藝術(Computational Monochromatic Art)時會變得異常興奮，而且一點都不緊張了。很好，我喜歡會真正在意事情的熱情人。(什麼是單色計算藝術？拔掉你的電腦顯示器的電源就可以看到了。)你可以質疑某些事(試試看。先等他們談到某些可能為真的事，然後你就說「這不會是真的」)，即使他們五分鐘前還在冒汗，還是會挺身辯解。因為他們非常在意，所以忘記你不久之後即將主宰他們的命運。

其次是好的人選會仔細地從各個層次把事情解釋清楚。我曾經因為應徵者在談論之前專案時，無法用普通人能明白的方式說明而否決他們。主修電腦科學的人常會直接假設，每個人都知道Bates Theorem(譯：一種經濟學理論)或O(log n)的意義。如果他們開始這樣，儘快阻止他們，然後說「幫我一個忙，純粹為了練習，請你用我祖母能懂的話來解釋這件事。」這時候很多人依舊會繼續使用術語，於是完全無法讓人瞭解他們。停！基本上你不會想錄用他們的，因為他們不夠聰明，無法理解要如何才能讓別人瞭解他們的想法。

第三點：如果他從事的團隊合作的計畫，找尋他們擔任領導角色的徵兆。某個應徵者可能會說：「我們在做X，可是老闆說要Y而客戶說要Z。」我就會問：「那麼你做了些什麼？」好的答案可能會像「我集合其他團隊成員寫了一份提案...」不好的答案就像是「嗯，我無計可施，這根本就無解。」記住，聰明而且把事做完。而要知道某人是會能把事做完，唯一的方法就是觀察他們過去是否有把事情做完的傾向。事實上你甚至可以直接要他們提供一個例子，說明過去他們曾扮演領導角色並把事情做完(比如克服某些制度慣性)。

不過面談的大部份時間，還是應該用來讓應徵者證明他們能撰寫程式碼。

再度向應徵者保證，你知道不用編輯器是很難寫程式的，而且你不會在意白板被塗得亂七八糟。另外你也瞭解沒有編譯器是很難寫出正確無誤的程式碼，這些在看結果時你都會考慮進去。

我會在一天的第一場面談裡加上一個非常非常容易的編譯問題。我被迫在dotcom熱潮時期開始這樣做，因為當時有很多認為HTML就是寫程式的人跑來面試，我得找方法避免在這些人身上浪費太多時間。這是那種現役程式師都能在一分鐘內解決的問題。舉些例子：

1. 寫個函數找出某個字串是否以大寫字母A-Z開始
2. 寫個函數算出半徑已知的圓面積
3. 將某陣列中所有的值累加起來

這些軟柿子問題似乎太容易了，所以我得承認，當我第一次開始問這些題目時，真的預期所有人都能輕鬆回答。不過卻發現雖然每個人都解出問題，不過解題所花的時間差別很大。

這讓我想起我為什麼不能靠買賣證券來謀生。

Jared是個證券交易員。他總是告訴我他做了什麼有趣的交易。有種東西叫選擇權，還有賣權、買權以及市場陡峭(market steepens)，所以你要加注steepener，這一切就讓人混淆，不過瘋狂的是我知道這些用語的意思，我知道賣權確實的意思(以一定價格賣出某物的權利，而不是責任)。另外如果你擁有賣權而市場上漲，我也能在三分鐘之內想出會發生什麼事。不過我需要整整三分鐘才能想到，而當他告訴我更複雜的故事時(賣權只是其中第一小節，整個故事還有很多其他環節)，我馬上就投降了，因為腦袋已經暈了(「我們來想看看，市場上漲，表示利率下跌，而賣權是賣出某物的權利...」)要等他拿出圖紙開始逐步引導我才會搞懂，我的眼睛呆滯無神，實在很難過。雖然我瞭解每個小環節，但是我理解得不夠快，無法瞭解整體大局。

程式設計的世界也會有相同的狀況。如果對你來說，基本概念沒有簡單到無需思索，你就無法獲得整體的觀念。

耶魯大學的數學教授Serge Lang習慣在微積分第一堂課出一題很簡單的代數問題給學生做，這題目幾乎每個人都會解，不過有些人解的速度和寫字一樣快，而其他人則需要一些時間。Lang教授宣稱，解這個問題的速度和寫字一樣快的學生，都會這堂微積分課拿到A的成績，其他人則拿不到A。解出簡單代數問題的速度可以準確預測微積分的學期成績，預測低效果相當於整學期的作業、小考、期中考加上期末考。

你看，如果不能以每小時一百英里的高速飆過簡單的東西，你永遠都無法得到進階的東西。

不過就像我所說的，好的程式員會站起來在板子上寫出答案，有時還加上一些巧思(哦！符合Unicode規範！棒啊！)，整個過程只花了三十秒，於是我得看看他們是否真的夠好，這時就得拿出重武器：遞迴和指標。

15年面試程式員的經驗讓我深信，最好的程式員都有本事能輕易地同時處理多個抽象層次。以程式設計而言，具體的意思是他們能輕易處理遞迴或使用指標的複雜演算法，前者必須讓你的腦袋同時考慮呼叫堆疊中多個層次，而後者中物件的位址有點像物件本身的抽象表示。

我終於明白瞭解C語言的指標並非技能而是天賦。在第一年電腦科學的課程中，學期開始時總是有大約200個小孩，每個都曾在四歲大時，在自己的PC上用BASIC寫過複雜的冒險遊戲。他們在大學裡學C或Pascal也學得很快樂，而突然間他們就學不會了。他們就是無法再多學會任何東西。九成的學生會退選改修政治學，然後他們會跟朋友說電腦科學課裡好看的異性太少，所以才會轉換主修。基於某些原因，大多數人似乎生來就缺乏能理解指標的天賦。瞭解指標需要一種複雜的雙重間接思考，這是某些人所做不到的，但對好的程式設計來說卻極為重要。很多「腳本語言高手」學寫程式都是把JavaScript程式碼片段拷到自己的網站開始，然後再學習Perl，從來沒有碰過指標，而他們永遠沒有辦法產生你所需的高品質程式碼。

這就是你曾聽說過的這些著名面試問題的根源，比如「反轉一個連結串列」或是「在一個樹狀結構中偵測迴圈」。

雖然我總認為所有優秀程式員都應該能處理遞迴及指標，而這的確也是辨別某人是否好程式員的極佳方法。但事實卻令人悲哀，現在的程式語言幾乎已經完全不需要這種技藝了。在十年前，很少有電腦科學畢業生沒修過遞迴及functional programming，或沒上過用C或Pascal的資料結構，而如今很多原本的名校可能都只用Java了。

如今面試會遇到的程式員中，很多都會認為遞迴、指標甚至資料結構都是呆板的實作細節，它們在很多現在幸福的程式語言中都已被抽象化掉。他們會竊笑著說：「上一次你必須寫排序演算法是什麼時候的事？」

儘管如此，我並不是真的很在意。即使急救我的醫生只需要把電子式電擊器的電極放在我胸口，然後按下大大的紅色按鈕，我還是希望她懂解剖學。同樣的，即使Ruby on Rails真能知道你的想法，讓你只要點三下滑鼠就能建出完整的Web 2.0社群網站，我還是希望程式員能瞭解深入到CPU層次的各種程式設計。

雖然在表面上，面試的形式只是讓應徵者在白板上寫一些程式碼，但我真正的目的在於衍生與程式碼相關的對話。「為什麼你要那麼做呢？」「你的演算法的效率如何？」「你有沒有漏掉什麼？」「你的程式錯在哪裡？」

這意味著我並不真的擔心提出的編程問題太難。只要讓應徵者有些機會開始上路，然後我會很樂意沿路給些小提示，或者說是些小踏腳石吧。比如說我可能會要某人把三角形投影在一個平面上(一個典型的繪圖問題)，我並不在意提示一下三角函數，提醒他們sin, cos, tan等的定義。而當我要他們想辦法加速時，也可能會提示用查表。注意這些我樂於提供的提示，其實都只是瑣碎問題的答案，那種用Google就能找到的東西。

你難免會在他們的函數裡看到錯誤。所以我們就來到我面試計畫的第五問：「你對這段程式滿意嗎？」你可能會直接問：「好，那麼這段程式錯在哪裡？」這是標準的開放性爛問題。每個程式員都會出錯，這是很正常的，只要他們能找出錯誤就可以了。以C的字串函數來說，大多數大學生都會忘記替新字串加上結尾的0字元；另外幾乎寫任何函數時都會有差一(off-by-one)錯誤。他們有時候會忘了加分號；寫的函數不能處理字串長度為零的字串；配置記憶體失敗時會出現記憶體保護錯誤...只有極少的機會能遇到第一次就完全無錯誤的應徵者。萬一遇到這種狀況就更好玩了。當你說「這段程式裡有個錯」時，他們會仔細的審視程式碼，然後你就能看出他們能否不冒犯面試官，圓滑地聲稱那段程式碼沒有問題。

最後詢問應徵者是否有其他問題作為面試的結尾。記住，雖然說你正在面試他們，但是好的人選有很多工作機會可以選擇，所以他們也是在利用這一天判斷是否想替你工作。

有些面試官嘗試以所問的問題是否「有智慧」來判斷應徵者。我個人並不會在意他們問的問題，因於這時我早已有定見。這個作法有個難處，應徵者在一天內必須與五到六個人面斌，對他們來說很難問出五六個不重覆的好問題，所以如果應徵者沒有問題也沒關係。

我總是會在面試結束前留五分鐘，向應徵者推銷這家公司和這個工作。即使你不想錄用對方，這一點還是很重要。如果有幸找到一個非常好的人選，這時候你會儘你所能確保對方願意來與你共事。即使對方並不適合，你還是希望他們能喜歡你的公司，而且帶著正面的印象離開。

啊，我剛想到應該多提供一些爛問題範例。

首先是要避免違法的問題。在美國詢問任何與種族、宗教、性別、原國籍、年齡、兵役義務、退役狀況、性傾向、婚姻狀況或身體殘疾有關的問題都是違法的。如果履歷上寫著曾待在海軍陸戰隊，就算你想閒聊也不能問對方是不是有去伊拉克。針對兵役狀況的差別待遇是違法的。如果履歷上寫著曾在海法讀過 Technion 技術學院也不能問，不管你是想閒聊，還是因為你太太是以色列人，或者只是你愛吃炸豆丸子(Felafel)都一樣不能問。針對原國籍的差別待遇也是違法的。

再來是要避免任何可能讓人覺得你會在意或會因而有差別待遇的問題，那些你其實不在意也不會有歧視的東西。我能想到最好的例子，就是問對方是否有小孩或是否已婚。這可能會讓人有種印象，覺得你認為得有小孩的人無法在工作上投入足夠的時間，或是有可能請產假。基本上只問與面試工作相關的問題就對了。

最後是要避免問腦筋急轉彎，比如要用六根等長的棒子排出四個一樣大小的等邊三角形。也要避免問任何和海盜、彈珠、密碼有關的題目。這種題目大多數都是那種「原來如此！」的問題，知道了就會，不知道答案時怎麼樣都答不出來。答得出這些問題，只是表示之前你曾玩過腦筋急轉彎。應徵者可能只是剛好靈機一動，但你卻無從得知對方是否「聰明又能把事做完」。

過去我曾經用過「不可能的問題」，也就是所謂的「信封背面問題(譯：在信封背面空白處演算，指沒有答案，只能粗略估計的問題)」。典型的例子就像「西雅圖有多少個鋼琴調音師？」應徵者不會知道答案，不過聰明的應徵者不會放棄，而且會勇於嘗試並估計出一個合理的數字。讓我們想想看，西雅圖可能有個...一百萬人嗎？其中假設百分之一擁有鋼琴好了？一台鋼琴幾年要調一次音吧？調一次音應該要35分吧？這些當然全都是錯的，不過至少他們有在攻擊這個問題。問這種問題唯一的目的就是讓你與應徵者對話。「好吧，就算35分鐘好了，不過在各台鋼琴間的交通時間呢？」

「好問題。如果調音師能預先安排好預約時間，就能適當安排時程讓交通時間減到最少。你知道意思，星期一把Redmond地區的鋼琴全部搞定，而不是一天之內在520公路來來回回三趟。

好的信封背面問題能讓你與應徵者對話，幫助你評價對方是否聰明。而不良的「原來如此」海盜問題，通常只會讓應徵者瞪著你一陣子，然後說他們被難倒了。

如果在面試結束時，你深信對方既聰明又能把事做完，而且其他四或五個面試官都同意，那麼錄用對方應該不會有問題。不過如果你有任何疑慮，最好還是再等看看是否有更佳的人選。

決定是否錄取應徵者最佳的時點，是在面試結束後約三分鐘加右。太多太多公司允許面試官在幾天甚至幾週後才交出意見。問題是時間過得愈久，記得的內容就愈少。

我會要求面試官在面試之後，無論「錄用」還是「不錄用」都要馬上交出意見，還要附上一兩段說明。截止時間是面試結束後15分鐘。

如果你無法決定，有個很簡單的方法。不錄用。不能肯定的人就不要錄取。在最初幾次可能會有點膽怯，如果「永遠」找不到好的人怎麼辦？沒問題的。如果你的履歷篩選和電話篩選程序都有作用，面試或許會有兩成的錄取率。而當你發現聰明又能把事做完的人選時，你會知道的。如果你沒有因某人而興奮無比，就再找下一個吧。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.