英文原文：I’m an Engineer, Not a Compiler 

　　原文作者：dclements，發(fā)布于 2009-2-23

　　最近我接到一個面試電話，被問了許多 Java 的問題。這樣的面試很平常，大部分的問題也都是標準問題：

　　● 什么是多態(tài)？

　　● List 和 Set 有什么區(qū)別？你什么時候用 List，什么時候用 Set？

　　● 什么情況下你會遇見死鎖？

　　● 強類型和弱類型有什么區(qū)別？

　　這些算是很合理的問題。我不喜歡那個多態(tài)的問題，因為它和大部分的面向?qū)ο笳Z言以及繼承緊密相關(guān)，而當我們覆蓋和重載一個方法時，我們是不會意識到“哦！這實際上是一個多態(tài)！”而我會想“什么是繼承，我什么時候應(yīng)該用繼承”，而這才是面向?qū)ο笳Z言的關(guān)鍵。但是這是我個人的觀點，可能會有其他不同觀點。

　　強類型和弱類型的那一題有點不尋常，因為他實際上指的是類型檢查而不是類型強度。當我說C是一種弱靜態(tài)，Java 是強靜態(tài)，Python 是強動態(tài)時，他有點迷糊（我認為 JavaScript 是弱動態(tài)，但我并沒有說出來）。

　　接下來的是一些細枝末節(jié)的問題：

　　● List 在哪個包中？

　　● File 在哪個包中？

　　● 你要繼承的時候用什么關(guān)鍵字？

　?。ㄎ覀円矔?jīng)常遇見一些標準問題“你 5 年內(nèi)想成為什么樣的人？”等等）

　　Russ Olsen 提到了問細枝末節(jié)問題的結(jié)果：

除了不能告訴你許多信息以外，問細枝末節(jié)的問題會付出兩種代價：首先會占用你真正可以用來了解一個人的時間，你可以利用這些時間來了解這個人是否足夠聰明，是否有合適的背景，是否適合你的團隊。其次，這種類型的問題有可能會剔除掉那些真正聰明的，你真正想雇傭的人呢。

　　我現(xiàn)在列出這些細枝末節(jié)的問題，我認為還會引發(fā)一個結(jié)果：問這樣的問題剔除掉那些真正合適的人之外，剩下的人將會錯誤的人選。

　　一個好的工程師在設(shè)計和創(chuàng)造系統(tǒng)的時候是抽象性的思維的，他們會想象算法，組件，工程性的設(shè)計。他們不需要知道語言的所有細節(jié)，尤其是當他們使用 IDE 時，IDE 可以幫他們完成（我使用 Eclipse：我輸入 List，然后輸入 control + 空格，IDE 會自動幫我載入 Java.util.List）。我能分辨出我需要哪個包，這比我能記住它們的名字更重要。

　　類似的，更重要的是我能告訴你什么時候我應(yīng)該使用繼承，什么時候應(yīng)該使用多態(tài)，而不是僅僅記住概念。

　　總體而言：用 Google 5 秒鐘可以找到答案的問題不是好問題。我最喜歡的電話面試問題是“你最喜歡的語言是哪一種？”然后接著是“它的弱點是什么？”

　　然而很多面試和考試測試的都是為了看你能否很好的取代編譯器而設(shè)置的。甚至 Java 認證考試都只關(guān)注在語言的語法和編譯上的問題，而不是測試實際編程的能力和實際設(shè)計系統(tǒng)個能力。

　　我是一個優(yōu)秀的軟件工程師，我不是一個優(yōu)秀的編譯器。我不能看了一段代碼后就告訴你它有問題，它不會獲取 ClassNotFoundException，現(xiàn)代的編譯器會告訴我問題的所在。即使不是馬上知道，但當我編譯的時候我會知道。這么說我就過于依賴 IDE？也許吧，但這不是什么壞事，因為在辦公室里我們還是要用到這些工具。

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

it知識庫：我是工程師，不是編譯器，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。