Don't spend $10k on a bootcamp. Try our back-end career path first.
Back home

Coding Interviews - Why you shouldn’t give homework

By Lane Wagner on Nov 18, 2021

A while back I went through the interview process at a company I won’t name here. The first interview was basically just a phone screen, where I was able to chat with my would-be manager about things like compensation range, tech stack, work duties, etc. It went well! The guy was delightful.

I moved on to a second interview, which was a live coding session that lasted 1 hour where I completed two technical problems. That also went well, though live coding isn’t my favorite thing in the world.

After these first two steps, HR reached out to me to inform me that I’d received great reviews from both interviewers and they’d like to move me on to the next step! Then the next line of the email read, “if you can just block out 4 hours of your schedule, we have some take-home code for you to write”.

I politely withdrew from the application process.

Homework signals to candidates that their time is worthless

The purpose of homework is to send the candidate away to work on something so that the interviewer can review it later. It’s strictly less effective in measuring problem-solving skills than working with the candidate directly on a problem, though it saves the interviewer a lot of time.

That said, homework can sometimes be tolerable. I think for junior-level jobs, where there are so many applicants, and many candidates apply without having nearly the technical skills asked for, a maximum of 1 hour of homework can be acceptable as a weeding-out process. Here are the differences between a decent homework situation and what I experienced.

A simple path to your career in back-end development

The pace of's JavaScript, Python and Go courses has been perfect for me. The diverse community in Discord is a blast, and other members are quick to help out with detailed answers and explanations.

- Daniel Gerep from Cassia, Brasil

If you don’t like homework, what do you like?

The goal of both parties in the interview process should be to properly convey or assess the talent and experience of the candidate. Employers don’t want to miss out on great hires, and candidates want to be given a fair share shake.

Preferences are going to change by candidate, but I can tell you what I enjoy most both as an interviewer and an interviewee. Let’s go over all the types of interviews I’ve had in descending order of preference. Keep in mind, it’s often best to mix and match these techniques.

1. The code presentation

This one is great, it’s by far my favorite kind of technical interview approach. The idea is simple, the candidate brings a piece of code that they wrote either at a previous company or on a personal project, and walks the interviewer through the code.

The only problem here is it requires the candidate to have some code that they have permission to share in an interview. Not all candidates will have that, especially more junior developers.

2. The whiteboard

This is probably a controversial opinion, but I actually quite enjoy whiteboarding. I’d much rather work through a technical problem with lines, boxes, and pseudocode than attempt to get syntax right while someone is watching me. Again, maybe it’s just me, but I can usually reason through a problem much better if I’m not required to worry about small implementation details at the same time.

3. The questioning

This one will rarely work on it’s own, but is important to use in tandem with another technique. The idea is to ask probing technical questions to gauge the breadth and depth of a candidate’s experience. There are no problems here to solve, the goal is just to try to learn about the candidate’s skill set. Questions and prompts I often use include:

4. The live coding

We all know what this is. I don’t love live coding, but if you’re going to do it, I think it’s much better to just have the candidate screen share and let them work on their local machine. I’ve had interviews where I had to use weird web app text editors that I’m not used to, and Google even made me write code in a Google doc… that was awful. If you want to see how a candidate performs, let them perform on their home turf.

5. The homework

We already talked about homework so I won’t rehash it all here, but know that it’s at the bottom of my personal list. That said, I understand that a lot of people would put it about live coding, and maybe even some of the other methods.

If you have any other interviewing methods you think I should know about, please share them with me! I’m fascinated by the whole process and am looking for ways to improve my own processes when it comes to finding amazing people to work with.

Learn back-end without spending $10,000+ on a bootcamp

Related Reading