Engineers, embrace the technical take-home test

take home interviewer

Companies technical hiring processes are completely different. Some use live-coding interviews, others take-home challenges/projects, and some even use both. Over the last few months and having been sat in the candidate seat for the month of March (take a look at my article about my technical interview experience here), I enjoy take-home challenges for a variety of reasons.

To get started with this article, I'm going to bring up a few negative arguments that I've heard on the topic of technical take-home challenges:

  • The candidate can cheat
  • The candidate can copy and paste code and pretend it's their own
  • It takes too long to review all the code
  • You can find other candidates projects on Github/BitBucket or whatever other version control app you may be using
  • The candidate can take however long they want to complete the challenge

Now let me address each of them individually and give you my opinion:

The candidate can cheat

I've spoken to a lot of engineers who think that take-home interviews allow a candidates to cheat. The way I think about it, engineers are sat at their desk all day: googling how to fix things, looking up methods they've forgotten. I'll be the first to admit, I have to look up the syntax for a Javascript FOR loop every single damned time. Since when did Googling and searching the internet become cheating.

Now, if a candidate has blatantly copied huge chunks of code from someone elses work - well then that is cheating. From my experience grading take-home projects, I think it's pretty easy to tell when a candidate has not used their own work in places.

To get to the bottom of this, I always review the take-home project with the candidate - and question each decision made and why they wrote the code like that. Those that have cheated usually can't communicate clearly and explain their thinking/decisions.

The candidate can copy and paste code and pretend it's their own

I kind of touched on this above. But again, just from reading code all day, you can usually spot pretty easily if someone has copied code in their solution. It just won't flow.

Now all of this being said, if the candidate has used a snippet e.g. a regex for breaking up a string - I'm totally ok with this as long as they have left a comment or note stating they used "xyz article" and this particular part of the code isn't theirs.

It takes too long to review all the code

One thing I do not like doing, is conducting live interviews. It takes up precious time in your day, and you usually have to abide by the time picked by the HR team.

Take-homes, because of their nature, can be reviewed at any time which free's up my brain and thinking power. I usually schedule take-home reviews at the end of my days. I think this is actually beneficial to the candidate. It allows me to think about their code, why they made certain decisions and I'm not having to make a rush judgement from any 30 minute live coding session.

The candidate can take however long they want to complete the challenge

Most of the time I've found it beneficial to give a chunk of time to complete take-home interviews. If they are interested in working at your company, they'll usually put their best foot forward and return something to you within 1-5 days time.

If it's god tier talent, then yeah - maybe just don't give them an interview in the first place!

That being said, most candidates are also interviewing other places, have other jobs, families and their own lives to live. I'm not saying give them an infinite amount of time to complete the take-home project, but I think setting 2 weeks for completion is reasonable - especially if your going to give a small project that only takes 2-3 hours.

I believe take-homes overall provide a better environment for candidates, and engineering teams looking to hire engineers. It simulates the real-world, and it takes a little bit of the stress out of the interview - allowing candidates to truly showcase their skills and work. I'm not completely hating on live-coding interviews - but to me, they just don't reflect the real world of a software engineer.

Now this isn't to say take-homes can be a disaster. If executed poorly, your going to have a bad experience. See AngelLists article about this: Engineering teams really need to dial in their processes and questions they ask (see my article about questions I like asking in technical interviews).

Your always going to get the senior engineers who are disgruntled about interviewing. But provide them a good environment, good questions to solve and respect their time. You won't be disappointed giving them a well thought out take-home project.

If you're looking for a take-home project IDE, reach out and I'd be happy to talk more about CoderPad and how we can help. We've been building something that I think you might like 😉