Think twice before coding that Take-Home Test

Lots of companies make their developer candidates code example projects or “take-home tests”. On iOS camp, it’s usually a variation of the same silly app: One that consumes a REST endpoint, shows a result on a list, and has a detail-view for each of the results.

The most simple version of this app could be developed by an experienced developer in around 3 hours. Some companies make it more complicated and ask you to add maps, custom UI components, or stuff related to geolocation, Bluetooth, etc. This increases the minimum needed time to about 8 hours of highly specialized work they want to be done for free.

Of course, if you are competing for a position, you do not want this example project to “just work”. Often, the instructions of these take-home projects say “impress us”. To show that you know your stuff, you add Unit Tests, UI Tests, animations, linters, and structure the app using a complex architecture. Hell, sometimes you put more care into those toy projects than in your current job.

So after spending 20 hours on an app that shows the result of an API, like a list of pokemons, temperatures of cities, movies, etc., you send the project with a hopeful smile and wait. Days go by with no word from the recruiter. A week later, you write to the company to confirm if they received your test. The recruiter answers that their development team “is very busy right now”, but they will let you know the result of the process soon.

Some days after, you get a generic email that says they will not proceed with your application. Tough luck, you think, then you apply for another position. They do not even have the first meeting with you. Right away, they send you a PDF via email with a set of instructions for another example project.

Then you think that is kind of weird that some stranger invested 3 minutes sending you an email and automatically put you into rush mode to give 20 hours of work for free. But, ok, c’est la vie, you think. You send the solution and again, days go by with just generic responses. If at least they sent you a detailed technical feedback, that would be good for you to improve professionally.

This happens again and again. You forget what it is to have weekends. Now they are “the days I code for free”. Until you find a company that assesses your skills differently: technical interviews, live coding sessions, or fixing problems of a project they send you. Then you get hired.

That is no coincidence. If a company does not value your time from the beginning, maybe they are not even in such a need to fill the role. Maybe they just want to have you in their database as a potential developer for a project that is still not approved. Maybe the person who checks the test has recommended someone else. Maybe they just ran your app and thought the UI was very simple, without checking all the effort you put in writing a clean and well-architectured code. Maybe your test was excellent, but another developer asked for a lower salary.

There are so many factors you do not know, and can not control, no matter how good your test is. But what you can check from the beginning is how committed the company is to the process. If they send you the test without even having the first call, I would discard that company right away. Just imagine the tenths of developers that have received that same email. Sometimes you can even confirm that by doing a quick search on GitHub and finding lots of repositories of the same example project written by other candidates.

If at least you got the take-home test after an introductory call with the recruiter, I would recommend coding a teaser project and sending it quickly (like in the next 48 hours), letting them know you can not devote more time to it because of your multiple occupations as a rock-star developer. Here, the speed of your response will work in your favor. The idea here is to intrigue them enough to have a technical interview with you. To do that, you can use app mockups, links to your portfolio, descriptive documentation (starting with the Readme file), or comments in the code that explain your decisions and how could they be improved.

On the other hand, If you received the take-home test after the initial contact with the recruiter and also after some interview with a technical leader or a project manager, then you know they invested the time of two of their employees, one of them with technical expertise or important responsibilities, so you can guess they don’t send that take-home test to a lot of candidates. In this case, if the position interests you, maybe investing your weekend coding a polished example project is worth the effort.

I am not saying take-home projects are bad per se, but they should not be the first filter for a technical position. That could give a bad image of the company to the candidates and unnecessarily waste their time.

In conclusion, as a candidate you have limited information, so try to assess carefully when is it worth it to invest your time on a take-home project, when you should ask if they can use other forms of evaluation, and when to just say “Thank you for the opportunity but I will not continue with the process.”