Future Proof Your Technical Interviewing Process: The Technical Interview

It’s incredibly important to interview well as you’re building your technical team. Further, interviewing well is hard to do and, like anything, you only get out of it what you put into it. In part 1 of this series, we discussed the phone screen. In this part, we’ll discuss the technical interview.

The Technical Interview

The only way to really know if someone can deliver technically is to give them a problem to solve and watch them solve it. You can do this with simple data structure problems on the whiteboard, test questions on paper, algorithm problems in notepad, real-world problems with some pair programming or puzzle problems with them waving their hands wildly in the air. In a technical interview, you should encourage the candidate to think out loud, because you care more about how they go about solving the problem then actually getting to an answer. You will look for the following things:

• Are they asking questions to solidify vague requirements?
• Are they approaching the problem from a logical angle (even if it’s different from what you had in mind)? Does problem solving come naturally to them?
• Are they making the right use of the features available in whatever sandbox you gave them in which to solve the problem, e.g. making good use of list comprehensions in Python?
• Are they writing good code and pointing out the shortcuts they’re taking due to the medium they’re using, e.g. the whiteboard? Does the coding come naturally to them or are they struggling?
• Do they come up with a reasonable answer? Are they on the right path even if they run out of time?
• Do they understand the “why” behind their answer as well as the “how?”

This last one is the one I tend to focus on the most. Even more important than a candidate having knowledge of the technologies you’re going to ask them to use is their ability to understand new technologies over time.

My father always says that while teenage drivers hopped up on testosterone may get into the most accidents, they’re the ones that push the cars to see what they will do. You want to hire engineers that have pushed technologies past their limits for the pure joy of it. Those are going to be the ones that build the deep knowledge and can adapt in the future to whatever comes their way.

I filter for deep understanding by not just digging into not only the “how” of whatever they claim to know best, but also the “why.” They may know how to build a factory in Angular, but do they understand what a factory is and why Angular does it that way? They may know how to manage their resources in the face of the JVM’s garbage collector, but do they know why we use garbage collection and what the downsides are? Do they understand what canvas is good for, what SVG is good for and when to choose which?

The key here is that past behavior indicates future behavior — if they’re developed deep understanding of the technologies they’ve learned before, chances are pretty good that they’re going to be able to do that for the new technologies your team adopts in the future. There is no better way to understand how well they’re going to do on future technical challenges than hearing how they’ve handled such challenges in the past and seeing how they do it right in front of you.

What’s Next in This Series

However, the technical fit is not the only thing you need to look for — you also want to make sure that they will fit in well on your team and the company culture overall. We’ll talk about these in the next piece in this series.