Coder Interviews Shouldn’t Be Painful

It’s commonly agreed that engineering interviews are broken, and yet they never change. Why are they broken and how can they be fixed?

The standard software engineering interview often includes the following:

• Solve some “algorithmic” question on a whiteboard or in CoderPad.
• Answer trivia questions about the technologies they are expected to work with.
• Describe a bug and how it was fixed.

We do these because they supposedly tell us something about the candidate we’re interviewing. They’re supposed to tell us if the candidate is “capable” or “incapable”.

Algorithmic questions as simple as FizzBuzz are supposed to tell us whether a candidate can “even code”or not. This may seem fair since the interviewer can code it standing on their head but it instead filters out people who have either never read about it or never needed to use the modulus operator (I honestly can’t remember the last time I shipped code that used it). The candidates that are good at algorithmic questions are those that like doing them, but those candidates may not be good at implementing a UI, or a scalable API layer.

You can try asking domain-specific knowledge questions like “What’s the DOM?” or “What’s the difference between a thread and a process?”. Again, this just tests whether they know this one specific thing. You may think that if the candidate doesn’t know what “the DOM” is, then they cannot be an effective front-end engineer, even if they’ve shipped multiple web apps. If you encountered a co-worker that didn’t know what “the DOM” was, would you try to get them fired, or would you just tell them and move on?

I like to call this style of interviewing “trivia testing”. We think that these questions determine whether an engineer is good enough, but they instead test things that are almost totally orthogonal to what is required to do the job. If Ken Jennings was asked this question on the first episode of Jeopardy that he appeared on, he wouldn’t have had the record breaking run that he did. How could such a smart person not know the right answer?!

This is practice is bad for a couple reasons:

• Higher rate of rejections than necessary — You’re passing on good candidates and don’t even know it! You totally miss out on candidates with lots of potential and just need a little guidance.
• Slows the hiring process — You’re losing out to companies that are either quicker or who started interviewing the candidate earlier.
• Prejudices against candidates — Not everyone happens to have the exact same educational/work background as you. This leads to a monoculture and lack of diversity (note: diversity is good!).
• It’s painful, for everyone — These types of questions are at best boring and at worst embarrassing. They’re a waste of everyone’s time, especially the candidate who needs to “study” this stuff to get a job.

We keep the practice going because it’s what we went through, which makes it not much different from a hazing process.

Is there an alternative though?

The research shows that we’re better off just chatting with a candidate for a short period of time. Ask about stuff they’ve done, anything, it doesn’t have to be a bug.

For example:

Oh, I see you worked at Cyberdyne, what was that like?

What did you code last week? Was it fun? No? Why not? What would you rather do?

I see you made a project using Google Maps. Was it hard?

What technology do you want to work on but haven’t had a chance yet and why?

Oh, I see you’ve just learned GraphQL? What do you think of it?

Find the candidate’s passions. People tend to be good at the things they’re passionate about. The candidate is likely to be a good fit if they’re passionate about solving the same types of problems that your team is working on.

By just chatting you’re also discovering whether you can talk to this person. The candidate won’t be successful if they can’t communicate effectively with you and the rest of the team, and chatting is the easiest and most pleasant way to judge that. Humans tend to be very comfortable with chatting, even introverts (when talking about stuff they’re interested in).

This simpler form of interviewing will also give you a leg up on the competition. I’ve had engineers I’ve hired this way tell me that it was the primary reason they went with my company’s offer. And for the record, I’ve had no regrets on these hires either!

I see no reason why interviewing in software engineering needs to be so much more painful than any other profession. When lawyers and accountants are interviewed it usually consists of a few conversations, often centered around the resumé, why should we be any different?