What most technical interviews are missing

by Xavier Talpe a year ago in Technical Interviews

2 min read

Imagine you're a restaurant owner and you're looking for a new chef. You put out a job advertisement and you receive a number of applications. You're not familiar with any of the candidates nor the restaurants they worked at in the past. How would you validate if a candidate is worthy of being a chef in your restaurant?

During my career I've participated in dozens of technical interviews, the majority of them as a candidate and some of them as an interviewer. As a candidate, every technical interview seemed to be completely different than the others. Questions would range from very specific algorithms and data structures (suffix trees) to common terms in OOP (class vs object), as well as solving Codility exercises (turtle graphics) or running through a variety of Javascript oddities.

While the majority of these questions often sparked some interesting technology debates (and I almost always learned something new), I often felt that these interviews rarely gave a good insight into  my technical skills. A feeling that apparently is quite common amongst programmers.

Fortunately, not all interviews are the same. A couple of years ago I applied for a job as technical lead/architect at a startup. This interview ended up being the most honest, interesting and challenging interview I've ever had.

Before attending the interview, I was asked to bring along my development laptop for some live coding exercises. The interviewer, a senior programmer himself, started the interview by asking me some basic questions about my resume, what projects I worked on... etc. For the technical interview itself, he had prepared a variety of technical challenges I had to solve: from parsing a CSV file to writing a solution for the producer-consumer problem. Unlike past interviewers he didn't ask for a "thinking out loud" solution. Instead, I was asked to write an actual working program on my laptop for every one of the technical challenges he had prepared.

With my laptop hooked up on the big monitor in the room, my interviewer could easily follow along on my journey. Not only could he see the actual code I wrote, he was also able to follow my entire thinking process: from analysis, to design, implementation and even testing. He would also regularly ask questions about why I made certain decisions, how a specific class/method would behave or what I would do different if the use case was slightly different.

What felt so good about this interview was the fact that I was solving real-life problems using real-life tools (a.k.a writing code in an IDE). At the same time it also presented my interviewer with a very honest look at how I work: how I analyzed the problem, the questions I asked, the iterative way in which I built a solution, what I do if I'm stuck, how I write tests and use the debugger...

Seeing people code live gives you an exceptional insight in how a candidate thinks, works and communicates.

Based on my personal experience of interviewing candidates for a position, I can also say it makes hiring decisions so much easier compared to a traditional approach of asking a list of "theoretical" questions.

After all, if you had to hire a chef to work in your restaurant, wouldn't you at least make them cook a meal before deciding to hire them?