How to Fix the Coding Interview

Is hard to argue against the perception the hiring process in tech is broken, mostly when a top contributors to widely used open source project was rejected by a company using that same project.

At the core of this dysfunctional process there's the coding interview in its many forms: white boarding, live coding, and peer programming. All of them are equally useless as a way to measure candidate's development skill for one main reason: they set an unrealistic situation that doesn't resembles the actual work environment that candidates will face in their jobs. It is certain that they can measure some other soft-skills such as communication, or receiving feedback. But what they will not tell you is how good that person is as a developer.

In more than 20 years of career I never had to come with a cleaver algorithm for a random problem that someone just threw at me, and explain it to other person in 30 minutes. Maybe I've just been lucky. And regarding coding a hard problem with three people looking over my shoulder (not matter how amicable they are) only happened to me a couple of times, but I was a sysadmin at a bank and I wasn't coding. The toughest if such occasions I can recall I was trying to recover a failing mainframe server and the three guys were my boss, his boss, and THE boss.

However, I will confess a little secret: I have always been shy of coding in front of other people because I used to be a very sloppy typer. That is something I have improved significantly over the years, but I cannot match one million keystrokes without an error mark yet, and therefore I still get nervous when I have to type in a shared screen. So yes, I can think how to recover from a fatal crash on a live production system but cannot type in public. Go figure!

That takes me to the real problem regarding such interviews: how do you actually interprete the outcome of the interview. If the candidate can revert a red-black-red tree does it means that person can solve complex problems or just that has practiced all common algorithmic problems? If the person fails, was it because lack of programming skills or due to poor pressure handling. How can you actually tell and even more importantly, how relevant is that for the position you are hiring for?

What the industry needs is to align the interview with the actual tasks the person will execute. Instead of multiple one-hour interview with 10 or 15 different people, whose names and job titles the candidate cannot possibly remember, making random questions, why not simulate a day in the office? This is how I would do it.

Let's start with a short meeting on which the candidate is introduced to the team and a fictional project. Some context is given. Then the team lead gives more detailed requirements to a small team (two or three) about a micro-service. Here you can evaluate the candidate's abilities to ask questions and clarify requirements, as well as document the tasks on hand. Never underestimate this. I remember hiring a developer because he knew "to read and write" (seriously, that's what I told him).

Then go to a coding session with a peer. Define the approach, and split the tasks (collaborative working). This is a good moment for defining an API, for instance (design skills). Give the person one or two hours for completing the coding, with other team member(s) at hand to clarify any question and possibly also coding on the same problem (for example, coding a test for the interface). That peer(s) could also come back and ask for clarifications, like "what should do the service do in case of X?" or "have you considered this case?". You can make some short breaks, take coffee and allow the person to ask questions, and comment on the work. At the end, the code is reviewed and tested with the peer. The session end with a stand-up meeting with the team at large, including the team-lead, to comment on the task, and any pending issue (for example, how to improve design, testing, etc)

All this process would take half a day, which is the standard for this kind of interview processes, but you will get far more insights about how the person would actually work in a project.

I must confess that as a hiring manager, I never followed this exact model, but intuitively tried to make the interview to look more like a work session, than an exam. After all, you are hiring someone neither for passing tests, nor for winning coding contests, but to be a contributor to your team.