No.4 编程语言命令不佳
出现率: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搜索查询将会得到很多信息。
No.5 不使用测试
出现率: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)。
第二次是在勾画出解决方案之后,使用测试用例,通过伪代码来引导并验证其正确性。
第三次是在完成了编写代码后,再次进行测试,以确保没有任何问题。
No.6 错误解读问题
出现率: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.
建议:
在面试官解释完问题之后,第一件事就是用自己的话复述一遍,以证实是否正确地理解了问题。如果弄错了,面试官会告诉你的。这样简单的一步可以避免文不对题的尴尬。
在复述这个问题的同时,可以适当提出几个简单的输入示例,以确保预期结果的正确性。这会让面试官更容易知道你是否理解了这个问题。
另一项需要注意的是,可以适当做出某些假设。例如,你可以询问,输入是否排序,自己是否可以假设输入是有效的,或是在特定范围内的。也可以和面试官一起缕清需不需要针对时间或空间进行优化。
No.7 忽略边缘案例
出现率:8.31%
问题所在:
在所有的问题中,读题错误是最容易避免的。但依然有大约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.
建议:
在面试官解释完问题之后,第一件事就是用自己的话复述一遍,以证实是否正确地理解了问题。如果弄错了,面试官会告诉你的。这样简单的一步可以避免文不对题的尴尬。
在复述这个问题的同时,可以适当提出几个简单的输入示例,以确保预期结果的正确性。这会让面试官更容易知道你是否理解了这个问题。
另一项需要注意的是,可以适当做出某些假设。例如,你可以询问,输入是否排序,自己是否可以假设输入是有效的,或是在特定范围内的。也可以和面试官一起缕清需不需要针对时间或空间进行优化。
No.8 代码不易理解
出现率: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检查和许多特殊情况)而不考虑是否必要。这导致代码更复杂,更加难以理解和调试。
建议:
适当保持代码简短。按照常识在适用的地方给出描述性的名字,并在面试期间选择一种代码标准。最好使用惯用的代码。否则,面试官可能会怀疑你的编程语言运用的不够熟练。