How not to fail the "take home" test

As a senior dev I have done take home tests multiple times and I have also graded them. Every place has their own criteria, so no universal truth exists, however I can give you multiple types of ammo for nailing the task.

In these types of tests you are usually assigned a small engineering task (make a todo list in X technology) to do in usually a week. The aim of this is (and should be!) to see what the candidate thinks about maintainable code. However these types of tasks are long in time which leads to my first tip:

If you have already a project up on github that shows your chops, you can try to convince the recruiter to take a look at that.

Make your work visible

One of the worst things when you grade a test is the ambiguity: is this the candidate's wit? Or is this coming from a smart template?

After the initial working commit (preferably with green unit tests) create a branch which consists your work upon the template.

To give you an example I did this for a company: https://github.com/latobibor/icf-homework/pull/1

They could see that what was my added value.

Less is good, but it should look great

If they want unit test coverage it is OK not to cover every case. That's a lot of work! However writing just a couple of snapshots test for React is no bueno.

So get a decent coverage over a small amount files. Strategically cover parts of the application:

• these are my detailed unit tests for the business logic in this file
• these are exhaustive UI tests for this important UI interaction
• these are a couple of API tests to see actually the data is making to the DB
• ...

And so on. The task is a showcase of your talents.

The same applies to clean coding. Make sure you have some very neat files and do not forget to mention in your answer letter o in the Readme.md.

Communication is - as always - the key

As I have mentioned above, the aim is to see your coding skills, so many limitations of the take home tests are flexible: given you have very solid reasoning.

Therefore it is very important to give a reasonably long disclaimer when you submit your work pointing to strength of your work and giving explanation to its weaknesses. I would say the "softer" side of your explanation should be featured in a reply email while the technical stuff should be in your Readme.md file (link is my own example).

• Never forget to thanks them for the opportunity and the time spent on grading your work.
• The usual take home test is built on a template, so make sure that you help the graders point to the most important source code files.
• Make sure to detail how your take home test can be tried out. (A bit more on this later)
• If you have deviated from their specification give a good reason about it.
• Be upfront about the possible known issues and why you could not fix it - there's a good chance the graders will find it, and it is a sing of a mature developer to make a note about these.
• If possible ask them to give feedback; even if you fail the task you can learn something from it.

With the graders knowing where to look and what to check it is time to introduce another important factor:

Your code should work out of the box

Usually this is how I expect take home tests to behave:

1. I need to run npm i for dependencies
2. And then npm start for the ability to try it
3. Finally npm test for checking the tests written

Now onto the list of what I see as red flags and my reasoning behind them.

It does not run out of the box

This one is obvious, yet I frequently run into this: it just doesn't work.

The fix is to clone your repository in another folder, do a clean install of your dependencies and run your app.

I have to install global packages

Global packages should be needed for very-very specific tasks, like deploying to Firebase.

It is usually a bad engineering practice to rely upon this. Why? It is not documented in the dependencies part of package.json and also not included to package-lock.json which will lead to the "it works on my machine" shrug.

Now imagine that you have to grade take home tests and now you need to install 2-3 global packages per candidate. Come on.

Setup is too long or not documented

So setup is a tell-tale sign that an engineer will take care of the developer experience of their colleague or not.

Having worked in a company with the weak ownership model (i.e. anyone can create a pull-request to anyone's repository) I realized how insanely important is having a well-documented, easy setup. And as such I no longer wish to work with people who I need to nag for their arcane bash_profile.rc configurations.

The key takeaway of my little list is to realize that your take-home test is the holistic showcase of you as engineer, including your coding chops, your ability to communicate and your willingness to do the extra mile for the team.

Good luck with those job interviews! :)