提出實務性問題，鑑別應試者實力

開放性的問題，有較大的表達空間。這麼做的目的，是希望不要限縮答題的範圍，讓應試者吐露更多的線索，你便有機會深入了解他的個人特質，以及技術水平。

身為面談者，你可以設計幾個大範圍的問題，並且試著在應試者回答的過程中，因應他的答案，更進一步地引導並追問更特定的問題。大原則便是要了解他是否是個符合你所設定條件的人。

以觀念性的問題，由淺入深驗證履歷表的虛實
除了試著透過面談了解應試者的人格特質及技術水平之外，面談者還有一項重要的工作，便是試著驗證應試者履歷表的虛實，尤其是專業的部分。你會邀請應試者進一步面談，有一部分的原因，便是從履歷上看來，該應試者有可能滿足你所設定徵才的條件。

例如，他對你所期望的專業領域有所了解、或者他能運用你希望新成員熟悉的程式語言，或者他應該具備基礎的電腦科學背景知識……等。

那麼，你便可以透過面談，驗證履歷表中所載的內容是否屬實。

他在履歷表上宣稱自己熟悉Java，那麼，在面談中詢問幾個關於Java的專業問題，那是免不了的。但是，我建議像這一類的問題，以偏向觀念性質的為主、問題的難度應該從淺到深都有，而且，最好是實務撰寫程式時一定會遇到的。

為什麼問題最好是以偏向觀念為主呢？太瑣碎的技術性問題，有時不見得能反映實力，觀念的正確與否，則是比較關鍵的一環。觀念對了，即使細節不是那麼熟悉，只需要查閱資料就可以解決。但若是觀念不正確，要求對方重新建立正確的觀念，反而是一件更困難的事情。

此外，之所以問題的難度最好深淺兼具，是因為組合搭配起來會比較有鑑別率。我們提出問題的目的，並不在於要問倒應試者，或者期望應試者能夠答對所有艱深的問題。簡單的來說，面談的目的，就是希望在短時間內盡可能了解到最真實的對方。

驗證的目的是要確認能力，而冷門的題目沒有鑑別度
我們的期待應該是透過這些有深有淺的問題，盡可能地評估出來應試者對這個領域的實力所在。因為事實上，即使他的實力目前還達不到某個水平，但只要學得快，也不會構成什麼大問題。

簡單的問題，可以像是Java的public、private等存取權限修飾詞的意思，以及作用？什麼樣的情況會選用public？什麼樣的情況會選用private？要是像這類簡單的問題都答不出來，那麼應試者宣稱他能夠以Java撰寫程式，就令人十分存疑了。

稍難的問題，可以像是Java的多型是如何運作？和C++的多型機制相比又有什麼差異（如果他也同時宣稱他能夠以C++撰寫程式的話）？多型機制在實務的設計上，能夠派上什麼樣的用場？這些都是觀念性質的問題，也是程式設計實務上會碰到的問題。倘若應試者能夠回答這種難度的問題，那麼他履歷表上填寫能夠以Java撰寫程式，幾乎可以確定所言非虛了。

在實務上幾乎不會用到的問題，我們沒有必要考應試者太多，像是一些很冷門的程式語言特性，幾乎在實務上不會遭遇到，即使應試者答不出來，也沒有太重要的代表性。

問實務上會遇到的問題，最能一翻兩瞪眼
程式設計這個領域，只要問題問得適宜，其實幾乎不需要請應試者當場撰寫程式，就可以問出深度。例如應試者宣稱他能以某程式語言撰寫程式，你只需要詢問一些實務上必然會遭遇到的問題，即可驗證此事。

這種問題的回答是一翻兩瞪眼，很難唬弄過去。應試者宣稱懂得設計模式，我們只需要問他，生成性模式（Creational Patterns）的作用什麼，其中Simple Factory模式的用途又在那？也就大概能估量出他對設計模式的熟悉程度。

一名真的有實際程式撰寫經驗的Java程式設計者，應當會明白什麼場合該使用HashMap、什麼場合該使用TreeMap、什麼場合又該使用ArrayList。

有的人或許喜歡問經典問題，例如如何以C自行撰寫strcpy()函式。不過，最近我看坊間已經有好幾本關於程式設計工作面談問題的書籍出版，在此類的書籍中，對各式經典的問題都有整理及解答，因而降低了回答這些經典問題的參考性，因為就像考試前的補習一樣，這類的書籍，都會讓測驗的結果變得失真。

與其太依賴此類的問題，不如確實地從你自身的實務經驗中，發掘更可靠的題目，用以驗證應試者是否真的具備如他所述的能力。

小心錯失無法忠實表達實力的人
身為面談者，你的考驗除了要找出誇大自身能力的人之外，同時也需要注意那種無法忠實表達出自己實力的人。

能找到表達能力好的程式設計者當然是加分，不過有時候我們面對的情況並不那麼完美，而表達能力不那麼好、但足以擔當責任的程式設計者，仍然還是我們希望招攬的目標。

不要忘了，我們的面談工作並不是以刷掉對方為目的，真正的用意還是希望能夠找到可用之材，即使他的表達能力並不那麼好。當然，這就有賴面談者從應試者的答案中去觀察和推論了。

面試是互相檢視，別忘了給對方提問機會
面談，英文字是「Interview」，有互相檢視的味道存在。

除了由面談者詢問問題之外，也應該適度地開放時間，讓應試者有機會可以了解他所想要知道的事情。基本的資訊，像是公司的福利、開發方法、正在開發的產品、未來的產品走向、公司的願景及文化等。

招攬人才不單只是人求事，同時也是事求人，必須二者對彼此的條件都能匹配才行。應試者需要了解團隊的文化，因為他也有可能成為此團隊中的一員，倘若不能、或不適合融入這個團隊的文化，那麼即使是能力方面沒有問題，也不適合招攬進來，因為即使是加入，也是會造成雙方的困擾。

所以，就算是應試者沒有主動提起，你也可以提示或引導他詢問此類的問題，以確保雙方在日後能夠愉快地合作。

找同儕一起參加面談，也是個不錯的做法
面談通常是招募活動的尾聲，不同公司需要面談的次數不盡相同。我有一名朋友參加一個美商公司的面談，其回合數多達8次。每一回合的面談者角色都不盡相同。

當然，大多數的中小型軟體公司，都不會需要這麼多回合的面談。不過，除了技術主管或人事主管的面談之外，納入同儕間的面談，其實是個不錯的做法。除了從不同的角度詢問問題，並且從中觀察反應之外，也可以讓同儕確認這是日後要一起共事的夥伴。

面談是最後一關，對於能不能找到合適的人進入團隊，這一關扮演了關鍵性的角色。找到正確的人，團隊戰力即可增加，倘若找到不適合的人，就容易演變成「請神容易送神難」的局面，增加許多不必要的困擾。所以，請各位主管們務必善用面談這個重要的過程，找出真正符合需求的人才。