【译文】我是程序员,不是编译器

最近,我参加了一次电话面试,面试官问了我各种各样的 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

你也许感兴趣的:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注