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.
- Don’t make homework take longer than an hour. Don’t make it busy work, make it an interesting but solveable problem, ideally connected to the domain of the job description.
- Give the homework before any serious interviews. Don’t make candidates sit through several interviews, only to be handed homework afterwards.
- Don’t give homework if the candidate can point to projects or open source code they’ve written. The point of homework is to verify a basic level of technical proficiency. If they already have proof, just move on to the real interviewing.
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.
- There isn’t much risk of the candidate performing poorly under pressure - the code is already written.
- The candidate doesn’t have to do extra homework to prepare for the interview.
- The interviewer gets a real look into how code from this candidate will look.
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:
- Tell me about one of the most fun technical challenges you’ve worked on, and how you solved it
- Tell me about your biggest pet peeve regarding coding style
- If you had to learn one new programming language, which one would it be and why?
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.
