How To Excel In a Take-Home Technical Test

TECHNICAL TEST

 

4 MINUTE READ

 

Once a qualified developer has submitted a well-constructed CV that has gotten on the short list, the next stage in the hiring process is often a take-home technical test. As an IT recruitment agency, we typically find around a quarter of all development roles we recruit for require candidates to complete some form of test in order to progress their application.

 

The aim of such tests is to check whether a candidate has the necessary technical skills required to succeed in the position and filter out those who are are not a good fit. While there is some debate on whether or not this is good practice, it is hard for developers to avoid these tests completely unless they have significant open-source contributions to showcase their work. Therefore, it’s important that developers are prepared to take them.

 

When approached in the right way, take-home tests offer a great opportunity for candidates to showcase their skills.

 

In this article, we will review the things employers are hoping to see in a completed submission and what you can do to improve your chances of progressing to the next stage.

 

What employers want to see

 

It is impossible to know in advance what specific questions a company will ask – these will vary according to the demands of each role. But generally speaking, the tests are designed to gauge a developer’s comfort with computer science and see how they can handle problems they will face in the real job.

 

Employers will usually consider the following things when reviewing submissions:

 

Was clear documentation included?

Have some minimal high level documentation to explain the overall architecture, how to build the code, and how to run it (this could take the form of a few lines in a README.md).

If you’re implementing a more complex algorithm, give a short description of what it does. In the real job, you won’t always have to document your code directly, but the aim here is to make the life of the reviewer as easy as possible.

 

Is the code performant?

Answers to problems will often be judged on the basis of their performance. One benefit of the take-home test is that you have plenty of time to think about performance and revise your work. Employers are likely to look favourably on candidates who explain the performance of their code and how they could improve it if needed.

 

Was the code reviewed before submission?

Since code is generally read many more times than it is written, it is important that developers self-review their code before submitting the completed test. Often times, candidates try to solve a problem one way and then change their approach along the way. That’s fine, but it’s important to remember to go back and clean up the code so that it makes the most sense given how you ultimately solved the problem. Failing to do so demonstrates a lack of care.

 

Was the right tool used for each problem?

There’s often multiple correct ways to do something, but you should pick your tools carefully and then use them in the way that best demonstrates their utility. Before selecting tools, refer back to the job specification first. If an employer has specifically mentioned a particular tool in their spec, they probably want to see it used in your submission.

 

Does the code flow logically?

This is hard to define but generally speaking, shorter code is better code. However, this heuristic only works up to a point. You should aim to submit code that is as concise as possible but still gets the job done. Think of the person reviewing your code, will they understand the design in under 30 seconds?

 

Conclusion

 

Ultimately, the question at the forefront of the reviewers mind is likely to be:

 

“Will this candidate improve our productivity or decrease it?”

 

This means that your answer should strike the right balance between good software design, and pragmatism. Produce solid, concise code that gets the job done.

 

 


 

 

Looking for your next IT job? We can help. Quick send your CV today.