编码 面试_您在进行面试的编码任务中可能犯的错误

编码 面试

by Michael Lazarski

迈克尔·拉扎斯基(Michael Lazarski)

您在进行面试的编码任务中可能犯的错误 (Mistakes you’ve probably made in your coding task for a job interview)

You got this task from that company you want to work for! You are hyped and you immediately start to work on it. After a long night of coding, you are done and you think you implemented the best thing ever!

您从您要工作的公司那里获得了这项任务！ 你被炒作了，你立即开始努力。 经过一整夜的编码，您完成了工作，并且认为自己实现了有史以来最好的东西！

So you send the task back to the company. After some time you get an email from that company. You are confident that you aced it and they are sending you a draft of the contract!

因此，您将任务发送回公司。 一段时间后，您会收到该公司的电子邮件。 您有信心已签收，他们正在向您发送合同草案！

Then you read the E-Mail and you can’t believe what you are seeing. It’s just a thank you E-Mail and that they decided to go with someone else.

然后，您阅读了电子邮件，您不敢相信自己所看到的。 只是感谢您的电子邮件，他们决定与其他人一起去。

What went wrong and how could you improve? Let’s dig into it!

出了什么问题，您如何改善？ 让我们深入研究吧！

错误1：您没有足够仔细地阅读任务 (Mistake 1: you did not read the task carefully enough)

Sometimes just one word can change the meaning of the task completely. Perhaps you did not catch the word responsive the first time, or you just think that you got it but you don’t get what the task is really about.

有时，一个字就可以完全改变任务的含义。 也许您第一次没有听到“响应”一词，或者您只是认为自己已经掌握了它，但是却没有得到任务的真正意义。

So read the task a few more times to really understand it.

因此，请多读几次任务才能真正理解它。

错误2：您在未完全了解任务的情况下开始执行任务 (Mistake 2: you started implementing the task without fully understanding the task)

So you have fixed mistake 1 but you’re still having questions? Ask the person you are in contact with. It’s not bad to ask! It’s the opposite as it shows the company that you care about a good product and that you don’t want to waste their time.

因此，您已修正了错误1，但仍有疑问吗？ 询问与您联系的人。 问也不错！ 相反，它向公司表明您在乎优质产品，并且不想浪费时间。

If they react negatively, then I would stay far away from that company because this is the first sign of a toxic environment where nobody can ask anything.

如果他们做出负面React，那么我将远离那家公司，因为这是有毒环境的第一个迹象，没人可以问任何问题。

错误3：您没有使用Git(或任何其他版本控制系统) (Mistake 3: you are not using Git (or any other version control system))

Please! Please! Don’t send a 60 Mb ZIP file via E-Mail with the complete node_modules Folder. OSX does not like to unzip node_modules, so the person who will review your code will not even get a chance to look at your code.

请！ 请！ 不要通过电子邮件发送带有完整的node_modules文件夹的60 Mb ZIP文件。 OSX不喜欢解压缩node_modules，因此查看您代码的人甚至没有机会查看您的代码。

Use Git instead. If you don’t know Git then this is the best chance to learn it because a lot of companies use Git. Sooner or later you will have to learn it.

改用Git。 如果您不了解Git，那么这是学习它的最佳机会，因为许多公司都在使用Git。 迟早您将必须学习它。

错误4：您编写的提交信息不好 (Mistake 4: you didn’t write good commit messages)

You are now using Git, good. Don’t do everything in one commit. Companies will look at your git log to read the commit messages. You have to remember you will work in a team, and in a team good commit messages matter. It’s important for the other team members, and for you in 2 weeks when you have to find a commit or understand what happened in that part of the application. So commit often and write good short messages.

您现在正在使用Git，很好。 不要一次提交就做所有事情。 公司将查看您的git log以读取提交消息。 您必须记住您将在团队中工作，在团队中，良好的提交信息很重要。 这对于其他团队成员以及您在两周之内必须找到提交或了解应用程序那部分内容的情况而言非常重要。 因此，请经常提交并撰写简短的短信。

错误5：您忘记了.gitignore文件 (Mistake 5: you forgot the .gitignore file)

This comes back to mistake number 3. If you don’t have a .gitignore file everything in that directory will be added to Git. So again you will send the complete insides of your node_moudes. Nobody wants your node_modules.

回到错误编号3。如果您没有.gitignore文件，则该目录中的所有内容都将添加到Git中。 因此，您将再次发送node_moudes的完整内部node_moudes 。 没有人想要您的node_modules 。

Here is a good collection of gitignore files: https://github.com/github/gitignore

这是一个很好的gitignore文件集合： https : //github.com/github/gitignore

错误5：您正在通过电子邮件发送Zip文件 (Mistake 5: you are sending a Zip file via E-Mail)

I mean as a developer you have to know GitHub, right? So use it! Put your code on GitHub and send the GitHub link to your contact person. Your contact person will be very thankful for that.

我的意思是作为开发人员，您必须了解GitHub，对吗？ 所以用吧！ 将您的代码放在GitHub上，并将GitHub链接发送给您的联系人。 您的联系人对此将非常感谢。

• No corporate spam filter will remove the zip file.
  公司垃圾邮件过滤器不会删除该zip文件。
• Yes even in 2019 E-Mail’s have a file size limit and you may be just hit that limit
  是的，即使在2019年，电子邮件也有文件大小限制，您可能会遇到这个限制
• It is easier to have a first look at the code without downloading a zip file.
  不用下载zip文件就更容易先看一下代码。
• It is easier to share with other developers in the company. Usually, more than one developer will look at your code.
  与公司中的其他开发人员共享更容易。 通常，不止一个开发人员会查看您的代码。

错误6：您没有README.md文件，或者它不好 (Mistake 6: you don’t have a README.md file or it is not good)

Github will render the README.md file and it will be shown on the main page of your repo. Write some meaningful content in it. For example, the task name or explain what this task does, maybe add the dependencies…and this brings me to my next point.

Github将呈现README.md文件，该文件将显示在您的仓库的主页上。 在其中写一些有意义的内容。 例如，任务名称或解释该任务的功能，也许添加依赖项……这将使我进入下一步。

错误7：您未编写有关如何开始任务的说明 (Mistake 7: you didn’t write instructions on how to start your task)

Yes, I can go the package.json file and have a look at your scripts and if they are meaningful I can figure out which of them is the right one to do or maybe not. So please write down in the README.md how to set up and start your task so I can run it.

是的，我可以去package.json文件，看看您的脚本，如果它们有意义，我可以弄清楚哪些脚本是正确的，也许不是正确的。 因此，请在README.md中写下如何设置和启动任务，以便我可以运行它。

错误8：您未包含指向任务的有效链接 (Mistake 8: you did not include a working link to your task)

“But why should I do that when you just told me that I should write instructions on how to run it?” is what you are asking yourself right now. To make reviewing your task as frictionless as it can be, so the reviewer is not annoyed that they had to figure out for one hour how to see if your code is actually doing what was mentioned in the task.

“但是当您告诉我应该编写有关如何运行它的说明时，我为什么要这样做呢？” 是您现在要问自己的问题。 为了使您的任务尽可能轻松地进行审阅，因此审阅者不必烦恼他们必须花一小时的时间来弄清楚如何查看您的代码是否实际上正在执行任务中提到的内容。

Put a working version anywhere on the internet where you can give the reviewer a link. Heroku, GitHub pages, AWS or Azure are just a few which also have free services for doing that.

将工作版本放在Internet上的任何位置，您可以为审阅者提供链接。 Heroku，GitHub页面，AWS或Azure只是其中的一部分，它们也提供免费的服务。

错误9：不从任务中删除旧文件/不需要的文件 (Mistake 9: not removing old/unneeded files from the task)

Don’t be that developer that has an _old folder somewhere in the git repository. As a reviewer of your code. What should I do with this folder? Should I look into it or maybe don't? Why is it there? I don't even know what to say. So please remove all unneeded and old files from your code.

不要在git仓库中某个地方拥有_old文件夹的开发人员。 作为代码的审阅者。 我应该怎么用这个文件夹？ 我应该调查一下还是不要？ 为什么在那儿？ 我什至不知道该说些什么。 因此，请从代码中删除所有不需要的文件和旧文件。

错误10：您没有编写带有指向GitHub存储库链接的漂亮电子邮件 (Mistake 10: you didn’t write a nice E-Mail with the link to your GitHub repo)

Don’t just send an empty E-Mail with a link. This can be viewed as very rude. I mean on the other side is also sitting someone human. Write at least: Hello X, how are you? I hope everything is fine. Here is the link to my finished task [THE LINK]. Have a nice day. Best wishes, Michael.

不要只发送带有链接的空电子邮件。 这可以被视为非常不礼貌。 我的意思是在另一边也坐着一个人。 至少写：你好X，你好吗？ 我希望一切都好。 这是我完成的任务的链接[THE LINK]。 祝你今天愉快。 麦克，祝你好运。

错误11：不要说容易 (Mistake 11: Don’t say something is easy)

“Javascript is easy and not hard”. I don’t know why people say this but it is a common thing. You can replace Javascript with anything you want. Everything is easy and also hard at the same time. Driving a car is easy but driving a Formula 1 car is hard.

“ Java语言简单易行”。 我不知道为什么人们这么说，但这是平常的事。 您可以将Javascript替换为所需的任何内容。 一切都很容易，同时也很困难。 驾驶汽车很容易，但是驾驶一级方程式赛车却很难。

Why does this matter? It shows the interviewer that there is some kind of elitism in your mind. What do I mean by that? It’s the same thing when people who are new to programming are asking: “What is the best way to do XYZ?”. There is neither the best way or one way. There is not such a thing as the best programming language to use or to learn.

为什么这么重要？ 它向面试官表明，您的心中有某种精英主义。 那是什么意思 当刚接触编程的人问：“做XYZ的最佳方法是什么？”时，这是同一回事。 没有最好的方法，也没有一种方法。 没有最好的编程语言可供使用或学习。

So if you learned C++ you now look down on Javascript developers, that shows that you feel like you are in some elite squad. It just means that you learned one tool from your toolbelt. You now can use the Claw Hammer but not the Sledgehammer. Yes, it will be easier to now learn the Sledgehammer but both hammers have their own pros and cons.

因此，如果您学习了C ++，现在就开始看不起Javascript开发人员，这表明您感觉自己像是位精英人士。 这只是意味着您从工具带中学到了一种工具。 现在，您可以使用羊角锤，但不能使用大锤。 是的，现在学习大锤会更容易，但是两种锤子都有其优缺点。

So please don’t say that things are easy. Most probably they seem easy because you don’t fully understand them.

因此，请不要说事情很简单。 它们很可能看起来很简单，因为您不完全理解它们。

错误12：如果工作规格说明您必须知道如何进行测试，则不必编写测试 (Mistake 12: you don’t write tests if the job specs say you have to know how to test)

It’s always a plus to show that you can write tests. They don’t have to be perfect. You don’t have to have 100% code coverage. Just write some simple tests that are testing your core functionality and you probably have a big plus point.

表明您可以编写测试始终是一个加号。 他们不一定是完美的。 您不必具有100％的代码覆盖率。 只需编写一些简单的测试来测试您的核心功能，那么您可能会有很大的收获。

错误13：未将代码拆分为较小的文件 (Mistake 13: not splitting your code into smaller files)

If you send one big file with 2000 lines of code it is hard to review that.As someone who has to check your code, it is hard to see what is happening in this file and how the code flows. Probably you also have to scroll from top to bottom. Better try to split your code into smaller files. This will also be important later for work. Nobody wants code that only you understand but none of your team members. Please split it up. It’s so much easier to review.

如果您发送一个包含2000行代码的大文件，则很难对其进行审查。作为必须检查您的代码的人，很难看到此文件中发生了什么以及代码如何流动。 可能还需要从上到下滚动。 最好尝试将代码拆分为较小的文件。 这对于以后的工作也很重要。 没有人想要只有您能理解的代码，而没有您的团队成员。 请分开。 审查起来非常容易。

错误14：您没有代码注释，或者只写下一行的内容 (Mistake 14: you don’t have code comments or you just write what the next line does)

This one I see people do even after some years of working as a developer. Comments like: // Loops through an array and the next line is Array.forEach(). Yeah hello, Captain Obvious. It would be better if you would describe what this loop does in a more abstract way. // preparing data for sending it via AJAX or something in this direction. So people know what the intent of the code is.

我看到人们甚至在作为开发人员工作了几年后仍会这样做。 像这样的注释： // Loops through an array ，下一行是Array.forEach() 。 是的，Obvious上尉 如果您以更抽象的方式描述此循环的作用，那将更好。 // preparing data for sending it via AJAX或其他方向发送。 因此人们知道了代码的意图。

错误15：您的代码无处不在 (Mistake 15: your code is all over the place)

const array = [ 1, 2];

array.forEach((a ) =>{ a = a+ 1;

console.log(a) ; });

This is really hard to read and also shows that you are working very carelessly. Today we have tools like eslint and prettier. Every bigger editor and IDE has this build in or you just need to install a plugin/extension. So please use it.

这真的很难看，也表明您工作很粗心。 今天，我们有一样的工具eslint和prettier 。 每个更大的编辑器和IDE都内置了此版本，或者您只需要安装插件/扩展即可。 因此，请使用它。

错误16：您没有正确命名变量 (Mistake 16: you are not naming your variables properly)

const b = true;const a = [];

This is not easy to read and not helpful to understand what b is.Way better naming could be:

这不容易阅读，也无助于理解b是什么。更好的命名方式可能是：

const isReady = true;const listOfPersons = [];

Again these are just examples and every team will have its own way of naming things. Of course, you can not guess that style, but just do what you feel is a meaningful name and stick to one style.

同样，这些只是示例，每个团队都有自己的命名方式。 当然，您无法猜测该样式，而只是做一个您觉得有意义的名称并坚持一种样式即可。

错误17：您只是在注释掉旧代码 (Mistake 17: you are just commenting out old code)

I have seen this often and I still don’t understand why people are doing this. You have a file with 100 lines of code and 70 lines are just old code which is commented out and 30 lines of an actual implementation.

我经常看到这种情况，但我仍然不明白为什么人们这样做。 您有一个包含100行代码的文件，而70行只是被注释掉的旧代码和30行实际实现的文件。

Should I read the old code? Should this show me that you did it the first time wrong and then reimplemented it? Nobody is perfect and writes the first time the perfect code. So please delete this code. If I want to see if you refactored the code I should see it in the git commits with git commit messages where I can understand what you did.

我应该阅读旧代码吗？ 这是否应该告诉我您第一次做错了，然后重新实现了？ 没有人是完美的，并且第一次编写了完美的代码。 因此，请删除此代码。 如果我想看看你是否重构了代码，我应该在git commit中看到它，上面有git commit消息，我可以理解你的所作所为。

错误18：您没有检查代码是否仍在运行 (Mistake 18: you did not check if your code is still running)

This happens all the time. You get one E-Mail from an interviewee on Sunday evening. You go to work on Monday and start to check the code and suddenly you get a second E-Mail with some updates in the code. You also get a promise that this time it really works.

这事儿常常发生。 您在星期日晚上从受访者那里收到一封电子邮件。 您星期一开始工作，开始检查代码，然后突然收到第二封电子邮件，其中包含一些更新。 您还可以保证这次确实有效。

So please, before you send your code. Stop the program, clean the cache, install the dependencies and start it again. If it then still works then you can say that you’re ready.

因此，请在发送代码之前。 停止程序，清理缓存，安装依赖项，然后重新启动。 如果仍然有效，则可以说您已准备就绪。

错误19：您更改了某些内容，但没有检查它是否仍在运行 (Mistake 19: you changed something and did not check if it is still running)

For our full-stack developers, we have a task where they need to save variables in a database. They can choose the database, the schema and how to save the variables. We just say this has to be saved. This is where people change the code and don’t check if after the changes it still really saves to the database. For example, they change the schema or they just try it with a small file, etc.

对于我们的全栈开发人员，我们有一项任务，他们需要在数据库中保存变量。 他们可以选择数据库，架构以及如何保存变量。 我们只是说这必须保存。 人们在这里更改代码，并且不检查更改后是否仍将其真正保存到数据库中。 例如，他们更改架构，或者只是尝试使用一个小文件，等等。

Again before you send your task back, check if all functions are still working as they should and try to break stuff. Nobody is saying that you need to catch every edge case but at least the most common things a user can do.

再次，在将任务发送回之前，请检查所有功能是否仍按预期运行，并尝试中断工作。 没有人说您需要抓住每一个极端情况，但至少需要抓住用户可以做的最普通的事情。

错误20：您没有为编码面试做准备 (Mistake 20: you did not prepare for the coding interview)

Some time has passed between sending the task and the actual interview, maybe a week or more. Do you really still remember what you have done in that task? Like why did you solve this task in that way and what was your thinking when you implemented your task?

在发送任务和进行实际采访之间已经过了一段时间，可能是一周或更长时间。 您真的还记得您在该任务中做了什么吗？ 就像您为什么以这种方式解决此任务，以及执行任务时的想法是什么？

One of the goals of this entire process is not to see how good you are as a programmer but whether you fit the team and if you a team player. It’s more about your soft skills than your coding skills. Please read your own code before you go to the interview part.

整个过程的目标之一不是看您作为一名程序员的水平如何，而是看您是否适合团队以及是否是团队成员。 与您的软技能有关，而不是与编码技能有关。 在进入面试部分之前，请先阅读自己的代码。

These are just a few examples I have seen. Do you have more? Comment down below!

这些只是我所看到的几个例子。 还有吗 在下方留言！

Maybe you want me to review your code? Or give you some tips on how to help you? Just contact me on any of my social media accounts and I can try to help you. Of course, I can not do the task for you but I can help with everything else!

也许您想让我查看您的代码？ 或给您一些有关如何帮助您的提示？ 只要通过我的任何社交媒体帐户与我联系，我便可以为您提供帮助。 当然，我不能为您完成任务，但是我可以为您提供其他帮助！

Thanks for reading!

谢谢阅读！

Say Hello! Instagram | Twitter | LinkedIn | dev.to

问好！ Instagram | 推特 | 领英 开发到

翻译自: https://www.freecodecamp.org/news/mistakes-youve-probably-made-in-your-coding-task-for-a-job-interview-28e6db6a68ad/

编码 面试