Take home recruitment tasks – the good, the bad and the ugly

I believe that most of us were given a recruitment task at least once in their career. These tasks are meant to show our coding skills, the way how we think and much more. Since I have completed lots of them during my career, I write a few words about this approach of assessing skills.

Take home task types

Coding task

This is the most common type. Usually, you are given very brief specification, high-level overview of the tech stack you are allowed to use and that is it. This is also the most boring type of task 🙂
Some examples of tasks I have seen:

  • Implement some algorithm in Go given the specification.
  • Use Java to access (some specified) Rest API, put the data into DB and expose it over HTTP using REST principles.
  • Implement part of SDK client for our public API.

Algorithmic test

This is the most stressful take home task – usually, you are given a link to a platform that provides a web interface to assess your algorithmic skills. Very often you have to work under time pressure as time is strictly limited. Still, you are allowed to google things and you aren’t judged by any interviewer in real-time – that might help you not being stressed. Usually, you are allowed to use any language of choice and copy-paste solution from your favorite IDE – that’s good enough to feel like in-home 🙂

Personality test

This is a weird one. I was given a test like this twice and have mixed feelings. They try to ask the same questions over and over again to get a better understanding of you as a person. Are you a good fit? Are you a single contributor or team player? Are you calm and docile or impetuous and self-confident?
While extreme results might be a red flag for many employers, I think that it should be validated extensively by an HR person. I have witnessed case when during whole recruitment process engineers didn’t have any soft-skills related discussion and they “ability to interact with others” was judged by looking at the results of that kind of test.

The good

Let’s start with good things. In general, I like the idea of take-home tasks. They allow you to use your environment, do the task whenever you have time and most importantly, it puts off stress out of you. I think that most people do not feel very confident when being observed during doing the interview task. Another great thing is that they allow assessing your skills offline. You do it when you have time and your employer evaluates it when possible. I am sure that I do not need to explain how offline communication is and the same goes for offline recruitment tasks.

The bad


Imagine the situation: you are Java developer applying to three different companies and they want you to do:

  • a Spring Boot based application that fetches something using Github API and exposes it using REST API
  • a Spring Boot based application that parses CSV files and exposes it using REST API
  • a Spring Boot based application that servers library – CRUD for “book” resource.

Did you spot that all of them are almost the same? There are subtle differences but for all of them you need to:

  • configure build tools with dependencies
  • write controllers
  • write common DTOs/exception handlers
  • write tests

This is the common part of almost all recruitment tasks for Java developers. I agree that, for the employer, these things show you the ability to produce good code, however, we might do better. What if employers start accepting tasks that were created for other companies? After all most of these tasks have so poor business logic that it doesn’t matter whether our controller takes Book or Article. The same goes for business logic – if I could write a well-structured code that handles CSV upload then why wouldn’t I be able to produce high quality and well-tested CRUD code?

Algorithmic tests and “write an SDK for our Public API” tasks are doing better here – each of them represent different sets of problems, different (usually rich) domain and challenges you with real problems. Creating a Spring Boot project and configuring Gradle to produce fat-jar isn’t a problem we face every day and doing it tens times doesn’t make you better developer.

Another bad factor to me is that lots of companies have a fixed attitude to what they expect. They might reject you because the requirements were so poorly specified and you handle some cases differently. Some time ago I got such a task – it said I should implement algorithm “X” using language “Y”. Specification with pseudocode was attached.
I spent the whole weekend studying math and the official paper and noting down all differences between spec and then spend a few hours coding solution, however, their specification and official paper describing algorithm “X” was very far away from each other. What I did was:

  • I did think that the company sent me “invalid” spec for a reason trying to challenge me.
  • I implement a solution with regards to the official paper.
  • I noted down all differences with between spec and paper and added why I decided to go with official paper

and yet their response was like “oh yes, we did simplify the algorithm a bit for our needs but the task isn’t following our specification anyway so Sayonara”. Probably, I should just rewrite the attached pseudocode and they would be happy. Lesson learned? Ask if they want exactly what you think and do not be too suspicious. I, as a recruter, would appreciate doing and explaining something different by the candidate. The ability to take a deeper look into the system, have a different perspective (e.g. user perspective) and raise a flag when something looks wrong is a precious skill. Otherwise, we just want to recruit jira-to-java translator in a classic waterfall approach. But that might be just me 😉

The ugly

Time and feedback – these are the biggest problems for me. Lots of companies want you to spend 10 or more hours doing huge tasks. They get bonus points if their feedback is “our developers did review your solution thoroughly but the code isn’t following rules of clean code. Thank you.”. Do I need to mention that spending 15 hours per company is just A LOT of time? People usually apply to a few companies at a time so the time spend doing recruitment tasks multiplies by a lot.

The feedback itself is a topic for a new article. I just do not imagine leaving candidate that spent a few hours trying to get the job without any feedback. How the candidate can grow if we cannot provide constructive feedback on what to improve? Yet, this is still common. Please write about these companies – there are forums, FB groups, glassdoor and more places where you just could describe your experience. Fortunately, this is changing!

Leave a Reply