Whiteboard coding interviews are fantastic if you want to see a trustworthy, extemporaneous performance of technical problem solving and have a candidate who can show their skills this way. But what about when a great candidate can’t show their skills this way?
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:
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.
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.
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 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.
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.
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:
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 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.
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:
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.
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.
We will be in touch soon to get you started on your collaboration journey.
Cord powers collaboration in