Why I Don't Like Take-Home Challenges
If you want to work in tech, there's a chance you will encounter a take-home challenge at some point in your career. A take-home challenge is a project that you will build in your free time. You will be given a list of requirements and a suggested timeframe (2-4 hours) to complete the project and submit your work.
Take-home challenges are meant to assess your familiarity with something: a language, a framework, or a coding domain. A certain level of autonomy is required to complete it successfully. For example, you may be asked to implement a web app with RESTful routing. You may be asked to use a specific framework, library, or API. These requirements will often relate to the company's mission and the job position.
But I have a few reservations about take-home challenges. I personally try to avoid them, as I think there is a lot of unstated overhead. I'll first start with some of the cons of take-home challenges, which reflects why I don't like them. Later I will share some of the pros I have discovered in my conversations with others.
Take-home challenges take more time out of your schedule for a single interview. Challenges will usually have a time limit, however, most candidates spend more than the allotted time. The time limit is rarely enforced, which means that most candidates are spending more time than allotted.
I recently ran a poll to see how many people were taking more than the allotted time:
The results were not surprising, as I've often heard that people spend upwards of 2-3x the amount of allotted time, anywhere between 8 - 16 hours. Meanwhile, others are following the time limit and their work is held to the same standards as those who don't. All of this time spent on take-home challenges is out of your own pocket–which comes at the cost of your job, your other interviews, or your free time. Then there is the time that it takes to wait for a response, and the time it takes to review the take-home challenge with your interviewer. Moreover, if you are interviewing with multiple companies with take-home challenges, that time adds up or could prevent you from accepting other interviews. All of this time adds up!
In the course of this conversation, I did learn about some advantages to a take-home challenge. I'll cover these advantages in the next section.
For some people, a take-home challenge is the best option. Live coding challenges can be overwhelming and some people don't perform well in those exercises. It can also be challenging to take time away from work to schedule a live coding challenge during working hours. And lastly, take-home challenges can be a great alternative for engineers who don't care for data structures and algorithm challenges. To speak to the time it takes to complete a take-home, there are some folks who benefit from not having a time limit. Those who have families or other commitments can plan to work on the challenge over the course of a few days, spending as much time as someone doing it uninterrupted.
If you expect to receive a take-home challenge, it is helpful to be familiar with the framework or language you will be using. To be successful here is to have both a large breadth and medium depth in the code and APIs for the language or framework you're using. If you're looking for more information you can check out The Essential Guide to Take-Home Coding Challenges on freeCodeCamp.
That is the question: are take-home challenges the right choice? I think the best companies are going to be flexible and accommodate a candidate's preference for which style of interviewing they prefer. Between live coding challenges and take-home exercises, neither truly replicates the real conditions of the expected working environment. So why not give the candidate the choice to feel more confident? Personally, I will stick with live coding exercises since those are easier to schedule around my schedule, and take less time overall.
What are your thoughts about take-home challenges? Let me know by responding to this Twitter thread.