When recruiting new developers, a take-home coding task can be a good way of gauging someone's coding abilities in a more realistic scenario than something like a whiteboard quiz. A well-designed task can allow the interviewer to see not just whether the candidate can solve a problem, but how they structure their solution to a real-world problem, and how well they really understand the language.

There are several simple mistakes I see a lot of candidates make, and they could be easily avoided with a little diligence.

Understand what the code you are writing does.

If you don't know what your code does, don't submit it! If you use a built-in method, or a function from a library, read the docs and learn exactly what that thing does. Think about the following:

1. What does it return exactly? Does it return a promise? What does that resolve to?

2. What are the restrictions of the parameters? Are you using them as defined in the docs, or making assumptions about them?

3. Does it have side-effects?

   1. Does it mutate state?

   2. Does it return a copy of a parameter or the original object?

4. Do you really understand how async/await works?

Format your code consistently.

This is such an easy thing to get right. Untidy code makes you look sloppy. Most editors have built-in formatters and linters or extensions for such, so learn to use them.

Test your code.

Chances are that you will be expected to write tests for your code in your role, so this is a good opportunity to show that you know how to do that well. Tests are also good for showing that you really understand the requirements of your code (see point 1). Definitely don't submit untested code long before the return deadline, that just makes you look lazy.

You don't have to go crazy with the tests, but demonstrate that you know how to write good tests and that you really understand your code.