技术面试中应避免的 11 个错误

本文最初发表在我的博客smartpuffin.com上。

你即将参加一场技术面试。面试官会问你一个问题，然后你需要构建一个系统或者写一些代码，要么写在白板上（哇！），要么写在纸上，要么在家用笔记本电脑。然后你再和面试官讨论。

有人乐在其中，有人畏惧。但如果你正在经历这一切，就意味着这个过程即将结束！而你也确实渴望展现自己最好的一面。

我主持过120多场面试。以下是我注意到应聘者常犯的一些错误。

错误1. 屈尊俯就

我问了一个关于候选人解决​​方案的问题，候选人说：“啊，我看你不明白我在这里做了什么。（解释。）它解决了你的困惑吗？”

面试官希望你展示你的思维方式。他们不太可能感到困惑，因为他们面试过很多人，对这个问题非常熟悉，也见过很多可能的答案。即使他们真的看不懂你的代码（这种情况也时有发生），在不让他们感到不舒服的情况下，向他们解释你的结果也是一种礼貌。

重要性：入职后，你必须与团队成员沟通。面试官希望确保团队成员能够与经验丰富和缺乏经验的人进行良好的沟通。

错误2. 缺乏知识就使用流行语

字典树、NoSQL 数据库、负载均衡器、图、集群。如果你要使用它们，你必须解释原因。即使你根本不知道哈希是什么，也很容易理解。

“我在这里放一个负载均衡器，”候选人说着，在他的数据库集群旁边画了一个矩形。“它会每小时运行一次，查询所有数据库服务器，处理数据，并记录结果。”

嗯。这可不是负载均衡器能干的事。我以为我可能是口误，就此又问了几个问题。结果不是，他们一直叫它负载均衡器。好吧。

另一位应聘者说：“我用的是字典树。”当我要求他们提供更多信息时，他们连个小例子都展示不出来。

同时，即使对所有事情都不太了解，也没关系。只要诚实就好。关键在于不要假装知道你不知道的事情。

重要性：如果一家公司雇佣了一个在面试中“吹牛”过关，却缺乏真正知识的人，他们肯定会对工作结果感到失望。这就是为什么他们在招聘前会面试候选人——评估他们的知识水平。

有趣的是，还没有人尝试在我的采访中使用区块链。

错误3.缺乏推理

“我将在这里使用 NoSQL 数据库。”

“我的集群需要 50 台服务器。”

“我每天运行一次并检索 92 条记录。”

太好了，告诉我为什么。我相信你心里肯定有一些理由，有优点也有缺点，我很想听听。为什么不用 SQL？具体是哪个 NoSQL 数据库？NoSQL 这个总称下有太多数据库了，你真的需要缩小一下范围。图形数据库和面向文档的数据库适用于截然不同的用途。

为什么是 50 台服务器，而不是 70 台？为什么是每天而不是每小时？你从哪里得到这个 92 的数字？

为什么这很重要：面试官希望能够理解未来同事的决定。解释你的选择理由可以展现你基于逻辑、需求和数据而非一时兴起做出决策的能力。这是我关于推理为何重要的文章。

错误4.没有提出澄清问题

你的面试问题可能并非 100% 完整。这是故意为之：为了模拟真实世界的环境，在这种环境下你不太可能获得任务的完整描述。你应该提问，所以尽管问吧！

也要大声说出你的假设。有时你假设了某些事情，但面试官心里却有不同的想法。如果你不说出来，你的结果和面试官的期望就会不一致。

有时你或许会想问问：我讲的方向对吗？你想让我专注于这个还是那个？面试官会非常感激，因为他们不需要打断你来讨论他们的需求。

重要性：需求清晰且 100% 完整的情况非常少见。开发人员应该能够在实施之前明确这些需求。

错误5.忘记要求

我一开始就告诉候选人：“我们需要尽可能接近实时。” 在整个面试过程中，我都会重复这句话。最终，候选人每小时都会批量处理数据。

还有一种情况，候选人问会有多少个项目。我告诉他们一个很大的数字——比如说，2000万。候选人设计了一个可以容纳数千名用户的系统。

我们需要多语言支持，但候选人的代码仅支持 26 个 ascii 字母。

候选人需要注意。列出的要求很重要，应该考虑。如果你不知道该如何处理，可以建议：“我记得肯定还有其他语言。目前我只对英语有想法。我先解决英语的问题，然后再看看如何处理其他语言。” 这表明你没有忘记，也展现了你的优先级排序能力。

当你提出类似的建议时，将这部分代码抽象出来会很有帮助。把它放到一个方法或组件中，以便以后轻松替换。这里有一篇文章解释了为什么以及如何做到这一点。

为什么重要：如果用户有需求，他们不会忘记。如果开发人员忘记了，他们会不高兴。如果你真的无法支持某个需求，就明确地告诉面试官。然后你就可以做出权衡，就像在实际工作中一样。

错误 6. 忽略极端情况

候选人说：“我每 5 秒运行一次，选择过去 5 秒的记录。” 就在刚才，我们确定时间戳字段是随记录一起提供的。这意味着现在可以插入一条 7 秒前的新记录。这意味着我们永远不会处理这条记录。

候选人解答了一道关于国际象棋的问题，忘记了有角，访问了位于 [-1,-1] 的“棋盘”数组。

有三个工作进程，都选择最后未处理的记录。处理完成后，它们会将记录标记为“完成”。候选人没有想到将记录标记为“进行中”。这意味着一条记录最多会被处理三次。

试着逻辑地思考：你的解决方案在所有情况下都有效吗？你是否验证了用户输入？是否存在无限循环？如果传递 0、-1 或 INT_MAX 会怎样？你的系统如何从断开的网络连接中恢复？如果请求量达到峰值怎么办？

试着在脑子里测试一下，或者直接写一些测试题。大声说出你的思考过程。面试官可能会帮助你。

这里有一篇文章可以帮助您更好地思考极端情况。

重要性：用户的需求很少会包含任何极端情况。甚至一些基本情况也可能缺失。对于开发人员来说，能够识别这些情况并确保代码始终正常运行至关重要。

错误7. 过于深入细节

有一次，我让一个候选人开始选择系统不同组件之间通信所使用的协议。TCP 还是 UDP？当时组件还没有定义。

询问面试官他们是否希望你更详细地描述某件事会很有帮助。我发现一个不错的方法是先建立一个总体概述，然后再详细介绍具体部分。

重要性：在演示时，你需要确保每个人都能理解。过于深入的细节会分散注意力，偏离主题。而且，从实用的角度来看，这会给面试官留下足够的时间来讨论他们想要讨论的所有话题。

错误8.没有提供足够的细节

“所以我们将数据存储在这里，然后选择所需的记录”。

好的，我们把它们存储在哪个数据库中？采用什么模式或格式？哪些记录被认为是“需要的”？数据量有数亿行，我们如何加快选择过程？

我已经说过，解释太多细节可能会有问题。然而，略过重要部分也并非完美。尤其是当面试官告诉你他们对某个特定部分感兴趣时，你应该专注于那部分。

重要性：面试官希望在头脑中对解决方案有一个相当清楚的认识，以便能够正确评估结果。

另外，如果你对某些事情考虑不充分，很可能会错过一些关键点，甚至是基本情况。以数据库为例。如果有数十亿行数据，它们很可能无法在一台机器上存放，所以你必须构建其他东西来解决这个问题。

错误9.隐含的假设

对话通常是这样的。

候选人说：“数据太多了，我需要一个具有分片的集群、30 个节点和 3 个副本、一个负载均衡器，还有……”

我问道：“我们这里到底有多少数据？”

候选人停顿了一下并问道：“那么，我们有多少用户？”

看到了吗？目前还不清楚具体有哪些数据、来自多少用户、数据采集频率如何，但我们已经有一个包含 90 台机器的集群了。好贵啊！

提出问题。有多少用户？多少数据？我们能容忍的响应时间是多少？

经过一番计算，我们通常只需要存储 200MB 的数据。太棒了！我们立刻在那个集群上省了不少钱。

为什么重要：出于同样的原因，需求也很重要。面试官，以及最终你的用户，脑子里会浮现出一个画面，而你，则会有一个截然不同的画面。除非你谈论它，否则你最终可能会实现错误的东西。

错误10.回避问题

“如果发生 X 情况会发生什么？”

“嗯，你知道，如果 Y 我要做 Z，并且如果 A 或 B，那么 C 就会失败......”

“好的，那么X 怎么样？”

“让我们看看，如果 X...哦，这让我想起了，当我们有 D...”

很高兴你有这么多想法可以分享。先试着回答一下问题，然后再继续讨论其他想法。

重要性：面试官问你问题肯定是有原因的。他们想更好地了解你的知识储备，熟悉你的思维过程。如果你不回答，他们就无法回答。当你被录用后，你的经理和同事也会感激你提供他们想要的信息。

错误11.对面试官不礼貌

一位应聘者总是看着我的男面试官，而且只跟他说话，即使我问问题也是如此。这当然让我们两位面试官都感到很不舒服。我们该如何合作呢？

据说有些求职者完全无视女性面试官。有时他们认为所有女性都是HR。有时他们对HR（无论男女）都很粗鲁。有时他们傲慢地拒绝回答问题。我实在无法理解他们为什么这么做，但他们就是这么做的。

重要性：我希望与友善、礼貌、尊重我的人共事。其他人也一样。如果应聘者在面试开始时就对周围的人发表一些粗鲁的评论，那么他们显然不适合——对任何团队来说都不适合。

附言：文章开头那张可爱的海鹦照片是我最近在设得兰群岛度假时拍的。这跟我面试失误没关系。我只是喜欢海鹦而已。