Part of my job is doing recruitment interviews. I do them quite regularly – recently at least once a week. 1337 is growing and we want to hire more developers, and someone needs to interview them from a technical point of view. These days I do roughly one per week, and often get requests for more. It’s getting to the point where I have to say no because I can’t take that much time from my “real” work. But I enjoy them, so I do try to take the time.

We’re a large enough firm to have specialists for the early phases – finding and winnowing out suitable candidates, and having a first interview with them. I’ve never enjoyed that part of the recruitment process so I’m glad that’s already done by the time I get involved.

The second step is a technical interview, and that’s where I come in. The third and final step is a manager interview.

In a tech interview, we spend one to two hours inventorying and mapping the candidate’s skills in a wide range of topics. We don’t usually dig into any one area in great depth, but we probe enough to get a good picture of where the candidate’s skills lie, and find out where there are gaps in their knowledge.

These days we have a comprehensive template document listing all the areas to cover, each one with a set of keywords to help jog our memories. This is a relatively new “tool”. We’ve invested many laborious person-hours in internal workshops to prepare this interview guide, and then to get used to working with it, and now it’s really paying off. I’ve been doing interviews for many years and they’ve never been as focused and well-organized as what I’m doing now.

We always do the tech interviews in pairs, which I really like. Not only is it good to always have a second opinion, but it also makes the interview run better. If I can’t think of a good follow-up question, my colleague is sure to have one.

It’s easy, relatively speaking, to interview a developer who is supposed to be roughly at my own level of experience. I know what I would expect from another senior colleague. Does this person know enough to be able to deliver production-ready code? Do they have enough experience to make architecture decisions? Are they able to consider the bigger picture, the business needs, the trade-offs?

It is much harder to interview a junior developer. Experience and knowledge can be judged more or less objectively. But judging potential is so much harder. How can I know what this person will be able to do in a few years? How much of their lack of knowledge today is due to lack of exposure, and how much is due to lack of initiative?

I’m quite glad that the final decision is not mine.

Despite all the digital tools we have, I always take notes with pen and paper. Nothing beats pen and paper when it comes to quick scribbles and unstructured comments.