最近，我参加了一次电话面试，面试官问了我各种各样的 Java 问题。这类问题是标准问题，而且大多数问题都有些标准：
- 什么是多态性？
- List 和 Set 有什么区别？什么情况下你会使用一个而不是另一个？
- 什么情况下会出现死锁？
- 强类型和弱类型有什么区别？
这些基本都是可以讨论的问题。我不喜欢 “多态性 “这一条，只是因为它与大多数 OO 语言和继承关系密切，以至于大多数人在使用它时–例如，在覆盖或重载一个方法时–都不会想到 “哦！这就是多态性的作用！”相反，我可能会问 “什么是继承，你在哪里使用它”，这在 OO 语言中通常有一个关键字或模式。但这只是个人偏好，我也明白其中的道理。
强类型和弱类型的问题有点不寻常，因为他实际上指的是类型检查而不是类型强度，当我把 C 语言描述为弱静态语言、Java 语言描述为强静态语言、Python 语言描述为强动态语言时，他有点糊涂了（我认为 JavaScript 是弱动态语言，但我没有提到）。
不过，接下来出现的都是“小”问题：
- List 在哪个包里？
- File 属于哪个包？
- 你用什么关键字继承？
(我们还遇到了 “标准面试问题”，比如 “你认为自己 5 年后会在哪里 “等）。
拉斯-奥尔森(Russ Olsen)提到了提出“小”面试问题的两个后果：
首先，它占用了你本可以用来了解这个人的时间，让你不知道他是否足够聪明、是否有合适的背景、是否适合你的团队。这种问题的第二个代价是，它往往会把那些你真正想要聘用的聪明、全面的人拒之门外。
我在这里列出的纳米级问题都是对的，但让我抛出第三个后果：问一些微小的问题可能会导致错误的否定，把那些原本非常适合的人排除在外。
优秀的工程师在设计和构建系统时会进行抽象思维，他们会从算法、组件和工程设计的角度进行思考。他们并不一定了解特定语言的所有语法细节，尤其是如果他们已经习惯了由一个好的集成开发环境来代劳（我使用 Eclipse：输入 List，然后控制空格来加载 java.util.List）。更重要的是，我必须知道我需要哪个软件包，而不是凭空说出它的名字。
同样，比起能说出定义，更重要的是我能告诉你何时何地应该使用继承，何时何地应该使用多态。
基本上是这样：任何用 Google/ChatGPT 花 5 秒钟就能回答的问题都不是好问题。我最喜欢的电话面试问题？”你最喜欢的语言是什么？”然后是 “它的弱点是什么？”
然而，很多面试和考试基本上都是在测试你能不能替代编译器。即使是 Java 认证考试也倾向于关注语法和编译问题，而不是你的实际编程能力或系统设计能力如何。
我是一个优秀的工程师，但我不是一个优秀的编译器。我不可能看着一个代码块就告诉你它的问题在于无法捕获 ClassNotFoundException，而现代编译器会告诉我这是个问题。现代编译器会告诉我这是个问题，即使不能立即告诉我，至少也会在我尝试编译时告诉我。IDE 依赖性？也许吧，但这并不一定是件坏事，因为这代表了他们将在办公室使用的工具。
本文文字及图片出自 I'm A Developer Not A Compiler
你的反应是：