The Joel on Software Translation Project:軟體人員面試教戰守則

From The Joel on Software Translation Project

Jump to: navigation, search

軟體人員面試教戰守則

作者:周思博 (Joel Spolsky)
譯:Frank Huang 黃詔隆
Thursday, March 23, 2000 A part of Joel on Software, http://www.joelonsoftware.com

錄取合適的人對於Fog Creek軟體公司來說是非常關鍵的。在我們這個領域,有三類人可以挑選。在一個極端,是哪些混進來的,甚至缺乏最基本的工作技巧。只要問這類人兩三個簡單的問題,再讀一下他們的簡歷,就可以輕易地剔除他們。另一個極端的類型是才華橫溢的超級明星這些人僅僅為了好玩就用組合語言在Palm Pilot(一種手掌電腦)寫了一個Lisp(一種人工智慧編程語言)編譯器。在這兩種極端類型中間的是一大群不能確定水平的候選者,也許他們中的某些人能幹些什麼?這裏的關鍵是明白超級明星和那一大堆屬於中間類型的人的區別,因為Fog Creek軟體公司只錄取超級明星。下面我要介紹一些找出超級明星的技巧。

Fog Creek公司最重要的錄取標準是:

有頭腦,並且能完成工作 (Smart, and Gets Things Done.)

就是這些了。符合這樣標準的人就是我們公司需要的員工了。 記住這條標準。 每天上床前背誦這條標準。我們公司的目標之一就是錄取擁有這樣的潛質的人,而不是錄取懂某些技術的人。任何人所擁有的某些具體技術都會在幾年內過時,所以,錄取有能力學習新技術的人,要比錄取那些只在這一分鐘知道SQL編程是怎麼回事的人對公司更划算一點。

有頭腦實是一個很難定義的品質。但是讓我們看一些在面試時能提問的一些問題,通過這些提問,我們可以找出擁有這種品質的人。完成工作非常關鍵。看起來有頭腦但是不能完成工作的人經常擁有博士學位,在大公司工作過,但是在公司中沒有人聽他們的建議,因為他們是完全脫離實際的。比起準時完成交代事項,他們更寧願對於一些學院派的東西沈思。這些人由以下特性而可以識別出來。他們總是愛指出兩個根本不同的概念間的相似性。例如,他們會說「試算表是一種特殊的編程語言」,然後花一個禮拜寫一篇動人的,智慧的白皮書。這篇白皮書論述了,作為一個編程語言,試算表關於計算語言特性的種種功能。聰明,但是沒用。

現在,我們來談談完成工作但是沒有頭腦的人。他們愛做蠢事。從來也沒有考慮過將來得靠他們自己或者別的什麼人來亡羊補牢。通過製造新的工作,他們成為了公司的負債而不是資產。因為他們不僅沒有為公司貢獻價值,還浪費了好員工的時間。這些人通常到處粘貼大堆的程式碼,而不願意寫副程式。他們是完成了工作,但是不是以最聰明的方式完成工作。

面試時最重要的法則是:

做決定 (Make A Decision)

在面試結束時,對於被面試者,你不得不做一個直截了當的決定。這個決定只有兩個結果:錄取或者不錄取。回到你的電腦前,立刻用電子郵件通知招聘負責人你的決定。電子郵件的主題應該是錄取或者不錄取。接著你需要在正文中寫兩段來支援你的決定。

沒有其他的答案。永遠不要說,「錄取你,但是不能在我的團隊中」。這是非常草率粗魯的決定,因為你在暗示應試者沒有聰明到能有和你一起工作的資格,但是以他的頭腦適合進入那些天生輸家隊伍。如果你發覺自己被誘惑,想說出那句「錄取你,但是不能在我的隊伍中」,那麼就簡單的把這句話變成「不錄取」再說出口。這樣就沒事了。甚至如果某個人在特定領域很能幹,但是在別的隊伍中將會表現不好,也是不錄取。。事物變化的如此之快,我們需要的是在任何地方都能成功的人。如果某些情況下你發現了一個白癡專家(擁有某些特殊能力的白癡),這個專家對於SQL非常,非常,非常的精通,但是除此之外什麼也學不會,不錄取。在Fog Creek公司沒有他們的將來。

永遠不要說,「也許,我不確定」。如果你不確定,意味著不錄取看,比你想像的容易的多。不確定?就說不!同樣,如果你不能作出決定,那意味著不錄取。不要說,「嗯,錄取,我想是這樣的。但是關於...,我想知道...」。這種情況就是不錄取

最重要的是記住這點,放棄一個可能的好人選要比招進一個壞人選還要來的好。一個不合格的求職者如果進入了公司,將要消耗公司大量的金錢和精力。其他優秀員工的還要浪費時間來修復這個人的錯誤。如果現在你還在猶豫,不錄取

如果你是Fog Creek公司的面試官,別擔心公司會因為你拒絕一堆應聘者,所以僱用不到任何人。這不是你的問題。這是招聘負責人的問題。這是人力資源部的問題。這是我的問題。(譯註:本文作者是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秒鐘,講一下我是誰,接下來面試會如何進行。我總是使得應試者確信,我們關心的是他(她)如何解決問題的,而不是他(她)的最終答案是對還是錯。順便說一下,面試時,你不要和應試者隔著一個桌子坐著,否則在你和面試者之間就有了一個障礙,並且暗示著一種比較正式嚴肅的氣氛,這樣應試者就很難放鬆了。更好的辦法是把桌子背對著牆壁,或者和應試者坐在桌子的同一邊,這樣有助於應試者放鬆。只有應試者不會因為緊張而表現失常,你才能更有效的進行面試。

第二步的內容就是問應試者最近做了些什麼專案。對剛畢業的學生,如果有論文就問問論文,沒有的話,就問問他們做過什麼很喜歡的大作業。例如,有時候我會問一下,「你最喜歡上學期哪門課程?不一定要和電腦相關的。」事實上,如果應試者回答的課程和電腦沒有關係,我會比較高興。有時候你會發現這個電腦系應屆生選擇了盡可能少的電腦相關課程,但是卻選修了很多和音樂相關的課程。但是他(她)卻說最喜歡的課程是《物件導向資料庫》。哼哼,不錯啊。不過如果你直接承認你喜歡音樂勝於電腦,而不是在這兒胡說八道的話,我會更高興一點。

當面試有工作經驗的人時,你可以讓他們談一下前一份工作。

我問這個問題的目的是在尋找一樣品質:熱情。在應試者談到他(她)最近做過的專案時,你觀察到以下跡像都是不錯的:

    1. 談到他們做過的專案時變得熱情洋溢;他們的語速更快,語言更生動活潑。這說明他們對某些東西有興趣,有熱情(因為現實中有許多人對所做的專案根本漠不關心呢)。即使他們激動地表達對做過的專案的負面感情,這也是一個好的信號。「我曾經為上一個老闆安裝Foo Bar Mark II,但他是個傻瓜!」表現出熱情的人就是我們要錄取的人。差的應試者對工作根本就不關心,所以根本不會激動。一個非常好的信號是當應試者很激動地談論上一份工作,以至於暫時忘記了他們正在被面試。有時候應試者剛開始面試時表現的很緊張 -- 這是很正常的現象,所以我通常忽略不計。但是當他們談到單色計算藝術(Computational Monochromatic Art)時,這個傢夥變得極端興奮,一點都不緊張了。不錯,我喜歡這樣的應試者,因為他們關心他們做的事。(什麼是單色計算藝術?拔掉你的電腦顯示器的電源就可以看到了)
    2. 能認真地去解釋事情。某些人被我拒掉的原因就是他們不會用普通人能明白的語言去解釋他們做過的專案。很多工科專業的人總是以為所有人都知道Bates理論(譯注:Bates Theorem,一種經濟學的理論)或者Peano公理組(譯者注:Peano's Axioms,數論中的一些定理)是什麼。如果應試者開始滿口行話了,讓他們停一停,然後你說,「能幫我個忙嗎?就是為了再練習一下,你能把剛才說的用我老祖母也能理解的話說一遍嗎?」但即便如此,有些人還是繼續用那些術語,而且根本沒法讓人明白他們在說什麼。天哪!
    3. 如果這個專案是一個團隊專案,看看他們是否在有承擔領導責任的跡象?一個應試者可能會說:「我們用的是X方法,但是老闆說應該是Y,而客戶說應該是Z。」我會問,「那麼怎麼做的?」一個好的回答可能是「我設法和團隊中別的人開了個會,然後一起搞出個辦法...」壞的回答看起來像,「嗯,我什麼也不能做。這樣的問題我解決不了。」記住,聰明並且能完成工作。要搞清楚某人是否能完成工作的一個辦法就是看看他(她)過去是否傾向於完成任務。事實上,你可以主動要求他們給你個例子證明他們能擔任領導作用,完成任務。例如克服公司的陳規陋習。

現在我們談談清單上的第三款,無法回答的問題。這很有趣。這個主意的關鍵在於問一些不可能有答案的問題,就是想看一下應試者怎麼辦。「西雅圖有多少眼科醫生?」「華盛頓紀念碑有多重?」「洛杉機有多少加油站?」「紐約有多少鋼琴調音師?」。

    1. 聰明的應試者猜到你不是要測驗他們的專業知識,他們會積極地給出一個估計。「嗯,洛杉機的人口是七百萬;每個人平均擁有2.5輛轎車...」當然如果他們的估計完全錯誤了也沒有關係。重要的是他們能積極地試著回答問題。他們可能會試著搞清楚每個加油站的儲量。「嗯,需要四分鐘給一個儲油罐加滿油,一個加油站有十個油泵每天運行十八個小時...」他們也可能試著從占地面積來估計。有時,他們的想法的創造力讓你吃驚。而有時,他們直接要一個LA的黃頁去查。這都是好跡像。
    2. 不聰明的應試者則被難住了。他們目瞪口呆地望著你,好像你來自火星。你不得不提示:「嗯,如果你想建立一個像洛杉機那麼大的城市,你需要建立多少個加油站?」你還可以提示他們:「加滿一個儲油罐要多長時間?」不過,這些榆木疙瘩腦袋還是只會坐在那裏發呆,你得拖著他們往前走才行。這類人不會解決問題,我們可不要這樣的人。

關於編程問題,我通常要求應試者用C語言寫一些小函數。以下是我通常會出的題目:

    1. 將一個字串逆序
    2. 將一個鏈表(linked list)逆序
    3. 計算一個位元組(byte)裏有多少bit被設成on
    4. 二元搜索
    5. 在一個字串中找到可能的最長的子字串,該字串是由同一字元組成的
    6. 字串轉換成整數
    7. 整數轉換成字串 (這個問題很不錯,因為應試者要用到堆疊或者strrev函數)

注意,通常你不會希望他們寫的程式碼多於5行,因為你沒有時間理解太長的程式碼。

現在我們來詳細看一看其中幾個問題:第一個問題:逆序一個字串。我這輩子還沒有見過那個面試者能把這題目一次做對。所有的應試者都試圖動態生成緩衝區,然後將逆序的字串輸出到該緩衝區中。問題的關鍵在於,誰負責分配這個緩衝區?誰又負責釋放那個緩衝區?通過這個問題,我發現了一個有趣的事實,就是大多數認為自己懂C的人實際上不理解指標和記憶體的概念。他們就是不明白。這真叫人吃驚,無法想像這種人也能做程式設計師。但他們真的就是!這個問題可以從多個角度判斷應試者:

    1. 他們的函數運行快嗎?看一下他們多少此調用了strlen函數。我曾經看到應試者寫的strrev的演算法竟然只有O(n^2) 的效率,而標準的演算法效率應該是O(n),效率如此底下的原因是因為他們在迴圈中一次又一次調用strlen函數。
    2. 他們使用指標運算嗎(譯註:原文為pointer arithmetic,指的是加減指標變數的值)?使用指標運算是個好現象許多所謂的「C程式設計師」竟然不知道如何使用指標運算(pointer arithmetic)。當然,我在前文說過我不會因為應試者不掌握一種特定的技巧而拒絕他。但是,理解C語言中的指標不是一種技巧,而是一種與生俱來的傾向。每年一所大學要招進200多個電腦系的新生,所有這些小孩子4歲就開始用BASIC語言在Atari 800s寫冒險遊戲了。在大學裏他們還學Pascal語言,學得也很棒。直到有一天他們的教授講了指標的概念,突然,他們開始搞不懂了。他們就是不能再理解C語言中的任何東西了。於是90%的電腦系學生轉系去學政治學。為了挽回面子,他們告訴朋友,他們之所以轉系是因為他們電腦系英俊貌美的異性太少。許多人注定腦子裏就沒有理解指標的那根弦。所以說理解指標是一種與生俱來的品質,而不是一種單純的技巧。理解指標需要腦子轉好幾個彎,某些人天生不擅長轉這幾個彎。

第三個問題可以考考面試者對C的位元運算的掌握,但這是一種技巧,不是一種品質,所以你可以幫助他們。有趣的等他們建立了一個子函數用來計算byte中為1的位元的數目,然後你要求他們優化這個子函數,儘量加快這個函數的運行速度。聰明的應試者會使用查表演算法(畢竟這個表只有256個元素,用不了多少記憶體),整個表只需要建立一次。跟聰明的應試者討論一下提高時間/空間效率的不同策略是十分有意思的事情。進一步告訴他們你不想在程式啟動時初始化查詢表。聰明的面試者可能會建議使用緩衝機制,對於一個特定的byte,只有在第一次被查詢時進行計算,然後計算結果會被放入查詢表。這樣以後再被查詢時直接查表就行了。而特別特別聰明的面試者會嘗試有沒有建立查詢表的捷徑,如一個byte和它的置1的bit數之間有沒有規律可循?

當你觀察應試者寫C程式碼時,以下一些技巧會對你有幫助:

    1. 事先向應試者說明,你完全理解,沒有一個好的編輯器光在紙上寫程式碼是困難的,所以你不在乎他們手寫的程式碼是否看上去不整潔。你也完全明白沒有好的編譯器和調試器,很難第一次就寫出完全沒有bug的程式,所以請他們不必為此擔心。
    2. 好程式設計師的標誌:好程式設計師寫完{符號後,通常立刻跟上}符號,然後再在當中填上程式碼。他們也傾向於使用命名規則,雖然這個規則可能很原始。如果一個變數用作迴圈語句的索引,好程式設計師通常使用盡可能少的字元為它命名。如果他們的迴圈語句的索引變數的名字是CurrentPagePositionLoopCounter,顯而易見他們寫程式碼的經驗還不夠多。偶爾,你會看到一個C程式設計師寫下像if (0==strlen(x))一樣的程式碼,常量被放在==的左邊。這是非常好的現象。這說明他因為總是把=和==搞混,已經強迫自己養成這種習慣以避免犯錯。
    3. 好的程式設計師在寫程式碼前會訂一個計劃,特別是當他們的程式碼用到了指標時。例如,如果你要求逆序一個鏈表,好程式設計師通常會在紙的一邊畫上鏈表的草圖,並表明演算法中的索引指標當前移動到的位置。他們不得不這樣做。正常人是不可能不借助草圖就開始寫一個逆序鏈表的程式的。差的程式設計師立刻開始寫程式碼。

不可避免的,你會在他們的程式中發現bug,於是我們現在來到了第五個問題:你對程式碼滿意嗎?你可能想問,「好吧,bug在哪裡?」這是來自地獄的一針見血的問題,要回答這個問題可要大費口舌。所有的程式設計師都會犯錯誤,這不是問題。但他們必須能找到錯誤。對於字串操作的函數,他們通常會忘記在輸出緩衝區加上字串結束符。所有的函數,他們都會犯off-by-one錯誤(譯註:指的是某個變數的最大值和最小值可能會和正常值差1)。他們會忘掉正常的C語句結尾的分號。如果輸入是零長度字串,他們的函數會運行錯誤。如果malloc調用失敗而他們沒有為此寫好錯誤處理程式碼,應用程式會崩潰。一次就能把所有事情做對的程式設計師非常,非常,非常地少。不過要是真的碰上一個的話,提問就更有意思了。你說,「還有Bug」。他們會再仔細地檢查一遍程式碼。這個時候,觀察一下他們內心是否開始動搖了,只是表面上勉強堅持說程式碼沒有問題。總之,在程式設計師寫完程式碼後,問一下他們是否對程式碼滿意是個好主意。就像Regis那樣問他們!(譯註,Regis Philbin是美國ABC電視網的遊戲電視節目主持人,他的口頭禪是「這是你的最後的答案嗎?」)

第六部分:關於設計的問題。讓應試者設計某樣東西。Jabe Blumenthal,Excel的原始設計者,喜歡讓應試者設計房子。Jabe說,曾經有一個應試者跑到白板前,畫了一個方塊,這就是他的全部設計。天哪,一個方塊!立刻拒絕這樣的傢夥。你喜歡問什麼樣的設計問題?

    1. 好的程式設計師會問更多的資訊。房子為誰造的?我們公司的政策是,我們不會錄取那些在設計前不問為誰設計的人。通常,我會很煩惱我得打斷他們的設計,說「事實上,你忘記問這個房子是給誰設計的了。這個房子是給一群長頸鹿造的。」
    2. 笨笨的應試者認為設計就像畫畫,你想畫什麼就畫什麼。聰明的應試者明白設計的過程是一系列艱難的權衡。一個很棒的設計問題是:設計一個放在街角的垃圾箱。想一想你得做多少權衡!垃圾箱必須易於清空,但是很難被偷走;易於放進垃圾,但是碰到狂風大作,裏面的垃圾不會被吹出來;垃圾箱必須堅固而便宜。在某些城市,垃圾箱必須特別設計,以防恐怖分子在裏面藏一個定時炸彈。
    3. 有創造力的應試者會給出有趣而獨特的設計。我最喜歡的問題之一是為盲人設計一個放調味料的架子(譯註:原文為spice rack,老外的廚房裏有個專門放調味料的架子,上面放了很多瓶瓶罐罐,裏面裝了各種各樣的調味料)。通常應試者會建議把點字刻在調味罐上,這樣文字往往會讓彎曲變形。碰到一個應試者,他的設計是把調料放在抽屜裏,因為他覺得水平地感知點字比垂直地做更方便。(試試看!)這個答案這樣有創意,使我震驚!我面試了有一打的程式設計師,從來沒有人想到過類似的答案。這樣有創意的答案確實躍過了普通人考慮問題的條條框框。僅僅因為這個答案太有創意了,而且應試者別的方面還過得去,我錄取了這個應試者,他現在已經成為Excel團隊中一個優秀的專案經理了(譯註,本文作者曾在微軟工作過)。
    4. 總是爭取一個確定的了結。這也是完成工作的特質的一部分。有時候應試者會猶猶豫豫不能作出一個決定,試圖回避困難的問題,留著困難的問題不作決定就直接向下進行,這很不好。好的應試者有一種推動事情自然地前進的傾向,即使你有意把他們拖回來。如果關於某個話題的討論開始原地打轉變得沒有意義了,好的應試者會說,「嗯,我們可以整天談論這個,但是我們得做點什麼。為什麼我們不開始...」。

於是我們來到了第七部分,挑戰。這部分很好玩。在面試中留心一下,當面試者的回答絕對的百分之百毫無爭議時,你可以說:「嗯,等一下等一下。」然後花上兩分鐘玩一下魔鬼的遊戲(譯註,原文為devil's advocate,魔鬼代言人指的是違背自己的良知,為錯誤邪惡的觀點辯護)。記住一定要在你可以肯定他正確時和他爭論。

這個很有意思。

    1. 軟弱的應試者會屈服。那我就和他說拜拜了。
    2. 堅定的應試者會找到一個辦法說服你。他們會以甘乃迪總統的口才來說服你,「也許我誤會了你的意思,」他們這樣開頭,但是正文仍是堅定地站穩立場。這樣的人我就錄取

不得不承認,面試雙方的地位並不是平等的。有可能應試者由於害怕你的權力而不敢於你爭辯。但是,好的應試者有足夠的熱情和勇氣堅持正確的觀點,他們由於熱切希望說服你而會暫時忘記正在被面試。這樣的人就是我們要錄取的人。

最後,可以問一下應試者有什麼想問的。一些人喜歡看看應試者這時是否會問一些聰明的問題。這是市面上流行的面試書籍的標準技巧。我個人不在乎應試者問什麼,因為這時我已經做了決定。麻煩在於,應試者也許已經見了5、6個人,進行了好幾輪面試,他們可能很累了,以至於不能為每輪面試都準備一個聰明而獨特的問題。所以如果他們沒有可問的,沒關係。

我總是留下面試的最後5分鐘來推銷我的公司。這很重要。即使我不打算錄取眼前這個應試者。如果你幸運的找到一個很棒的應試者,你當然願意做任何事情說服他(她)來你的公司。即使他們不是好的應試者,你也要盡力讓他們為Fog Creek公司激動,這樣面試結束時他們會對Fog Creek公司留下一個很好的印象。記住,應試者並不僅僅是可能的雇員,他們也是顧客,也是我們公司的推銷員。如果他們覺得我們的公司很棒,他們也許會推薦朋友來面試。

啊哈,我記得我說過我會給出一些應該避免的非常不好的反面的試題例子。

首先,避免不合法的問題。有關種族,宗教,性別,出生國,年齡,服役記錄,是否老兵,性傾向,生理障礙的問題都是不合法的。。即使他們的簡歷說他們1990年在軍中服役,也不要問有關問題。也許這會讓他們愉快地談論在海灣戰爭中的經歷。但是你的問題還是不合法的。如果簡歷上寫著他們在海法讀過Technion,不要問他們是否是以色列人,即使只是為了閒談,因為這是違法的。下面有一個很好的不合法的例子。點擊這裏有很多關於什麼是違法的討論。(但是這個網站的其餘問題夠愚蠢的。)

其次,不要在問題中給予應試者暗示,我們公司喜歡或者不喜歡什麼樣的員工。我能想到的一個例子是問應試者是否有小孩或者是否結婚了。應試者也許會想我們不喜歡有家庭拖累的員工。

最後,不要問那些腦筋急轉彎的題目,例如6根火柴怎麼拼出4個三角形。像這樣的靈機一動的問題是不能看出應試者是否有「有頭腦/完成工作」的品質。

面試與其說是科學不如說是藝術。但是只要你記住有頭腦/完成工作這個原則,你就可以應對自如。有機會就問問你的同事他們喜歡的面試問題和答案。這是我們公司員工午飯時熱衷的話題之一。

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


Personal tools