As part of my job, I started getting more involved in the hiring process, and lately I had the chance to review and discuss many coding exercises, which for us are the first screening for technical interviews.

That made me realize how many people, even some of those who are technically skilled, may fail the screening because of their approach.

Here are a few takeaways that might help you face a coding exercise in your next interview, based on my own past mistakes and my experience on the other side of the barricade.

Don't Rush It (unless you are asked to)

Coding exercises are your business card to your potential employers. Even more than your resume: in your CV you talk about what you can do, but in an exercise you have to actually show that.

They are your chance to show your technical skills, but also all the tacit knowledge and best practices you accumulated over your career.

While it's impossible to come up with a general rule about how much time you should spend on your exercise, an always good rule of thumb is to base that on the feedback from the team. (More in the next points).

Regardless of how much time you spent on it, another golden rule is that you should never give the impression you rushed your solution. Unless you have a short deadline, you should take the time to solve the exercise properly, clean up your code, iterate over your solution and find the possible bottlenecks.

You should never just return a "quick and dirty solution" (unless you are asked to), for two reasons:

1. The goal of asking for this kind of coding exercise is in part to filter out people who are not used to code on a daily basis, but you can also show much more than your problem solving or coding skills.
2. If you rush it, the hiring team could get the impression you are not really interested in that position, that you are not willing to make an effort to get it.

Read the Exercise

And I mean read the text of the coding exercise carefully. Devil is in the details, and so is your chance of passing an interview, so you better get those right.

Like any college exam or school test, you need to make sure you understand the questions before you answer them, or understand the problem before you can solve it.

A few tips:

• Check what's the goal of the task, and focus on that.
• Don't over-engineer your solution: if you are asked for a simple digital phone book, don't try to implement a social network or add voice recognition (while it might show some of your skills, one skill in high demand is being able to judge what's relevant for a task and use a reasonable amount of resources for it).
• Not everything can or should be solved with Machine Learning.
• If you are asked for production-level code, make sure to polish your solution before you submit it.
• Add a proper amount of comments: not too much to be needlessly verbose, but you'd better explain the key points (I'll never get tired of stressing how this is important in your everyday work: while your code might seem obvious to you the moment you wrote it, your colleagues and your future self will thank you for those comments in a year).
• Document your classes/methods (rule of thumb: when in doubt thoroughly document the public ones, just pretend you are writing an API).
• If it's not clear from the exercise, ask if there is any constraint about tech stack, platform, OS or build system.

Clarify Requirements (or Make Explicit Assumptions)

You should get an idea from the exercise's description, but when in doubt, you have two ways:

1. Ask your recruiter for clarifications. If you are in touch with the developers team who formulated the exercise, even better, ask them directly, if possible.
2. Make assumptions about the requirements (and document those thoroughly).

The first alternative is a good way to shed light on some questions that could influence the final result and the effort needed: for instance, it's often a good idea to double check the size of the expected input, if your input data is supposed to fit in memory or if you need more complex solutions. If you don't need to worry about some of these things, you can save time or focus on crucial parts.

At the same you should not take this too far: you don't want to ask every nit about the requirements! Besides becoming potentially annoying, you don't want your potential future team to get the idea you are incapable of making the smallest decisions alone.

And so a good compromise could be using a mix of those solutions. Choose a few (maybe 2 or 3 at most) big questions you'd like to clarify, on topics you would normally discuss with your PM/client on a real project (for example, about how what you are writing will be used) and check your understanding of those requirements.

Then for other small things, like (for example) some input formatting issues (unless already specified in the exercise), make assumptions: the important thing is that you document all these assumptions, explaining (ideally in a README you will include in your bundled answer) what you are assuming and why you are making that particular choice.

Clarify Expectations

Make sure that what you think it's expected from you is aligned with what the team actually expects.

Read the exercise and if in doubt check with your recruiter about the deadline, the code quality and the programming language you are using.

War Story
There was this one time, some 12 years ago, I had two phone interviews in the same days. Both asked me to solve a coding exercise, at home. So for the first one, I was given a time limit, but I decided to go for an unnecessarily fancy solution spilling over the allotted time: despite they told me they liked my solution, they also said that staying within the deadline was more important (e.g. I didn't read the exercise's constraints well + didn't clarify the expectations, and I paid the consequences).
Then on the next day I embarked on the exercise for the second interview (at a different company). Remembering what had happened the day before, instead of going for a complicated solution I rushed to a simple one and sent it back within a couple of hours. Of course, this time they were more interested in clean and tested code, and they wouldn't have minded a fancier algorithm 🤦‍♂️
(e.g. again I didn't clarify expectations + rushed it + didn't test it).

Heads up: if you have a chance, check also with the team or with whom will interview you. Sometimes recruiter can make mistakes or can be unaware of some technical constraints.
For instance, if you know a company works mostly with (say) Java, or if the job post or homework test says you need to use Java, don't rely on a recruiter telling you that you can use (say) Python. Trust me, I wasted a couple of good opportunities because of that (but that's a _war story for another time).

Test It (Thoroughly)

Would you deploy code to production without proper tests? If you would, that's a different problem (and we should talk about a different approach). But hopefully you embrace good practices and thoroughly test your code (which doesn't necessarily mean aiming for 100% coverage, but writing adequate tests depending on reach, risk etc.)

Then, take-at-home tasks are just your best chance to show your possible future colleagues and employers that you do care about best practices.
If you are still not convinced, I'll add that testing your code is also your best shot at nailing the coding exercise, making sure that your code behaves as expected and works for any example provided (and ideally a few more).

Caveat: if you have time constraints to produce your solution, obviously you might not be able to test your code thoroughly (or at all). Likewise, if you are explicitly asked to write some throw-away code, a prototype or proof of concept, extensive testing would not be needed or possibly wanted.

A few tips:

• Focus on the most important areas of your code and test those first and more extensively. Then, if you have time, cover more code.
• If you have to validate your inputs, be thorough in testing valid and invalid data, especially edge cases.
• Reason about edge cases and try to cover them all. Then test a few of the common inputs.
• Try to avoid random tests, which might lead to flaky tests.
• If possible, write tests first, even before you start writing code: it will help you clarify requirements and plan how to develop your code.
• First set your tests up to failure: what I mean is, for instance, if you have to check that the result of function F is always positive, initially assert that F(x) is negative, and see the test fail. This will help you double check that you are testing the right code and that the test would detect an error.

Conclusions

And... that's all you need to thrive! Seriously - well, that, and some hard skills (coding, designing, etc..., depending on the role), of course. To some readers these might seem trivial suggestions, maybe even something you'd take for granted when you assign such a test. But truth to be told, you'd be surprised to see the percentage of applicants rejected because of a misunderstanding about the expectations, or for skipping tests altogether.

I myself had to learn these lessons the hard way, when I started seriously interviewing for developer positions. And even more, learning never ends, at each interview (either as interviewer or interviewee) there is something new to be learned.
But in those early days I got burned a few times, and I wish I had had some advice or a way to practice, to avoid wasting many good opportunities.

So, if you are starting your journey into software engineering, or even if you are a more seasoned engineer who is just preparing to go back to interviewing, I hope these few pieces of advice can help you express your true potential.