Interviewing: Done Right

When I conduct interviews, I want to see you code. I don’t want to see your code, I want to see you type something from scratch. That means, brand new, as in not something you’ve already done (or copied from somewhere else).

I give the same problem to all the people I interview. It helps me form a baseline and I can easily compare how one person did to another. After all, they solved the same problem. The problem I give has nothing to do with technology stacks. In fact, I usually let the user choose what language they want to do it in, and also how they want to deploy it. My preference is to watch them use some kind of testing framework, but I don’t expect it, nor require it.

I also record the interview. I record it so I can refer to it later when anyone has any questions about the interview. The recordings are also a really great way to coach other people how to do the interview.

The algorithm/problem I give my interviewees is really simple. I mean, it’s drop dead simple. Why make it so simple? For a couple reasons, actually.

  • I don’t want to be there forever.

Totally selfish reason, I know, but if I hated long interviews when I was taking them, you bet I’m going to hate them when I’m giving them. I want it to be short. I shoot for 30 minutes, but if I’m going over an hour there’s a problem. This portion of the interview should only take 15 minutes. Any more than that and a flag goes off in my head.

  • Simple problems can show you a lot about a person.

Does the person take time to do it right, even if the problem is simple? Do they use TDD when they say they’re an avid TDDer? Do they stick to principles like SRP and DIP when they say they know and use all of the SOLID principles? These things come through on simple problems, and are a lot easier to spot.

  • Benchmarking

Simple means there’s no excuse. If I give a simple problem, no one can come back to me and say, “how can you expect me to answer this kind of thing on the fly?” It also lets me take how one person did and compare them to another person. Here I’m not so much concerned about time as I am about technique.

When they finish with the problem I gave them they move onto the second item for the interview, which is a question or set of questions about Object Oriented Principles. I’m not looking for the dictionary definition, either. I want a real life, come up with an example for me on the fly, kind of answer. It let’s me watch the interviewee think. They have a chance to show me that not only can they tell me what the principles are, but do they understand them and can they explain them to me.

Again, the questions are simple for the same reasons that the problem was simple. It should be easy in concept, and thoughtful in reply. I’ve already seen them code, so I should have seen some of these concepts in action, but I need to make sure they know what they’re typing. If you can’t tell someone else what you’re doing, then when you work on a team you won’t be able to explain to your team mates what you’ve implemented, even if it’s good code. Contrary to what most people might think, communication is more important than your coding skills.

However, doing an interview right only get’s us part of the way there. We also need to know how to do is easy.