The #1 complaint about coding interviews is that they’re super stressful and bear basically zero resemblance to the actual job.
“Whiteboard” style coding interviews create a high-pressure situation in which the candidate must perform under close observation by someone with the power to decide their fate. They’re supposed to perform feats of reasoning and problem solving – a creative process – while also not making mistakes because those will be counted against them. That’s a contradiction. In fact, this is actually pretty close to what psychologists would call a “double bind”. Research shows that double binds create massive psychological stress. Stress kills creativity. And… like… people.
So coding interviews are bad. Definitely. There’s no question they’re bad for you as the candidate and as a human.
If they’re so bad, why do we keep using them? The answer is simple: they are also really good at getting clear, decisive signal for a bunch of logistics-related reasons.
Here are the things you have to also solve for if you’re going to kill whiteboard coding interviews:
The interview has to be you
Take home tests, for instance, don’t guarantee it’s you. The company can’t tell which candidate got their friend to help them with the take home versus who solved the problems individually. The interview process has to have lots of ways to prove that it’s you doing the work with your own brain. Not you plus your smartphone, googling for StackOverflow answers. Not you plus a bunch of reference material, copying-and-pasting lines until something works. The real you showing what you have in your mind. This is who the company is trying to meet.
The interview has to be timed
If you don’t control for time, you can’t tell which candidate spent 45 minutes on the problem and who spent 3 hours. There’s no way around this. We have to see what the candidate can do when faced with a new problem, in real time. Code samples have the same problem.
The interview has to be solo
Pair-programming is often cited as an alternative to whiteboard coding interviews, but this falls down because you can’t be sure what factors come into play when you add a second person. Especially if that person already knows the shape of the problem. Do the two people speak the same native language? If so, instant boost in interview performance for the candidate. Are they from similar socio-economic backgrounds? Another boost. Are they the same gender? Very likely to hurt the performance of a woman being interviewed by a man because we have such calcified gender roles. What if the interviewer is incredibly senior and the candidate is very junior? How does that impact the dynamics? The problem is simple: if you add another person, you lose the clarity of knowing what the person being interviewed is actually capable of.
For what it’s worth, this is also a negative point against whiteboard interviews. There’s the other person in the room with you and they whatever they contribute directly impacts your performance.
The interview process has to be scalable for the company
The ideal way to tell if someone is a good fit or not is to just hire them, give them some work, and see if they succeed at it. If we could just hire everyone who wants to work for us and only keep the people who do great work, we’d have an amazing team in no time. But that’s not practical. The same is true for complex, multi-part interview processes. Many things that would lead to a better interview experience just aren’t feasible for a company who, after all, isn’t actually in the business of hiring. We’re building collaborative software. That’s our true specialty. So, whatever interview process we do, it’s got to be possible to have a small number of interviewers assess a large number of candidates. The process has to be repeatable as we expand the team and train new interviewers.
The interview process has to be practical for you, the candidate
We could hire much more accurately if we could say, “Hey, just come in and work for a half a day for free on our own problems and with our own team.” We’d get to see the person in the role we’re hiring for, faced with the actual challenges. However, for a huge number of people, that’s just not practical. People have jobs. Kids. Commutes. Dogs. Hobbies. Bills to pay. We can’t practically expect people to perform multiple days of work to prove they’re good enough to join our team. Though they lose many good candidates, whiteboard coding interviews are extremely time efficient.
Can we do even better without losing any of the above?
The problems above are table stakes for replacing coding interviews. But what other problems do we want to solve? Here’s my best stab at this:
The interview process has to be inclusive
This means it has to be something that you can do in the morning or at night. Something you can do whether you have fast internet or slow. It has to work for working moms and for single, male university graduates. It has to work whether you have a short commute or a long one. Maybe you’re at your peak at 7:30 in the morning over the first coffee of the day. Or maybe you’re best at 1am with the lights turned out. Why not give you the chance to work that way? You certainly would be able to work that way as a member of our team, after all.
The interview process has to keep the pressure to an absolute minimum
The biggest problem with whiteboard style coding interviews is that it creates a pressure cooker for you, the candidate. We know this means we get a bunch of false-negatives. People who fail the interview, who are actually good technical problem solvers. So, whatever we do, we have to fix that. I’d argue this means giving you as much of your normal working environment as possible – your computer, your choice of location, your choice of time of day.
Most importantly, I think this means no one actively looking over your shoulder.
So we have to give you the chance to solve a new problem, under time constraints, extemporaneously, but not create an interrogation room vibe.
A Proposal: Vlogging Your Coding Process
So here’s our proposal. Instead of putting you through the standard whiteboard coding interview, what if we asked you to record your screen and your voice while problem solving and then send us a link?
The idea is that we unlock a coding challenge for you on your terms. You tell us when you want to do it and we’ll send you the challenge then. We ask that you work on it right then and there. Recording your screen as you go. Narrate your thoughts as you go. When you’re done, you send us the video. We’ll have an engineer review your work ASAP and advise on whether or not to hire you, exactly the same way that they would if you’d been in a meeting room with them.
Here’s what this looks like in practice:
- You get yourself set up to record your computer screen — not your face
- You get yourself set up to record audio while you code
- Email us when you’re ready to start the challenge
- You start the challenge when you get the link, record your screen and your voice as you work through the problem
- You send us a link to watch the video within 2 hours
- We’ll review it and let you know when we have so you can remove our access to it
- We’ll never keep the video on our end — as soon as we’ve watched it, we’ll delete any cache or temp download on our end. Gone-gone.
On our end, we’ll review your work exactly as we would assess you in a whiteboard coding interview. Most importantly, we won’t keep a copy of the video afterward. After we assess your solution, we’ll purge anything related to the video on our end permanently. It needs to exist just for the assessment and not for one second more.
This is the best we’ve come up with to get the same (and very likely better) signal from you to decide if there’s a good match for our team. We’re actively working on this process. If you have other ideas, we’d love to hear them.
Would you do this?
If you think this is a better approach for you and you’d like to try it, checkout our job listings or email me: jack [at] cord [dot] com. Also, if you absolutely hate this idea or you see that we’re missing something, let us know! We want to kill the coding interview and we’ll keep trying things until we find a way.