我是一个优秀的软件工程师，我不是一个优秀的编译器

汪星人

最近我接到一个面试电话，被问了许多java的问题。这样的面试很平常，大部分的问题也都是标准问题：
! h8 ]5 J1 X& @9 ]  i# M4 B. S● 什么是多态？
, T* g4 i/ o3 E1 p( \0 [' t: s● List和Set有什么区别？你什么时候用List，什么时候用Set？
' G; C% Z6 B: e) P! }" ~+ I● 什么情况下你会遇见死锁？
● 强类型和弱类型有什么区别？

) a. L' d  m' Z+ ^5 A" Q, z* a& b这些算是很合理的问题。我不喜欢那个多态的问题，因为它和大部分的面向对象语言以及继承紧密相关，而当我们覆盖和重载一个方法时，我们是不会意识到“哦！这实际上是一个多态！”而我会想“什么是继承，我什么时候应该用继承”，而这才是面向对象语言的关键。但是这是我个人的观点，可能会有其他不同观点。
4 C2 C  l" ~% b( }  e# @强类型和弱类型的那一题有点不寻常，因为他实际上指的是类型检查而不是类型强度。当我说C是一种弱静态，Java是强静态，Python是强动态时，他有点迷糊（我认为JavaScript是弱动态，但我并没有说出来）。

接下来的是一些细枝末节的问题：
● List在哪个包中？
# J" g6 Y" y/ F" V● File在哪个包中？
● 你要继承的时候用什么关键字？

(我们也会经常遇见一些标准问题“你5年内想成为什么样的人？”等等）

Russ Olsen提到了问细枝末节问题的结果：
除了不能告诉你许多信息以外，问细枝末节的问题会付出两种代价：首先会占用你真正可以用来了解一个人的时间，你可以利用这些时间来了解这个人是否足够聪明，是否有合适的背景，是否合适你的团队。其次，这种类型的问题有可能会剔除掉那些真正聪明的，你真正想雇佣的人呢。

9 K% q6 c8 `' M/ ~& |) @

我现在列出这些细枝末节的问题，我认为还会引发一个结果：问这样的问题剔除掉那些真正合适的人之外，剩下的人将会错误的人选。

' v: ^- h# j2 r$ d) @一个好的工程师在设计和创造系统的时候是抽象性的思维的，他们会想象算法，组件，工程性的设计。他们不需要知道语言的所有细节，尤其是当他们使用IDE时，IDE可以帮他们完成（我使用Eclipse：我输入List，然后输入control+空格，IDE会自动帮我载入java.util.List）。我能分辨出我需要哪个包，这比我能记住它们的名字更重要。

类似的，更重要的是我能告诉你什么时候我应该使用继承，什么时候应该使用多态，而不是仅仅记住概念。
总体而言：用Google 5秒钟可以找到答案的问题不是好问题。我最喜欢的电话面试问题是“你最喜欢的语言是哪一种？”然后接着是“它的弱点是什么？”

- F- g6 L3 G, E然而很多面试和考试测试的都是为了看你能否很好的取代编译器而设置的。甚至Java认证考试都只关注在语言的语法和编译上的问题，而不是测试实际编程的能力和实际设计系统个能力。

我是一个优秀的软件工程师，我不是一个优秀的编译器。我不能看了一段代码后就告诉你它有问题，它不会获取ClassNotFoundException，现代的编译器会告诉我问题的所在。即使不是马上知道，但当我编译的时候我会知道。这么说我就过于依赖IDE？也许吧，但这不是什么坏事，因为在办公室里我们还是要用到这些工具。
; `) V8 \+ K  G一句话：找一个合适团队的人选时，不要纠结于细枝末节的问题。