经验总结！我们是如何在编程面试中挂掉的
作者：Michael Lazarski
编译：张晶晶
阅读编程题目不够细致
有时一字之差就会完全改变要求原意，或许你在第一时间并未领会该词要义，又或许以为自己领会到了，然而实际上未必。
改进：将题目多读几遍，直到真正理解。
未使用Git客户端，或其他版本控制系统
千万不要把完整的node_modules压缩成60Mzip文件后电邮，OSX系统对解压缩node_modules并不友好，所以阅件人甚至都不会看你的代码。
用Git客户端解决上述问题。若不了解Git，正好认真学一下。很多大公司都用Git，迟早要学。
不会写优秀的提交说明
改用Git后，不要把所有工作一次性提交。公司在看git日志时会浏览提交说明。你必须谨记以后将是团队工作，其中优秀的提交说明格外重要。对团队成员而言，两周之内消化理解提交内容所涉及的应用至关重要，所以你应该分多次提交，写说明尽量简洁明了。
忘记.gitignore文件
如果你没有.gitignore文件，该目录中的所有内容都将添加到Git中。相当于你发送的依旧是完整的node_modules，而node_modules没人去看。
.gitignore文件汇总请点击：
https://github.com/github/gitignore
通过电子邮件的发送zip文件
作为开发人员你必须知道GitHub！所以尽量使用它。把代码放在GitHub上，并将GitHub链接发给阅件人，这会给其留下个好印象。注意以下几点：
1、公司垃圾邮件过滤器不会删除zip文件；
2、即使在2019年电子邮件仍然有大小限制，或许你发邮时会受限；
3、简单扫一眼确保代码没下载为zip文件；
4、通常公司里不止一人看你的代码，确保看你代码的其他开发人员易于浏览。
没有README.md文件，或者写的不好
Github会显示README.md文件，这将显示在你报告的主页。尽量丰富其内容。例如，任务命名或解释任务作用等方法或许会锦上添花。由此，引出下一个误区。
对如何启动编程任务未作介绍
阅件人会在package.json文件查看脚本，写的好的话会看哪条可行，哪条不可行。所以请在README.md中写下如何设置、启动任务，以便阅件人运行。
编程任务没有有效链接
或许你会有这样的疑问：我刚刚在写链接你却叫我写运行介绍？尽量让编程代码审核流畅，审核人才不会因花费近一小时来看懂代码和任务要求是否匹配而不高兴。设置有效的且在Heroku，GitHub pages，AWS 或Azure等页面中兼容的链接也是很简单的事。
没有从任务中删除旧的/不需要的文件
不要在Git库中设置“old”文件夹，阅件人看到只会不知所措，犹豫该不该看下去，并对此表示无奈。所以务必在代码中删除之前的和不必要的文件。
没有写一封漂亮的关于GitHub回复的邮件
发送只含链接的空邮件会被认为十分失礼。至少写上：“X您好，希望您诸事顺遂。这是我的编程任务链接。【链接】张三！”。等等~
不要随意说某事轻而易举
有个普遍现象——有人说“Java一点儿也不难”，我很不能理解。其实，若把Java换成任意的词——任何事同时有或易或难的一面。开车简单但驾驶一级方程式赛车却很艰难。
为何会有这种问题呢？研究发现人脑中有某种思维定式。具体而言，这跟不熟悉编程的人问：‘做这件事的最佳方法是什么？’是一码事，事实上没有学习编程语言的最佳方法或唯一方法。如果你学完C++后瞧不起Java开发人员，说明你只是小团体中的佼佼者，就像是你学会了工具箱中的一种工具，会使爪锤却不会大锤。现在学习大锤的确会简单些，但两种工具各有所长。
若工作规格要求会做测试而你却只字未提
编写测试是个加分项，不必力求完美，也不必用100%的代码覆盖。仅仅用些简单测试检验核心功能就会很加分。
没有对代码进行拆分
若你发送一份含2000行代码的大型文件，则很难对其审核。作为代码审核人，很难看出代码要做什么、怎样切换。或许你自己也得从头看起。最好尝试把代码分割成小块，这对后期工作尤为重要，没人想看团队中除了你别人都看不懂的代码，所以务必拆分，这样核查起来要容易得多。
没有代码注释或者仅仅解释一行代码
这个现象甚至是具有多年开发经验的老程序员都有。像下面的注释：
“// Loops through an array”，下一行是“Array.forEach()”。
你好，显然先生！如果你能用更抽象的方式描述这个循环，那就更好了。
写成像形如“// preparing data for sending it via AJAX”的代码以便代码意图更易懂。
代码编写不规范
上述代码晦涩难懂，也反映出你工作马虎。现有的代码检测工具如eslint和prettier功能都很强大。所有大型编辑器和IDE都内置该功能，只需安装一个插件或扩展文件即可，要习惯尽量使用它。
不恰当的变量命名
上述代码变量“b”的含义就很难懂，应该写成下面这样会好一点：
这些仅仅做个示范，每个语言都有自己的命名方式。当然，你可能猜不出它是哪种方式，只需按照自己认定有意义的方式命名，并坚持一种风格。
仅仅对旧代码做注释
虽然这种现象屡见不鲜，还是不懂为何如此。有个100行代码的文件，其中70行旧代码，30行才是真正用于实现的代码。那是要我看旧代码吗？还是要告诉我你第一次写错后面又修改了呢？第一次的代码都不会完美，所以记得删除不必要的代码，需要查看是否重构代码时只需看Git提交说明就能理解代码作用了。
没有检查代码是否更新完毕
这事儿也经常发生，周天晚上审核人从参加面试人员那收到一封邮件。周一工作时审核人开始检查代码，然后突然又收到第二封，面试者声称代码已更新，审核人还得祈祷这封才真正有效。
修改后未检查代码是否更新完毕
对于全栈开发人员而言，工作要求其在数据库中保存变量，他们可以选择数据库、架构以及变量保存方式，但必须保存。这可能导致代码修改后并未检查是否真的保存进数据库中。例如，仅仅修改架构或某个小文件等等都有可能导致类似问题。
在发给代码审核人之前，请检查是否全部功能是否依旧奏效。并不是说需要你掌握每个极端情况，但至少掌握一些普通开发人员需要做到的常识。
对于编程面试毫无准备
在发送编程成果后和正式面试之前这段时间，一般会是一周多一点，你还记得编程里写了些什么吗？比如为何以某种特定方式解决这个任务，认为编程任务还应该怎么改善？
整个过程的目标不仅仅需要看你是个多合格的程序员，更应该是如果你是团队一员的话，是否和团队兼容。相比编程硬实力，其实更看重的是你的软实力，所以务必在面试前仔细阅读自己的代码。
上述误区仅仅是职业生涯中的部分情况，如果你还有不同的误区，请在下方留言区写下你的评论。
—End—
Dtawhale高校群和在职群已成立
扫描下方二维码，添加负责人微信，可申请加入AI学习交流群（一定要备注：入群+学校/公司+方向，例如：入群+浙大+机器学习）
▲长按加群