工程师面试官总结候选人常见失误，写给未来的自己

前段时间，我获得了一个难得的机会，在我所任职的公司面试高级工程师岗位的候选人。在和几十个人交流之后，我开始注意到一些反复出现的相同模式——正是这些模式让面试偏离正轨。想到有一天我也会坐在桌子的另一边，我决定把这些写下来，留给未来的自己。其中有些道理显而易见。而这也恰恰是人们一再忘记它们的原因。而且很有可能，我也会忘。

听起来很明显，但我仍然震惊于人们违反这条规则的频率。生活总有意外，大多数面试官都会理解——他们毕竟也是人（至少大多数是）。但无论是什么事情耽搁了你，请务必联系面试官或安排会议的人，让他们知道。这是基本的职业礼貌。最糟糕的做法是迟到十分钟一言不发地加入，装作什么都没发生。

作为一名全栈开发者，你可能每周都要在几种语言之间切换好几次——用 Clojure 实现后端，用 TypeScript 写前端，时不时再丢进一些 Python 脚本，或者在午餐时间用 Brainf*ck 实现俄罗斯方块。通常需要几个小时才能完全切换上下文，达到不用停下来思考 for 循环怎么写的状态（Clojure，说的就是你），或者不用想 Java 里怎么定义 Enum。问题在于，在编程面试中你没有那几个小时。至少提前一天切换上下文——打开你的 Emacs，深入钻研你选的这门语言，做几道 kata。然后让肌肉记忆在第二天替你工作。

如果你有选择，尽量倾向动态类型语言（除非岗位明确要求静态类型语言）。用 Java 把东西跑起来比 Python 要多花相当多的精力和样板代码。理想情况下，手边有一个 REPL——你可以快速验证语法、检查函数输出、或者查看 docstring。压力会让人忘记基本语法结构。假设你会突然想不起循环怎么写、switch 语句怎么用，并为此做好准备。

如今有了各种 LLM，你可能已经意识到，这类练习其实并不真正关乎写代码。机器写代码比我们大多数人都好——尽管它们仍然不会思考（至少我一直这么告诉自己）。这正是我们见面的原因。我们需要的是一个会思考的人，而不只是另一台写码机器。而这是你展示人性一面的机会——不是超能力，我们又不是 ClosedAI。很有可能，我们最终会一起工作，所以我在意你如何着手一个问题：你会把它拆成更小的部分吗？你如何提问，哪怕是那些看起来显而易见的问题？你如何把思考过程说出来？想象你已经在和一个未来的队友交谈——因为面试官想象的恰恰也是这个。一言不发、含混嘟囔、思路混乱地跳来跳去——所有这些都远比编译不过的代码糟糕得多。我面试过的最聪明的人并不是最好的程序员。他们是思考者，能清晰地阐述自己接下来要做什么。

最大的危险信号之一：不读完全部说明就直接开始实现。或者没有完全理解说明。更糟的是——不听面试官的话，无视他们试图告诉你的内容。确保你掌握了全貌，就像 LLM 构建它的上下文窗口一样。如果有任何不清楚或缺失的地方——看在上帝的份上，问。有些说明是故意留白的，用来测试你的理解。而且你的假设往往都是错的。

把控时间安排是面试官的事，但把工作拆分好是你自己的责任，免得在结束前五分钟才意外发现还有些边界情况要处理，或者还得补几个测试。这就是恐慌模式启动的转折点。我们至少都经历过一次。

你真觉得对面的高级工程师看不出来吗？暴露你的微妙信号远比你想象的多。当然，你或许能压制其中一些——但你需要是一个克格勃训练出来的、钢铁般神经的间谍才能控制住整个肢体语言。你的语调会变、语速会变，你会整整一分钟不眨眼，眼睛却不由自主地左右乱瞟——然后你给出一个完美的回答，却在对方进一步追问的瞬间彻底沉默。这可不有趣。

面试不是单行道——至少不该是。这是你询问对自己重要的事情的机会。提前准备好那些问题。说真的，准备好。到场后问“你喜欢在这里工作什么？”或者“所以这家公司到底是做什么的？”会留下不好的印象，即使其他一切进行得还算顺利。

就像生活中的其他事情一样，练得越多水平越高，面试也不例外。找一些你并不是特别想去的公司，用它们来练到编程面试环节。关键在于从错误中学习。主动索取反馈，写下自己的反思。把它当作一次复盘：哪里出了问题？哪里可以做得更好？我本怎样才能避免这样那样？对收到的每一条批评都心怀感激。那才是帮助你成长、提升下一轮机会的东西。