为什么把工作带回家_带回家的错误，这将确保别人得到这份工作

为什么把工作带回家

因此，您轻松获得所需的工作(So you easily get the job you want)

Ekrem Aktaş 埃克雷姆·阿克塔斯(EkremAktaş)

Follow 跟随

Sep 14 九月14

Photo by NeONBRAND on Unsplash

NeONBRAND在 Unsplash上 拍摄的照片

Finally, the developer submitted the take-home assignment he worked on all night long, with a sense of pride in achieving the results, and satisfaction stemming from the thought of flawless execution.

最终，开发人员提交了他整夜工作的带回家的任务，对获得结果感到自豪，并出于完美执行的想法而感到满意。

But he did not get the job.

但是他没有得到这份工作。

Do you want to know why he did not get that job?

您是否想知道他为什么没有得到这份工作？

I have reviewed many take-home assignments during my career. And let me tell you: software developers make lots of mistakes in their take-home assignments.

在我的职业生涯中，我已经审查了许多实地任务。 并且让我告诉您：软件开发人员在完成任务时会犯很多错误。

I made a lot of mistakes in my take-home assignments when I looked for jobs in the past as well. That’s how I know some of the mistakes because I couldn’t get the job because of them.

在过去寻找工作时，我在带回家的工作中也犯了很多错误。 我就是这样知道一些错误的，因为我因为这些错误而无法找到工作。

When you avoid these mistakes, your assignment will shine.

当您避免这些错误时，您的作业将会发光。

1.没有得到审查 (1. Not getting it reviewed)

When I review a take-home assignment, I want to assess the best work of the candidate. But the best software is not produced by a single rock star engineer. You achieve the best results with teamwork and collaboration.

当我复习带回家的作业时，我想评估候选人的最佳表现。 但是最好的软件并不是由一个摇滚明星工程师生产的。 通过团队合作和协作，您可以获得最佳结果。

Here’s an unpopular opinion: let others review your code before you submit it. But wait, isn’t this cheating?

这是一个不受欢迎的意见：让其他人在提交代码之前先对其进行检查。 但是等等，这不是作弊吗？

Imagine you are a pastry chef and applied for the job of a well reputable restaurant. HR manager asked you to prepare a cake with carrots and cream in it. What would you do?

假设您是一名糕点厨师，并申请了一家信誉卓著的餐厅。 人力资源经理要求您准备一个蛋糕，里面放胡萝卜和奶油。 你会怎么做？

A. Bake the cake and send it to the restaurant without tasting yourself.B. Bake the cake, taste yourself, then bake a better cake to send to the restaurant.cC Bake the cake, taste with your chef friends, then bake a better cake to send to the restaurant.

A.烘烤蛋糕并将其发送到餐厅而不用品尝自己。 烘烤蛋糕，品尝自己的味道，然后烘烤更好的蛋糕以发送至餐厅。cC烘烤蛋糕，与您的厨师朋友进行品尝，然后烘烤较好的蛋糕以发送至餐厅。

Option A is a mistake. You’d probably either choose the option B or C, which applies to your take-home assignment.

选项A是一个错误。 您可能会选择选项B或C，这适用于您的实地任务。

A piece of code is perfect until it gets reviewed. Therefore, take a break after completing the assignment and come back for a review. Treat the code like someone else wrote it. Does it cover the requirements? How could it be improved? Are there any missing edge cases? Reviewing your code can save yourself from simple and obvious mistakes, such as leaving unused variables around or huge mistakes such as failing to understand the requirements.

一段代码是完善的，直到对其进行审查。 因此，在完成作业后请稍事休息，然后再进行检查。 像别人写的代码一样对待代码。 是否满足要求？ 如何改善？ 有没有遗漏的边缘情况？ 审查代码可以使您免于简单和明显的错误，例如将未使用的变量遗留在周围，或者避免重大的错误(例如不了解需求)。

Don’t hesitate to ask a friend to review your solution before submitting your solution. An external pair of eyes can help you discover issues that you’re too blind to see because you’re also acquainted with them. An external review allows you to get feedback about the first impression of your assignment. Is it readable? Maybe you need to include more description in the README?

在提交您的解决方案之前，请不要犹豫让朋友检查您的解决方案。 一双外在的眼睛可以帮助您发现因盲目相识而看不到的问题。 外部审核可让您获得有关作业第一印象的反馈。 可读吗？ 也许您需要在自述文件中包含更多说明？

Sure it sounds like cheating since you should do an assessment alone. But isn’t it a bit of hypocrisy to praise the importance of code review, but then assess candidates’ performance with unreviewed and time-pressured take-home assignments?

当然，这听起来像作弊，因为您应该单独进行评估。 但是，赞美代码审查的重要性，然后通过未经审查且时间紧迫的带回家作业评估候选人的表现，是否有点虚伪？

I’d even suggest letting the company know that your code was reviewed and acted upon them. You can even mention the things you improved during the code review. Maybe you refactored a React class component to a functional component with your friend’s feedback. Accepting and acting upon reviews is a sign that you strive for code quality, you can handle feedback, and work with others. All of them are essential skills a company is looking for in a sound engineer.

我什至建议让公司知道您的代码已经过审查并已采取措施。 您甚至可以在代码审查期间提及您改进的方面。 也许您可以在朋友的反馈下将React类组件重构为功能组件。 接受评论并根据评论采取行动是您追求代码质量，可以处理反馈并与他人合作的标志。 所有这些都是公司在声音工程师中寻找的基本技能。

2.没有故事 (2. Not having a story about it)

Create a story of your assignment before entering the review interview. Get ready to explain your journey. Let your story contain the approach you take, attempts you made, things you have learned, problems you encountered, and the solutions you came up with to tackle them.

在进入审查面试之前，为您的作业创建一个故事。 准备好解释您的旅程。 让您的故事包含您采取的方法，尝试的方式，已经学到的东西，遇到的问题以及为解决这些问题而提出的解决方案。

But why would you need a story? Two reasons:

但是，为什么需要一个故事？ 两个原因：

1. Nobody writes the code once, commits with the “Initial commit” message, and submits it. Nobody gets it right for the first time. It takes several attempts until you get it right, and numerous polishing attempts until you make it neat.
   没有人编写代码一次，使用“ Initial commit”消息进行提交，然后提交。 没有人第一次得到正确的答案。 您需要进行几次尝试，直到您将其正确放置，然后进行多次抛光，直到您将其整洁。
2. Take-home assignments hide the way you work from the companies, compared to whiteboarding. They see the result, which gives an opinion about what you can achieve, but they do not know how you think. Letting them know how you think and approach the problems allows them to learn more about you.
   与白板相比，外派任务掩盖了您在公司工作的方式。 他们看到了结果，对您可以实现的目标提出了意见，但他们不知道您的想法。 让他们知道您如何思考和解决问题，可以使他们了解更多有关您的信息。

3.不了解您的解决方案 (3. Not understanding your solution)

Reviewers expect candidates to justify the choices made in the solution, data types they’ve chosen, and general knowledge about the internals of the frameworks, libraries, and tools they use in their assignments.

审稿人希望候选人证明在解决方案中所做的选择，他们选择的数据类型以及关于在任务中使用的框架，库和工具的内部的一般知识。

For example, if you’re using Promises in your assignment, get ready to explain how they work under the hood.

例如，如果您在作业中使用Promises，请准备好解释它们在幕后的工作方式。

4.只专注于取得成果 (4. Only focusing on achieving the result)

I remember one of the review interviews I had with a candidate who completed the assignment, but the code could use a refactoring. I asked him: “How would you improve your solution?.

我记得我与完成任务的候选人进行的一次面试，但代码可以使用重构。 我问他：“您将如何改善解决方案？。

And the answer was: “It gives the results you asked for, isn’t that enough?”.

答案是：“它能提供您要求的结果，还不够吗？”。

Sure, completing the requirements of the assignment is essential. But how you get to those results is as much important as getting the results.

当然，完成分配要求至关重要。 但是，如何获得这些结果与获得结果一样重要。

5.过度设计解决方案 (5. Overengineering the solution)

Put yourself in the shoes of a fellow engineer. Do you prefer a neat, clean code that solves a problem or an overengineered solution?

把自己放在同伴工程师的脚下。 您是喜欢整洁，干净的代码来解决问题还是过度设计的解决方案？

One of the most adopted software development principles is K.I.S.S, meaning “Keep It Stupid, Simple”. This applies even more for take-home assignments because the reviewer has very little time to review and evaluate your solution.

KISS是最常用的软件开发原则之一，意思是“保持愚蠢，简单”。 这对于带回家的作业更适用，因为审阅者很少有时间来审阅和评估您的解决方案。

One reason for failing to keep the solution simple is overengineering it to show off how much you know and what you can do. Although it sounds nice to show off your skills, the result is often the contrary because overengineering often comes with additional complexity.

无法使解决方案保持简单的原因之一是对其进行了过度的工程设计，以展示您所了解的知识和可以做什么。 尽管炫耀您的技能听起来不错，但结果往往恰恰相反，因为过度设计常常带来额外的复杂性。

6.对作业的误解 (6. Misunderstanding the assignment)

Are you a genius coder? Great! Your exceptional technical skills are useful only if you use them to solve the correct problem. If you don’t understand what you need to solve in a take-home assignment, the chances of getting the job are quite slim.

您是天才的编码员吗？ 大！ 仅当您使用非凡的技术技能来解决正确的问题时，它们才有用。 如果您不了解家庭作业需要解决的问题，那么获得工作的机会就很小。

Ask for clarification if you have any questions. Asking the right questions can get you one step closer to getting hired, even before starting coding.

如有任何疑问，请澄清。 提出正确的问题，即使在开始编码之前，也可以使您离聘用更近一步。

7.不评估所有可能的解决方案 (7. Not evaluating all possible solutions)

Don’t jump into coding with the first solution that pops in your head.

不要急于采用第一个突然出现的解决方案进行编码。

Take-home assignments often have more than one solution, like any other business problem. There is usually a quick solution, but you may uncover a better solution if you dig deep.

像其他任何业务问题一样，外派任务通常具有不止一种解决方案。 通常有一个快速的解决方案，但是如果您深入研究，可能会发现更好的解决方案。

A useful way of evaluating solutions is to write them down and compare them. Writing them will help you think about each potential aspect of your solutions.

评估解决方案的一种有用方法是将其写下并进行比较。 编写它们将帮助您考虑解决方案的每个潜在方面。

8.缺少或缺少自述文件 (8. Missing or poor README)

The README is the first thing reviewers will look into your solution, probably even before your resume. You can astonish them with a clean, informative README before they see the code.

自述文件是审阅者(甚至可能在您恢复简历之前)会首先查看您的解决方案的内容。 在他们看到代码之前，您可以使用干净，有用的自述文件使他们惊讶。

Imagine you are in a house you’ve never been to before, and you need to live there for a week. Wouldn’t it be nice to have a document that says where you can find the towels or the wi-fi password? How can you appreciate the state-of-the-art coffee machine if you don’t know that it lays down at the kitchen's top shelf?

想象一下，您在一个从未去过的房子里，并且需要在这里住一周。 拥有一个可以在哪里找到毛巾或wi-fi密码的文档不是很好吗？ 如果您不知道它躺在厨房的最上层，您将如何欣赏最先进的咖啡机？

Your fantastic work is only excellent if others can appreciate it. A README is a guide for your project, helping the reviewers to find the state-of-the-art coffee machines. They can still figure out your solution without a README, but it is not a pleasant experience, just like figuring out the house by yourself.

只有别人欣赏，您的出色作品才是出色的。 自述文件是您项目的指南，可帮助审阅者找到最先进的咖啡机。 他们仍然可以在没有README的情况下找到您的解决方案，但这并不是令人愉快的体验，就像您自己弄清楚房子一样。

Explain the following in your README, whenever applicable:

如果适用，在自述文件中说明以下内容：

• The scope and functionality.
  范围和功能。
• Directory structure.
  目录结构。
• Instructions to get it up and running.
  安装和运行说明。
• The solution approach, and a brief story about it.
  解决方案方法，以及有关它的简短故事。
• Difficulties you encountered and how you tackle them.
  您遇到的困难以及如何解决。
• Performance and space requirements of the solution.
  解决方案的性能和空间要求。
• List of dependencies
  依赖项列表
• List of supported browsers/platforms.
  支持的浏览器/平台列表。
• Next steps to improve the solution.
  改善解决方案的后续步骤。

9.保留未使用的文件和依赖项 (9. Leaving unused files and dependencies)

Imagine you want to use React, and you decided to use npx create-react-app project. After running this command, you end up with the following directory structure:

假设您要使用React，而您决定使用npx create-react-app project. 运行此命令后，您将得到以下目录结构：

Contents of node_modules are omitted for clarity.

为了清楚起见，省略了node_modules的内容。

The resulting project contains features such as PWA support. But you probably won’t need it in your solution. In this case, remove them from the template.

生成的项目包含PWA支持等功能。 但是您的解决方案中可能不需要它。 在这种情况下，请将其从模板中删除。

For example, if you are asked not to include any unit tests, there is no need to keep the App.test.js file, thetest script entry in package.json and the whole dependencies added for unit testing.

例如，如果要求您不包含任何单元测试，则无需保留App.test.js文件， test脚本条目在package.json以及添加的整个依赖项以进行单元测试。

10.具有过多的嵌套目录层次结构 (10. Having excessive nested directory hierarchies)

Don’t convert your solution’s directory structure into a maze.

不要将解决方案的目录结构转换为迷宫。

When I review an assignment, I look for the solution’s directory structure right after reading the README. A clean, flat directory hierarchy helps me find out where I should look next.

当我查看作业时，在阅读自述文件后立即寻找解决方案的目录结构。 整洁，平坦的目录层次结构可以帮助我找出下一步的目标。

Having a multi-level nested directory hierarchy makes it harder to reach to the source files. Instead, try to keep the files in your solution in a single, max two-level deep directories.

由于具有多层嵌套目录层次结构，因此很难访问源文件。 相反，请尝试将解决方案中的文件保留在单个最大两级深目录中。

11.不包括单元测试 (11. Not including unit tests)

Unit tests do more than testing. They force you to write modular, testable with separated responsibilities. They let the company know that you can think out of the box with the edge cases.

单元测试比测试更重要。 他们迫使您编写模块化的，可测试的，具有单独职责的模块。 他们让公司知道，您可以开箱即用。

12.不加一点额外的 (12. Not adding a little extra)

Adding a little extra to the assignment can show the company that you’re motivated to join them, and this would help you move ahead of other candidates.

在任务中添加一些额外内容可以向公司表明您有加入这些公司的积极性，这将帮助您超越其他候选人。

For example, do you need to prepare a todo app? You can add a little, pleasant animation when the end-user selects a todo from the todo list. Attention to small details often leaves a good impression.

例如，您需要准备待办事项应用程序吗？ 当最终用户从待办事项列表中选择一个待办事项时，您可以添加一些令人愉快的动画。 注意小细节通常会给人留下良好的印象。

13.添加评论太少或太多 (13. Adding comments either too little or too much)

I’ve seen that developers tend the make the mistake of either not including any comments or commenting aggressively.

我已经看到开发人员倾向于犯错误，要么不包含任何评论，要么积极地评论。

The amount of comments needed depends on the assignment type. For example, if you need to prepare a single-web-page application, commenting on the code may not be necessary. On the other hand, you may need to develop a rather complex solution or algorithm. In this case, commenting out specific parts of the solution can be handy.

所需注释的数量取决于作业类型。 例如，如果您需要准备一个网页应用程序，则可能无需对代码进行注释。 另一方面，您可能需要开发一个相当复杂的解决方案或算法。 在这种情况下，注释掉解决方案的特定部分会很方便。

Comments that justify individual decisions are often well-received. For example, when you use an uncommon data type or a library to achieve the task.

证明个别决定合理的评论通常广为接受。 例如，当您使用不常见的数据类型或库来完成任务时。

Aggressive commenting may indicate a code smell. The need to comment on every line is a sign of hard-to-read code. Consider refactoring the code instead of adding more comments.

激进的注释可能表明代码有异味。 需要在每一行上注释是难以阅读的代码的标志。 考虑重构代码，而不是添加更多注释。

结语 (Wrapping it up)

Here is the summary of what we’ve covered so far:

这是到目前为止我们涵盖的内容的摘要：

1. Understand the assignment’s requirements well. Reach out to the hiring manager if you have any doubts about the scope or functionality.
   很好地了解作业的要求。 如果您对范围或功能有任何疑问，请与招聘经理联系。
2. Evaluate the possible solutions whenever possible. Solving the assignment with the first idea can cause you to find a better one.
   尽可能评估可能的解决方案。 用第一个想法解决任务可以使您找到一个更好的想法。
3. Include a clear and descriptive README in your project.
   在您的项目中包含清晰且描述性的自述文件。
4. Clean any unused code from your project.
   从项目中清除所有未使用的代码。
5. Do not have many nested directories in your assignment.
   您的作业中没有很多嵌套目录。
6. Understand the technical details of your solution. Learn about how libraries, tools, and APIs work underneath. Avoid answering, “It just works” during your review interview.
   了解您的解决方案的技术细节。 了解库，工具和API在下面的工作方式。 在您的面试访谈中，避免回答“这才行”。
7. Create a captivating story of your project. Focus on describing “hows” instead of “results”.
   创建一个迷人的项目故事。 专注于描述“方法”而不是“结果”。
8. Completing the assignment’s requirements is not enough. You also need to ensure that you achieve the results in the best and most optimized way possible.
   仅完成任务要求还不够。 您还需要确保以最佳和最优化的方式获得结果。
9. Don’t overengineer your solutions. Clean, neat, and readable code always wins over technologically advanced, complex, and hard to read code.
   不要过度设计您的解决方案。 干净，整洁且易读的代码始终胜过技术先进，复杂且难以阅读的代码。
10. Write unit tests for your assignment because unit tests lead you to a better solution.
    为您的作业编写单元测试，因为单元测试可以为您提供更好的解决方案。
11. Review your code as if someone else wrote it once you’re done. Also, ask for a friend for review to get feedback about the first impression of your assignment.
    查看您的代码，就像别人写完代码一样。 另外，请朋友进行审查，以获取有关作业第一印象的反馈。
12. Add a little extra to your assignment. It can be a pixel-perfect animation or a “select all” button on a page where you can choose todos.
    在您的作业中添加一些额外的内容。 它可以是像素完美的动画，也可以是页面上的“全选”按钮，您可以在其中选择待办事项。
13. Do not crowd your code with unnecessary comments. Refactor your code instead of adding a long comment to a block of code.
    不要在代码中添加不必要的注释。 重构代码，而不是在代码块中添加较长的注释。

Thanks for reading!

谢谢阅读！

升级编码 (Level Up Coding)

Thanks for being a part of our community! Subscribe to our YouTube channel or join the Skilled.dev coding interview course.

感谢您加入我们的社区！ 订阅我们的YouTube频道或参加Skilled.dev编码面试课程。

翻译自: https://levelup.gitconnected.com/take-home-assignment-mistakes-which-will-guarantee-someone-else-gets-the-job-36bcee1cec1d

为什么把工作带回家