注意事项 | 超20000次统计！8大面试易错点重磅出炉！

出现率：20.66%

问题所在：

在彻底思考好解决方案之前，深入编写代码无疑是得不偿失的。没有完整的方案就开始编码，当你意识到你所做的事情太复杂或毫无意义时，时间已经所剩无几。

莽撞而匆忙的行为或许是因为紧张，或许是因为过度自信，切记悬崖勒马！一边编写代码一边找出解决方案其实并不可行，这会耗尽时间，匆忙编写代码的结果是“做得更多”而不是“做的更好”。

建议：

首先需要理清自己的思路，将整个问题分解成简单的小部分。当准备开始编写代码时，最好先写出伪代码来解析自己的方法。以举例的方式，来说明算法中的关键步骤。

Only after both you and your interviewer agree that you have a good solution, proceed to implementation.

在开始编写前，早些提及那些缺乏理性的，粗暴或天真的方案是必要的，这有以下三个原因：

首先，它可以避免尴尬的沉默时刻，让你有可以描述表达的观点；同时也有助于找出最佳的解决方案。

其次，不成熟的解决方法有时可以通过优化，成为最佳解决方案。

最后，作为一名软件工程师，主要职责是编写一个可行的解决方案。正确性优先于效率。

出现率：20.05%

问题所在：

不管喜不喜欢，而今大多数编码面试仍然围绕数据结构和算法（DS＆A）的问题展开。无论是Dropbox，Airbnb，Uber＆Palantir这样的拟上市初创公司，还是Google，Meta， Amazon，Apple这样的巨头公司，都是如此。

You may be an exceptional practical programmer, but if your command of core DS&A is lacking, you’re unlikely to get the job that you want. Yes, this sucks, but that’s reality.

建议：

利用一些时间学习或复习数据结构和算法（DS＆A）。这不仅可以帮助你度过编码面试，还可以让你成为更好的软件工程师。掌握基本的DS＆A是每一位软件工程师的基本技能。

出现率：15.80%

问题所在：

面试官不是绝地武士，不会读心。你可能会因为思路不是十分清晰连贯而感到焦虑，但如果不能鼓起勇气说话，通过面试的希望便十分渺茫了。仅仅在面试开始时，解释解决问题的方法是不够的。即使在执行和测试算法期间，也最好和面试官保持全程交流。

建议：

夸大我们的想法，对于其他人来说，显而易见是一种常见的认知偏见，在过度交流方面更是如此。在面试时，向面试官展示你的步骤和推理过程。如果你感到焦虑，不能有效地表达你的想法，可以寻找一些让自己冷静下来的技巧。一边谈话一边编码对很多人来说并不十分习惯，一个专业的练习平台是必要的。

出现率：12.56%

问题所在：

你可能有很好的解决问题的能力和算法思维，但如果你不知道所选择的编程语言的核心结构，功能和语法，那么这将会造成一定的麻烦。

考官基本不会考察在稀有情况下使用的一些深奥数据的结构界面。但如果你不了解基础的知识点，例如C中的内存管理，Java中的继承，Python中的列表解析或者JavaScript中的闭包，那么再见，你的面试基本GG了。初学者一般容易犯下这个错误，但它也时时发生在拥有深厚理论知识但缺乏实践经验的学者身上。

建议：

如果可以选择，尽量用自己最熟悉的编程语言进行面试。面试官通常是灵活的，可以让你选择熟悉的编程语言。如果情况特殊，例如面试必须使用JavaScript的前端职位，那么就需要做好复习，提前掌握需要的编程语言技能。

Learning from books won’t cut it and you need to get your hands dirty. Program a few projects, contribute to open source, or better yet, do both.

边学边练习是真正掌握编程语言的唯一方法。如果你需要一个关于项目的想法，利用Google搜索查询将会得到很多信息。

出现率：10.33%

问题所在：

因为没有进行测试运行代码，与职位失之交臂。首先，代码在某些特定的测试中失败是很常见的事。经过测试，可以发现错误并尽快解决它们。此外，你可能会想出一个面试官没有想过的原创解决方案。通过举例说明，展示每一行代码中每个变量的变化，让面试官更容易理解这个解决方案是有效的。

Hiring engineering managers love test cases. In fact, for some of them not using tests is an outright deal breaker even if you reached to the right solution.

建议：

在面试中，建议分三次测试方案。

第一次是在面试官问过你编码问题之后，使用一个或两个例子来验证是否完全理解了这个问题（更多细节参见No. 06）。

第二次是在勾画出解决方案之后，使用测试用例，通过伪代码来引导并验证其正确性。

第三次是在完成了编写代码后，再次进行测试，以确保没有任何问题。

出现率：9.11%

问题所在：

在所有的问题中，读题错误是最容易避免的。但依然有大约9％的面试者会马虎以至于误读问题。这里没有太多需要说明的地方。

If you misunderstood the interview question or made assumptions about the problem statement or input that you shouldn’t have, it’s likely that you’ll fail your interview.

建议：

在面试官解释完问题之后，第一件事就是用自己的话复述一遍，以证实是否正确地理解了问题。如果弄错了，面试官会告诉你的。这样简单的一步可以避免文不对题的尴尬。

在复述这个问题的同时，可以适当提出几个简单的输入示例，以确保预期结果的正确性。这会让面试官更容易知道你是否理解了这个问题。

另一项需要注意的是，可以适当做出某些假设。例如，你可以询问，输入是否排序，自己是否可以假设输入是有效的，或是在特定范围内的。也可以和面试官一起缕清需不需要针对时间或空间进行优化。

出现率：8.31%

问题所在：

忽略边缘案例一定程度上表明面试者解决问题的能力不足。首先，如果算法没有处理所有有效的输入，那么这个解决方案就是不完整的。其次，因为没有考虑边缘情况，错过了更好的可以消除边缘情况的算法。

例如，在填出等式中空出的数字这个问题中，一个简单的解决方案是从总和（1，...，n）中减去输入数组的总和。但是，对于足够大的'n'来说，解决方案将由于整数溢出而失败。这个边缘案例迫使你想出更好的解决方案。通过使用位运算符XOR，可以设计一个不再容易溢出的解决方案。

建议：

围绕算法输入的边界使用测试。如果算法在某些边缘情况下失败，首先检查是否可以通过快速增量更改来修复算法。如果不能，询问面试官你是否应该处理这些边缘案例。

在需要处理边缘案例而你却毫无头绪时，尝试与面试官交流并试图寻求他们的帮助。

出现率：7.69%

问题所在：

技术面试不仅仅关乎正确性和效率，也关乎面试者的代码风格。你的代码也许是有效率的，经得住推敲的，但如果只有你自己能够理解代码，那么面试结果，十之八九是惨烈的。

Hiring managers look for engineers whose code is legible, maintainable and idiomatic. Code that other team members can pick up from where you left off easily.

这个问题在初学者、语言切换者和编程竞赛参与者中很是普遍。以下是应该避免的一些造型错误：

一.给变量，函数等赋予随机的，非描述性名称。例如，对非索引变量使用单个字符名称，或者调用函数'func'。编程竞赛开发人员尤其需要小心，因为他们习惯于在其程序中使用短名称，以便更快地编写代码。这在面试中是非常不利的。

二. 代码风格不一致。每个人都有自己的编程风格，但混合随机编码标准并不是一个好主意。例如，使用不同的命名方式，或者同时在camp Richard和camp Winnie使用制表符。同样，如果您将大括号放在同一行上，不要在后面的编程时又放在新行中。

三. 使用保护性代码（例如NULL检查和许多特殊情况）而不考虑是否必要。这导致代码更复杂，更加难以理解和调试。

建议：

适当保持代码简短。按照常识在适用的地方给出描述性的名字，并在面试期间选择一种代码标准。最好使用惯用的代码。否则，面试官可能会怀疑你的编程语言运用的不够熟练。