170
我是工程師,不是編譯器
最近我接到一個麵試電話，被問了許多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？也許吧，但這不是什麼壞事，因為在辦公室裏我們還是要用到這些工具。
一句話：找一個合適團隊的人選時，不要糾結於細枝末節的問題。
原帖地址：https://www.iteye.com/topic/1121960
最後更新：2017-04-02 22:16:40