導讀：NumberGrinder 博主寫於2009年的一篇舊文，上週被推薦至 HN 後又成為熱帖。伯樂線上編譯如下：
最近我接到一個面試電話，被問了許多Java的問題。這樣的面試很平常，大部分的問題也都是標準問題：
● 什麼是多型？
● List和Set有什麼區別？你什麼時候用List，什麼時候用Set？
● 什麼情況下你會遇見死鎖？
● 強型別和弱型別有什麼區別？
這些算是很合理的問題。我不喜歡那個多型的問題，因為它和大部分的面嚮物件語言以及繼承緊密相關，而當我們覆蓋和過載一個方法時，我們是不會意識到“哦！這實際上是一個多型！”而我會想“什麼是繼承，我什麼時候應該用繼承”，而這才是面嚮物件語言的關鍵。但是這是我個人的觀點，可能會有其他不同觀點。
強型別和弱型別的那一題有點不尋常，因為他實際上指的是型別檢查而不是型別強度。當我說C是一種弱靜態，Java是強靜態，Python是強動態時，他有點迷糊（我認為JavaScript是弱動態，但我並沒有說出來）。
接下來的是一些細枝末節的問題：
● List在哪個包中？
● File在哪個包中？
● 你要繼承的時候用什麼關鍵字？
（我們也會經常遇見一些標準問題“你5年內想成為什麼樣的人？”等等）
Russ Olsen提到了問細枝末節問題的結果：
除了不能告訴你許多資訊以外，問細枝末節的問題會付出兩種代價：首先會佔用你真正可以用來了解一個人的時間，你可以利用這些時間來了解這個人是否足夠聰明，是否有合適的背景，是否合適你的團隊。其次，這種型別的問題有可能會剔除掉那些真正聰明的，你真正想僱傭的人呢。
我現在列出這些細枝末節的問題，我認為還會引發一個結果：問這樣的問題剔除掉那些真正合適的人之外，剩下的人將會錯誤的人選。
一個好的工程師在設計和創造系統的時候是抽象性的思維的，他們會想象演算法，元件，工程性的設計。他們不需要知道語言的所有細節，尤其是當他們使用IDE時，IDE可以幫他們完成（我使用Eclipse：我輸入List，然後輸入control+空格，IDE會自動幫我載入java.util.List）。我能分辨出我需要哪個包，這比我能記住它們的名字更重要。
類似的，更重要的是我能告訴你什麼時候我應該使用繼承，什麼時候應該使用多型，而不是僅僅記住概念。
總體而言：用Google 5秒鐘可以找到答案的問題不是好問題。我最喜歡的電話面試問題是“你最喜歡的語言是哪一種？”然後接著是“它的弱點是什麼？”
然而很多面試和考試測試的都是為了看你能否很好的取代編譯器而設定的。甚至Java認證考試都只關注在語言的語法和編譯上的問題，而不是測試實際程式設計的能力和實際設計系統個能力。
我是一個優秀的軟體工程師，我不是一個優秀的編譯器。我不能看了一段程式碼後就告訴你它有問題，它不會獲取ClassNotFoundException，現代的編譯器會告訴我問題的所在。即使不是馬上知道，但當我編譯的時候我會知道。這麼說我就過於依賴IDE？也許吧，但這不是什麼壞事，因為在辦公室裡我們還是要用到這些工具。
一句話：找一個適合團隊的人選時，不要糾結於細枝末節的問題。