Lots of companies send take-home interview assignments to candidates before meeting them on-site. Those are generally small projects that might take a day or two to complete. Usually the candidates receive a description of the problem (or, "requirements") and (sometimes) acceptance criteria. Companies / teams use the submission to get a feel of the candidate's skill level and/or personal style, and the solution is often discussed in the actual interview process.
In the past few months I've been asked to review numerous submissions of a simple take-home test that my company sent to front-end candidates. And here are the mistakes I think people (especially junior developers) should try to avoid:
Copying Someone Else's Solution
You might not believe this is the very top mistake people make. Me neither, until we caught three candidates who just copied someone else's repository and called it a day. (One of them didn't even bother to change the author field in package.json.) I'm sorry the assignment is not a very original one, or it didn't interest you enough - but being dishonest about your work is a big no-no in pretty much every industry.
It's true that many (if not most) developers often use Google or StackOverflow to search for solutions, and that's OK - nobody knows everything after all. However, unless the description of the problem says the company is looking for someone who is really good at googling solutions, please give your genuine effort to code the solution yourself.
Not Reading the Requirements Carefully
The first thing I do when I review a submission is to run it myself and compare the outcome with the requirements. To a surprising degree, most of the submission I've seen doesn't satisfy all the requirements.
At the very least, please read the requirement carefully and follow the instructions. Make a list of things that you need to deliver, and note how each condition should be handled.
Not Asking Any Questions
This is somewhat related to the point above. There is no such thing called a perfect software requirement. Don't jump into coding right away - check your assumptions first. The people who wrote those requirements are people too and they might have their own sets of assumptions.
Don't be afraid to ask questions - if this is your first software developer job, trust me, you will be asking questions all the time whenever someone asks you to create anything.
Ask about edge cases, if you can think of any.
Ask about tools, if the interviewers have any preferences.
Write down your assumptions and ask if they are correct / acceptable.
If you don't think doing the test is the best way to demonstrate your skills, don't be afraid to ask if there are other ways.
Overcomplicating Your Solution
Of course you want to impress the interviewers. Doing the bare minimum of what the requirement document asks is probably not going to make you stand out. (But still, your solution should at least meet all the basic requirements).
It's totally OK if you want to add a few extra features to enhance your solution and show off your skills. However - know that the more code you write, the more mistakes you are going to make!
If a simple solution works, always go with the simple one. In a problem we sent to a candidate, there is this small part of the program that requires checking if a point { x, y } is inside of a up-right rectangle with { width, height }. One of the solutions I looked at, tried to create a class for Point and then wrote over 40 lines of code just trying to solve this small part by using "scalar product of vectors". Does it solve the problem? Yes. Is it better than a one-liner if/else check? Not really.
Oh by the way, don't immediately go OO for everything. I know JavaScript has class now and all the cool kids seems to be using it. But that doesn't mean you should use it for everything.
Skipping Unit Tests
Like it or not, unit testing is an essential part of software development. You probably have seen tons of articles talking about test-driven development now. However one of the most often heard (by me, at least) complaints from junior developers is "writing unit test is slowing them down." or "it feels like a waste of time."
Well, yes, it takes extra time and effort to write good unit tests. But I can guarantee you that it's never a waste of time.
When you work on an assignment, make sure you have good unit tests accompanying your code. This not only helps you discover issues in your code early, but also serves as simple documentation for your solution and your thought process.
Having simple, concise unit tests is a big plus in my books, even if it's not part of the requirements.
Not Linting Your Code
I've seen a couple of solutions, while solving the problem and meeting most of the requirements, riddled with linting issues: unused variables, inconsistent indentations, missing semi-colons (or extra semi-colons, if you prefer "no semis" in JS).
A common misconception is that code is meant to be executed by machines. In reality, code is to be read and understood by humans. Software is ever evolving - everything you write will eventually be read by other developers, or your future self. One way to improve your code's readability is making sure your code is free of clutter and consistent in styling.
When you start working on a JavaScript project, always use a linter. There are many popular (and opinionated) configurations out there (airbnb, standardJS, just to name a few). And now we've got prettier which formats your code automatically. Setting those up probably won't take you more than 10 minutes, just do it, your code will be much pleasing to the eyes of your interviewers.
In Short
I don't think being able to solve the problem is the most most most important part of the interview process. Being a developer is not as easy as it might seem - if you are not passionate about what you craft, you are probably not going to go very far. Please use the assignment as an opportunity not only to prove your skills but also to show that you care.
Top comments (0)