我是工程師,不是編譯器

最近我接到一個面試電話，被問了許多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？也許吧，但這不是什麼壞事，因為在辦公室裡我們還是要用到這些工具。

一句話：找一個合适團隊的人選時，不要糾結于細枝末節的問題。