# 二十、面試游擊指南
錄取合適的人對于Fog Creek軟件公司來說是非常關鍵的。在我們這個領域,有三類人可以 挑選。在一個極端,是哪些混進來的,甚至缺乏最基本的工作技巧.只要問這類人兩三個簡 單的問題,再讀一下他們的簡歷,就可以輕易地剔除他們。另一個極端的類型是才華橫溢 的超級明星這些人僅僅為了好玩就用匯編語言為Palm Pilot (—種手掌計算機)寫了一個 Lisp (—種人工智能編程語言)編譯程序。在這兩種極端類型中間的是一大群不能確定水平 的候選者,也許他們中的某些人能干些什么?這里的關鍵是明白超級明星和那一大堆屬于中 間類型的人的區別,因為Fog Creek軟件公司只錄取超級明星。下面我要介紹一些找出超級 明星的技巧。
Fog Creek公司最重要的錄取標準是:
有頭腦,并且能完成工作(Smart, and Gets Things Done.)
就是這些了。符合這樣標準的人就是我們公司需要的員工了。記住這條標準。每天上床前 背誦這條標準。我們公司的目標之一就是錄取擁有這樣的潛質的人,而不是錄取懂某些技術 的人。任何人所擁有的某些具體技術都會在幾年內過時,所以,錄取有能力學習新技術的人, 要比錄取那些只在這一分鐘知道SQL編程是怎么回事的人對公司更劃算一點。
有頭腦確實是一個很難定義的質量。但是讓我們看一些在面試時能提問的一些問題,通過這 些提問,我們可以找出擁有這種質量的人。完成工作非常關鍵。看起來有頭腦但是不能完成 工作的人經常擁有博士學位,在大公司工作過,但是在公司中沒有人聽他們的建議,因為他 們是完全脫離實際的。比起準時完成交代事項,他們更寧愿對于一些學院派的東西沈思。這 些人由以下特性而可以識別出來。他們總是愛指出兩個根本不同的概念間的相似性。例如, 他們會說“Spreadsheets是一種特殊的編程語言〃 ,然后花一個禮拜寫一篇動人的,智 慧的白皮書。這篇白皮書論述了,作為一個編程語言,Spreadsheet關于計算語言特性的種 種功能。聰明,但是沒用。
現在,我們來談談完成工作但是沒有頭腦的人。他們愛做蠢事。從來也沒有考慮過將來得靠 他們自己或者別的什么人來亡羊補牢。通過制造新的工作,他們成為了公司的負債而不是資 產。因為他們不僅沒有為公司貢獻價值,還浪費了好員工的時間。這些人通常到處粘貼大堆 的程序代碼,而不愿意寫子程序。他們是完成了工作,但是不是以最聰明的方式完成工作。
面試時最重要的法則是:
做決定(Make A Decision)
在面試結束時,對于被面試者,你不得不做一個直截了當的決定。這個決定只有兩個結果: 錄取或者不錄取.回到你的計算機前,立刻用電子郵件通知招聘負責人你的決定。電子郵件 的主題應該是錄取或者不錄取。接著你需要在正文中寫兩段來支持你的決定.
沒有其他的答案。永遠不要說,“?錄取你,但是不能在我的團隊中”。這是非常草率粗 魯的決定,因為你在暗示應試者沒有聰明到能有和你一起工作的資格,但是以他的頭腦適合 進入那些天生輸家隊伍。如果你發覺自己被誘惑,想說出那句“錄取你,但是不能在我 的隊伍中〃 ,那么就簡單的把這句話變成“不錄取再說出口。這樣就沒事了。甚至
如果某個人在特定領域很能干,但是在別的隊伍中將會表現不好,也是不錄取。事物變化 的如此之快,我們需要的是在任何地方都能成功的人。如果某些情況下你發現了一個白癡專 家(擁有某些特殊能力的白癡),這個專家對于SQL非常,非常,非常的精通,但是除此之 外什么也學不會,不錄取。在Fog Creek公司沒有他們的將來。
永遠不要說,“也許,我不確定〃 。如果你不確定,意味著不錄取。看,比你想象的容 易的多。不確定?就說不!同樣,如果你不能作出決定,那意味著不錄取。不要說,〃 嗯, 錄取,我想是這樣的。但是關于…,我想知道…”。這種情況就是不錄取。
最重要的是記住這點,放棄一個可能的好人選要比招進一個壞人選還要來的好。一個不合格 的求職者如果進入了公司,將要消耗公司大量的金錢和精力。其他優秀員工的還要浪費時間 來修復這個人的錯誤。如果現在你還在猶豫,不錄取。
如果你是Fog Creek公司的面試官,當你拒絕了大量的應聘者時,不要為Fog Creek公司將因 此雇不到任何人了而憂慮。這不是你的問題。這是招聘負責人的問題。這是人力資源部的問 題。這是Joel (譯者注:Fog Creek公司的老板,本文作者)的問題。但不是你的問題。不 停地問自己,哪種情況更糟糕? 一種情況是我們變成了一個龐大的,糟糕的軟件公司,充斥 著許多腦袋空空如可可果殼(譯按:火山豆,Macadamia Nuts,大洋洲特產。)的家伙,另一 種情況是我們是一個小而高質量的公司。當然,找到優秀的應征者(并聘用他們)是很重要 的。找到有頭腦而且完成工作的人是公司中的每個員工的日常工作之一。但是當你作為Joel Creek公司的一員真的開始面試一個應聘者時,要裝作現在正有很多優秀的人想打破頭擠進 Fog Creek公司。總之,無論找到一個不錯的應聘者是多么的難,永遠不要降低你的標準。
但是你如何作出錄取或者不錄取這樣艱難的決定?你只要在面試過程中不停地問自己:這個 人有頭腦嗎?這個人能完成工作嗎?要作出正確的回答,在面試時你必須問對問題。
開個玩笑,下面我要問個有史以來最差的面試問題:“Oracle 8i中的數據類型varchar和 varchar2有什么區別?〃 這是一個可怕的問題。掌握這種瑣碎的技術細節和Fog Creek公司 想錄取你之間沒有任何聯系。誰會去記這種東西?如果有網絡收尋引擎的幫助,你可以在15 秒內找到答案。
實際上,還有更差的問題,等會兒我會談到的。
現在我們要談到有趣的部分了:面試時提哪些問題。我的面試問題題庫清單來自于我去微軟 公司找第一份工作的經歷。這里實際上有幾百個微軟面試問題。每個人都有偏愛的問題。你 也可以發展一套自己的面試問題以及面試的個人風格,這樣你就可以比較容易地作出錄取/ 不錄取的決定。以下是我成功使用過的一些面試技巧, 在面試前,我讀一遍應試者的簡歷,然后在一張紙片上隨便寫以下我的面試計劃。這個計劃 實際上就是我要問的問題清單。以下是一個例子(用來面試程序設計師的):
1. 自我介紹
2. 應試者參加過的項目
3. 無法回答的問題
4. C語言函數
5. 你滿意嗎?
6. 設計問題
7. 挑戰
8. 你還有什么問題?
在面試前,我非常,非常當心,避免自己先入為主。如果在面試前你就己經想當然地認為, 一個麻薯工的博士一定是一個有頭腦的人。那么在接下來的一小時的面試時間內,無論 那個麻薯工的博士說什么都不能改變你的最初印像。如果在面試前你就認為這個應試者是 個傻瓜,那么他面試時說什么也無濟于事。面試就像一個非常精巧的天平。一小時的面試 結束后就要對一個人下結論是不容易的(但是你又必須在面試結束后得出結論)。一些不起 眼的細節可能會影響最后的結論。如果你在面試開始前對于應試者有了一點了解的話,就 好比天平的某一端加上了重重的砝碼。這樣面試本身就會變得沒有用處了。以前有一次在面 試前,一個招聘負責人跑進我的房間說,“你肯定會愛上這個家伙的!”對一個男孩?天 哪,這簡直讓我發瘋。我本來應該說,“嗯,如果你這么確定我會喜歡他,為什么你不干 脆錄取他,何必讓我浪費時間來面試?〃 但是那時我還太年輕幼稚,所以還是面試了那個 人。當這個家伙開始說一些蠢話時,我對自己說,“哇塞,這應該是個例外情況,也許是 大智若愚。〃 我開始帶著有色眼光看他了。于是我以說“錄取〃 結束了面試,雖然他 是一個糟糕的面試者。接下來發生了什么事?除了我,其他的面試官都說,不要錄取這個人。 教訓是,不要聽別的人的話,在面試應試者前不要四處打探這個面試者的情況。最重要的是 不要和別的面考官談論應試者,除非你們都己經作出了獨立的判斷。這才是科學的做法。
作為面試步驟的第一步,介紹的目的是讓應試者放輕松。我通常花30秒鐘,講一下我是誰, 接下來面試會如何進行。我總是使得應試者確信,我們關心的是他(她)如何解決問題的,
而不是他(她)的最終答案是對還是錯。順便說一下,面試時,你不要和應試者隔著一個桌 子坐著,否則在你和面試者之間就有了一個障礙,并且暗示著一種比較正式嚴肅的氣氛, 這樣應試者就很難放松了。更好的辦法是把桌子背對著墻壁,或者和應試者坐在桌子的同一 邊,這樣有助于應試者放松。只有應試者不會因為緊張而表現失常,你才能更有效的進行 面試.
第二步的內容就是問應試者最近做了些什么專案。對剛畢業的學生,如果有論文就問問論文, 沒有的話,就問問他們做過什么很喜歡的大作業.例如,有時候我會問一下,“ 你最喜歡 上學期哪門課程?不一定要和計算機相關的。事實上,如果應試者回答的課程和計算機 沒有關系,我會比較高興。有時候你會發現這個計算機系應屆生選擇了盡可能少的計算機 相關課程,但是卻選修了很多和音樂相關的課程。但是他(她)卻說最喜歡的課程是《面向 對象數據庫》。哼哼,不錯啊.不過如果你直接承認你喜歡音樂勝于計算機,而不是在這兒 胡說八道的話,我會更高興一點。
當面試有工作經驗的人時,你可以讓他們談一下前一份工作。
我問這個問題的目的是在尋找一樣質量:熱情。在應試者談到他(她)最近做過的項目時, 你觀察到以下跡像都是不錯的:
* 談到他們做過的項目時變得熱情洋溢;他們的語速更快,語言更生動活潑。這說明 他們對某些東西有興趣,有熱情(因為現實中有許多人對所做的項目根本漠不關心 呢)。即使他們激動地表達對做過的項目的負面感情,這也是一個好的信號。“我 曾經為上一個老板安裝Foo Bar Mark II,但他是個傻瓜! ”表現出熱情的人就是我 們要錄取的人。差的應試者對工作根本就不關心,所以根本不會激動。一個非常好 的信號是當應試者很激動地談論上一份工作,以至于暫時忘記了他們正在被面試。 有時候應試者剛開始面試時表現的很緊張–這是很正常的現象,所以我通常忽略 不計。但是當他們談到單色計算藝術(Computational Monochromatic Art)時,這 個家伙變得極端興奮,一點都不緊張了。不錯,我喜歡這樣的應試者,因為他們關 心他們做的事。(什么是單色計算藝術?拔掉你的計算機顯示器的電源就可以看到 了)
* 能認真地去解釋事情。某些人被我拒掉的原因就是他們不會用普通人能明白的語言 去解釋他們做過的項目。很多工科專業的人總是以為所有人都知道Bates理論(譯者 注:Bates Theorem,一種經濟學的理論)或者Peano公理組(譯者注:Peano’s Axioms, 數論中的一些定理)是什么。如果應試者開始滿口行話了,讓他們停一停,然后你 說,“能幫我個忙嗎?就是為了再練習一下,你能把剛才說的用我老祖母也能理解 的話說一遍嗎?”但即便如此,有些人還是繼續用那些術語,而且根本沒法讓人明 白他們在說什么。天哪!
* 如果這個項目是一個團隊項目,看看他們是否在有承擔領導責任的跡象? 一個應試 者可能會說:“我們用的是X方法,但是老板說應該是Y,而客戶說應該是Z。”我會 問,“那么你怎么做的? ”一個好的回答可能是“我設法和團隊中別的人開了個會, 然后一起搞出個辦法…”壞的回答看起來像,“嗯,我什么也不能做。這樣的問題 我解決不了。”記住,聰明并且能完成工作。要搞清楚某人是否能完成工作的一個 辦法就是看看他(她)過去是否傾向于完成任務。事實上,你可以主動要求他們給 你個例子證明他們能擔任領導作用,完成任務。一例如克服公司的陳規陋習。
現在我們談談清單上的第三款,無法回答的問題。這很有趣。這個主意的關鍵在于問一些不 可能有答案的問題,就是想看一下應試者怎么辦。“西雅圖有多少眼科醫生?〃 ”華 盛頓紀念碑有多重? ”“洛杉機有多少加油站?〃 “紐約有多少鋼琴調音 師? “
* 聰明的應試者猜到你不是要測驗他們的專業知識,他們會積極地給出一個估計。“嗯, 洛杉機的人口是七百萬;每個人平均擁有2.5輛轎車…”當然如果他們的估計完全 錯誤了也沒有關系。重要的是他們能積極地試著回答問題。他們可能會試著搞清楚 每個加油站的儲量。“嗯,需要四分鐘給一個儲油罐加滿油,一個加油站有十個油 泵每天運行十八個小時…”他們也可能試著從占地面積來估計。有時,他們的想法 的創造力讓你吃驚.而有時,他們直接要一個LA的黃頁去查。這都是好跡像。
* 不聰明的應試者則被難住了。他們目瞪口呆地望著你,好像你來自火星。你不得不 提示嗯,如果你想建立一個像洛杉機那么大的城市,你需要建立多少個加油站?〃 你還可以提示他們:“加滿一個儲油罐要多長時間?”不過,這些榆木疙瘩腦袋還 是只會坐在那里發呆,你得拖著他們往前走才行。這類人不會解決問題,我們可不 要這樣的人。
關于編程問題,我通常要求應試者用C語言寫一些小函數。以下是我通常會出的題目:
1. 將一個字符串逆序
2. 將一個鏈表(linked list)逆序
3. 計算一個字節(byte)里有多少bit被設成on
4. 搜索給定的字節(byte)
5. 在一個字符串中找到可能的最長的子字符串,該字符串是由同一字符組成的
6. 字符串轉換成整數
7. 整數轉換成字符串(這個問題很不錯,因為應試者要用到堆棧或者strev函數)
注意,通常你不會希望他們寫的程序代碼多于5行,因為你沒有時間理解太長的程序代碼。 現在我們來詳細看一看其中幾個問題:第一個問題:逆序一個字符串。我這輩子還沒有見過 那個面試者能把這題目一次做對。所有的應試者都試圖動態生成緩沖區,然后將逆序的字符 串輸出到該緩沖區中。問題的關鍵在于,誰負責分配這個緩沖區?誰又負責釋放那個緩沖區? 通過這個問題,我發現了一個有趣的事實,就是大多數認為自己懂C的人實際上不理解指針 和內存的概念。他們就是不明白。這真叫人吃驚,無法想象這種人也能做程序設計師。但他 們真的就是!這個問題可以從多個角度判斷應試者:
* 他們的函數運行快嗎?看一下他們多少此調用了 strlen函數。我曾經看到應試者寫 的strrev的算法竟然只有O(nA2)的效率,而標準的算法效率應該是O(n),效率如此 底下的原因是因為他們在循環中一次又一次調用strlen函數。
* 他們使用指標運算嗎(譯者按:原文為pointer arithmetic,指的是加減指針變量 的值)?使用指標運算是個好現象。許多所謂的“C程序設計師”竟然不知道如何使 用指標運算(pointer arithmetic)。當然,我在前文說過我不會因為應試者不掌 握一種特定的技巧而拒絕他。但是,理解C語言中的指針不是一種技巧,而是一種與 生俱來的傾向。每年一所大學要招進200多個計算機系的新生,所有這些小孩子4歲 就開始用BASIC語言在Atari 800s寫冒險游戲了。在大學里他們還學Pascal語言,學 得也很棒。直到有一天他們的教授講了指標的概念,突然,他們開始搞不懂了。他 們就是不能再理解C語言中的任何東西了。于是90%的計算機系學生轉系去學政治學。 為了挽回面子,他們告訴朋友,他們之所以轉系是因為他們計算機系英俊貌美的異 性太少。許多人注定腦子里就沒有理解指標的那根弦。所以說理解指標是一種與生 俱來的質量,而不是一種單純的技巧。理解指標需要腦子轉好幾個彎,某些人天生 不擅長轉這幾個彎。
第三個問題可以考考面試者對C的位運算的掌握,但這是一種技巧,不是一種質量,所以你 可以幫助他們。有趣的等他們建立了一個子函數用來計算byte中為1的位的數目,然后你要 求他們優化這個子函數,盡量加快這個函數的運行速度。聰明的應試者會使用查表算法(畢 竟這個表只有256個元素,用不了多少內存),整個表只需要建立一次。跟聰明的應試者討 論一下提高時間/空間效率的不同策略是十分有意思的事情.進一步告訴他們你不想在程 序啟動時初始化查詢表。聰明的面試者可能會建議使用緩沖機制,對于一個特定的byte,只 有在第一次被查詢時進行計算,然后計算結果會被放入查詢表。這樣以后再被查詢時直接查 表就行了。而特別特別聰明的面試這會嘗試有沒有建立查詢表的快捷方式,如一個byte和它 的置1的bit數之間有沒有規律可循?
當你觀察應試者寫C程序代碼時,以下一些技巧會對你有幫助:
* 事先向應試者說明,你完全理解,沒有一個好的編輯器光在紙上寫程序代碼是困難 的,所以你不在乎他們手寫的程序代碼是否看上去不整潔。你也完全明白沒有好的 編譯程序和調試器,很難第一次就寫出完全沒有bug的程序,所以請他們不必為此擔心。
* 好程序設計師的標志:好程序設計師寫完符號后,通常立刻跟上”}〃符號, 然后再在當中填上程序代碼。他們也傾向于使用命名規則,雖然這個規則可能很原 始。如果一個變量用作循環語句的索引,好程序設計師通常使用盡可能少的字符為 它命名。如果他們的循環語句的索引變量的名字是CurrentPagePositionLoopCounter,顯而易見他們寫程序代碼的經驗還不夠多。偶 爾,你會看到一個C程序設計師寫下像if (0==strlen(x))—樣的程序代碼,常量被 放在==的左邊。這是非常好的現象。這說明他因為總是把=和==搞混,己經強迫自己養成這種習慣以避免犯錯。
* 好的程序設計師在寫程序代碼前會訂一個計劃,特別是當他們的程序代碼用到了指 標時。例如,如果你要求逆序一個鏈表,好程序設計師通常會在紙的一邊畫上鏈表 的草圖,并表明算法中的索引指針當前移動到的位置。他們不得不這樣做。正常人 是不可能不借助草圖就開始寫一個逆序鏈表的程序的。差的程序設計師立刻開始寫 程序代碼。
不可避免的,你會在他們的程序中發現bug,于是我們現在來到了第五個問題:你對程序代 碼滿意嗎?你可能想問,“好吧,bug在哪里?〃 這是來自地獄的一針見血的問題,要 回答這個問題可要大費口舌。所有的程序設計師都會犯錯誤,這不是問題。但他們必須能找 到錯誤。對于字符串操作的函數,他們通常會忘記在輸出緩沖區加上字符串結束符。所有的 函數,他們都會犯off-by-one錯誤(譯者按:指的是某個變量的最大值和最小值可能會和正 常值差1)。他們會忘掉正常的C語句結尾的分號。如果輸入是零長度字符串,他們的函數會 運行錯誤。如果malloc調用失敗而他們沒有為此寫好錯誤處理程序代碼,應用程序會崩潰。 一次就能把所有事情做對的程序設計師非常,非常,非常地少.不過要是真的碰上一個的話, 提問就更有意思了.你說,”還有Bug”。他們會再仔細地檢查一遍程序代碼。這個時候,觀察 一下他們內心是否開始動搖了,只是表面上勉強堅持說程序代碼沒有問題。總之,在程序設 計師寫完程序代碼后,問一下他們是否對程序代碼滿意是個好主意。就像Regis那樣問他們! (譯者按,Regis Phi lbin是美國ABC電視網的游戲電視節目主持人,他的口頭禪是“ 這是 你的最后的答案嗎? ” )
第六部分:關于設計的問題。讓應試者設計某樣東西。Jabe Blumenthal,Excel的原始設計 者,喜歡讓應試者設計房子。Jabe說,曾經有一個應試者跑到白板前,畫了一個方塊,這就 是他的全部設計。天哪,一個方塊!立刻拒絕這樣的家伙。你喜歡問什么樣的設計問題?
* 好的程序設計師會問更多的信息。房子為誰造的?我們公司的政策是,我們不會錄 取那些在設計前不問為誰設計的人。通常,我會很煩惱我得打斷他們的設計,說“事 實上,你忘記問這個房子是給誰設計的了。這個房子是給一群長頸鹿造的。〃
* 笨笨的應試者認為設計就像畫畫,你想畫什么就畫什么。聰明的應試者明白設計的 過程是一系列艱難的權衡。一個很棒的設計問題是:設計一個放在街角的垃圾箱。 想一想你得做多少權衡,圾箱必須易于清空,但是很難被偷走;易于放進垃圾, 但是碰到狂風大作,里面的垃圾不會被吹出來;垃圾箱必須堅固而便宜。在某些城 市,垃圾箱必須特別設計,以防恐怖分子在里面藏一個定時炸彈。
* 有創造力的應試者會給出有趣而獨特的設計。我最喜歡的問題之一是為盲人設計一 個放調味品的架子(譯者按:原文為spice rack老外的廚房里有個專門放調味品 的架子,上面放了很多小罐罐,里面裝了各種各樣的調料)通常許多應試者的建議 是把布萊葉文(一種盲人使用的文字)刻在放調料的罐子上,這樣文字會卷起來而 變形。我碰到一個應試者,他的設計是把調料放在抽屜里,因為他覺得水平地感知 布萊葉文比垂直地做更方便。(試試看!)這個答案這樣有創意,使我震驚!我面 試了有一打的程序設計師,從來沒有人想到過類似的答案。這樣有創意的答案確實 躍過了普通人考慮問題的條條框框。僅僅因為這個答案太有創意了,而且應試者別 的方面還過得去,我錄取了這個應試者,他現在己經成為Excel團隊中一個優秀的 項目經理了(譯者按,本文作者曾在微軟工作過)。
* 總是爭取一個確定的了結。這也是完成工作的特質的一部分。有時候應試者會猶猶 豫豫不能作出一個決定,試圖回避困難的問題,留著困難的問題不作決定就直接向下進行,這很不好。好的應試者有一種推動事情自然地前進的傾向,即使你有意把他們 拖回來。如果關于某個話題的討論開始原地打轉變得沒有意義了,好的應試者會說, “嗯,我們可以整天談論這個,但是我們得做點什么。為什么我們不開始…”
于是我們來到了第七部分,挑戰。這部分很好玩。在面試中留心一下,當面試者的回答絕對 的百分之百毫無爭議時,你可以說:”嗯,等一下等一下.”然后花上兩分鐘玩一下魔鬼的 游戲(譯者按,原文為devil’s advocate,魔鬼代言人指的是違背自己的良知,為錯誤邪惡 的觀點辯護).記住一定要在你可以肯定他正確時和他爭論。
這個很有意思.
* 軟弱的應試者會屈服。那我就和他說拜拜了。
* 堅定的應試者會找到一個辦法說服你。他們會以甘乃迪總統的口才來說服你,“也 許我誤會了你的意思,”他們這樣開頭,但是正文仍是堅定地站穩立場。這樣的人 我就錄取。
不得不承認,面試雙方的地位并不是平等的。有可能應試者由于害怕你的權力而不敢于你爭 辯。但是,好的應試者有足夠的熱情和勇氣堅持正確的觀點,他們由于熱切希望說服你而會 暫時忘記正在被面試。這樣的人就是我們要錄取的人。
最后,可以問一下應試者有什么想問的。一些人喜歡看看應試者這時是否會問一些聰明的問 題。這是市面上流行的面試書籍的標準技巧。我個人不在乎應試者問什么,因為這時我己經 做了決定。麻煩在于,應試者也許己經見了5、6個人,進行了好幾輪面試,他們可能很累了, 以至于不能為每輪面試都準備一個聰明而獨特的問題。所以如果他們沒有可問的,沒關系。
我總是留下面試的最后5分鐘來推銷我的公司。這很重要。即使我不打算錄取眼前這個應試 者。如果你幸運的找到一個很棒的應試者,你當然愿意做任何事情說服他(她)來你的公司。 即使他們不是好的應試者,你也要盡力讓他們為Fog Creek公司激動,這樣面試結束時他們 會對Fog Creek公司留下一個很好的印象。記住,應試者并不僅僅是可能的雇員,他們也是 顧客,也是我們公司的推銷員。如果他們覺得我們的公司很棒,他們也許會推薦朋友來面試。
啊哈,我記得我說過我會給出一些應該避免的非常不好的反面的試題例子。
首先,避免不合法的問題。有關種族,宗教,性別,出生國,年齡,服役記錄,是否老兵, 性傾向,生理障礙的問題都是不合法的。即使他們的簡歷說他們1990年在軍中服役,也不要 問有關問題。也許這會讓他們愉快地談論在海灣戰爭中的經歷。但是你的問題還是不合法的。 如果簡歷上寫著他們上過Technion in Haifa,不要問他們是否是以色列人,即使只是為了 閑談,因為這是違法的.下面有一個很好的不合法的例子點擊這里有很多關于什么是違法 的討論。(但是這個網站的其余問題夠愚蠢的。)
其次,不要在問題中給予應試者暗示,我們公司喜歡或者不喜歡什么樣的員工。我能想到的 一個例子是問應試者是否有小孩或者是否結婚了。應試者也許會想我們不喜歡有家庭拖累的 員工。
最后,不要問那些腦筋急轉彎的題目,例如6根火柴怎么拼出4個三角形。像這樣的靈機一動 的問題是不能看出應試者是否有“有頭腦/完成工作〃 的質量。
面試與其說是科學不如說是藝術。但是只要你記住有頭腦/完成工作這個原則,你就可以應對自如。有機會就問問你的同事他們喜歡的面試問題和答案。這是我們公司員工午飯時熱衷的話題之一。
- 第一部分 位與字節:編程實踐點滴
- 一、語言的選擇
- 二、深入底層
- 三、joel測試:改進代碼的12個步驟
- 四、每一位軟件開發人員必須、絕對要至少具備UNICODE 與字符集知識(沒有任何例外!)
- 五、輕松寫就功能規格說明書 - 第1節:為什么煩心?
- 六、輕松寫就功能規格說明書 - 第2節:什么是規格說明書?
- 七、輕松寫就功能規格說明書 - 第3節:但是……如何?
- 八、輕松寫就功能規格說明書 - 第4節:技巧
- 九、輕松制訂軟件進度表
- 十、每日連編是朋友
- 十一、難伺候的故障修復
- 十二、軟件開發中的5個世界
- 十三、稿紙原型開發
- 十四、不要被太空架構師所嚇倒
- 十五、開火與運動
- 十六、人員技能
- 十七、源于計算機學科的三個錯誤思想
- 十八、二元文化
- 十九、自動獲取用戶故障報表
- 第二部分 開發人員的管理
- 二十、面試游擊指南
- 二十一、重金激勵害多利少
- 二十、二不配備測試人員的五個首要(錯誤)原因
- 二十三、任務換人有害無益
- 二十四、絕不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序設計界的LordPalmerston
- 二十八、評測
- 第三部分 Joel對常態問題的遐想
- 二十九、RickChapman解讀愚昧
- 三十、在這個國家狗是干什么的? 我們有多么天真?
- 三十一、作為哼哈二將,只管去做事
- 三十二、兩個故事
- 三十三、巨無霸麥當勞與天才廚師JamieOliver
- 三十四、沒有什么像IT看起來那么簡單
- 三十五、提防非自主開發綜合癥
- 三十六、策略I:BEN&JERRY公司與AMAZON
- 三十七、策略II:雞與蛋問題
- 三十八、策略III:讓我回去!
- 三十九、策略IV:大件與80/20神話
- 四十、策略V:公開源代碼的經濟因素
- 四十一、墨菲法則肆掠的禮拜
- 四十二、微軟公司是如何敗北API之戰的
- 第四部分 對.NET稍多的評說
- 四十三、微軟精神失常了
- 四十四、我們的.NET對策
- 四十五、請問,我可以使用連接程序嗎