DEV Community

Eddy Sims
Eddy Sims

Posted on

Take home interview questions. Do they suck?

Scenario #1

You have decided to move onto a new job. You spend a few hours looking for openings and decide to apply for something that look interesting to you. A few days later the company replies to you with an email "Thank you for applying, please answer these take home questions and send us back your solutions in any format".

Scenario #2

Your team is looking to hire someone new, how exciting! You have been asked by the hiring manager to write a take home interview that should take between x and y hours to complete. It shouldn't be too easy, but shouldn't be too hard.

During my career I have experienced both of these, and to me, both sides suck. On one hand you need to find time to sit down and solve the question, and on the other you are trying to determine whether someone is qualified to bring in for an interview based on a single solution.

Who has time for that?

I have heard an incredible range of "how long this should take". In talking to a staff level engineer, I was told a take home interview should be a maximum of 3 hours. I have also heard from others that they've been asked to solve problems with an expected maximum time of 12 hours!

When I think of this, I'm reminded of this graph.

There is a lot of amazing discussions happening in STEM about inclusivity. I think we are moving in the right direction, however there is still a lot of work to be done.

When we ask for 3-12 hours of someones free time, are we really being inclusive?

For me, a privileged male with no children and financial stability, 3 hours of time is not that hard to come by. However, that isn't the case for everyone. What if I was a single parent? Or worked a second job to support my family? Is it fair to still ask me for the same amount of time (and quality) to do a take home interview question?

Are we losing out on good candidates by asking for to much of their free time?

What's the solution?

Just solving the problem isn't enough.

If you aren't supplying test cases, documentation, super clean code you can be given the axe pretty quickly. I was once told that someone didn't qualify for an interview because they sent their answer in a zip file, instead of a GitHub repo.

Story Time

Before my last job I had never written an automated test. Matter of fact, I didn't even know what they were. I was hired and went on to be quite successful in the company, and at the same time learned the importance of testing.

Should I have been hired?

To me, part of hiring a developer should involve nurturing them into a better developer. Filling their weaknesses, teaching them (your companies) best practices and allowing them to bring their own style and skills into the role.

Where is the balance?

I know that there are lots benefits of the take home interview question, I won't argue that. I wonder where the balance is? Are we asking for too much by asking people to do a take home interview question?

Are we losing good candidates due to time restraints, or maybe even our own judgement of what the "correct way" to do something is?

Do take home interview questions just suck in general?

I recently was talking to a co-worker who was hired after doing a take home question that I wrote. We were discussing it as we wanted to make modifications and send it out to possible candidates. Our conversation went something like this:

Them: I found it a little to easy, I knew you were looking for x
Me: Actually we were looking for y...
Them: Oh..

Discussion (3)

robreid profile image
Rob Reid • Edited on

I like to offer people the choice between a challenge they can do at home and one they can do during a face-to-face interview.

In the 8 or so years I’ve been giving people the choice, everyone's opted for the home test.

I think there's a balance to be struck and it should be up to the candidate how to reach that.

dennmart profile image
Dennis Martinez • Edited on

I don't think take-home projects are horrible, but I agree that when handled in the scenarios you mention, they're a pain. In past companies where I helped in the interview process and included a take-home project, I've found a few things that helped.

One thing that I noticed worked well was taking an open-ended task that allowed the candidate to work as little as possible. We'd let them know they did not have to spend more than an hour or two on it because the expectation was for us to evaluate their initial solution and in the second round of the interview they would pair with someone to talk about their work and potentially expand it.

For instance, we gave them access to a REST API and asked them to build something that pulled the data and use React to display specific info. They didn't have to style it or put all sorts of fancy bells and whistles. If they could tackle that well enough, we'd bring them in and spend about an hour pairing with someone to add something else like write unit tests, add styling or pagination, etc. We just wanted to ensure that they knew React, could talk about what they did, and how they collaborated with others. I think it served us really well.

Interviewees should also be direct if they can't or don't want to do take-home projects. In one scenario, someone said they couldn't do any take-home projects for legit reasons. We didn't reject him - instead we offered him the chance to pair directly with someone on the team as part of the interview process.

As long as expectations are clear on both sides, the take-home approach can serve well.

jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

I could tell you what I think about them, but because I prefer to be polite, I would rather invite you to ask the candidates how they feel about it.