When recruiting for developers, I start with initial screening by CV and perhaps phone interview, followed by a technical test, and then a face-to-face interview. I often find that people are nervous about interviews, but there’s really no need. By this stage, if I’m spending a significant chunk of time on an interview, it’s because I already think you’re good enough, and it’s more a question of who you are and how you’ll fit in. The single biggest mistake I see in interview preparation is an obsession on technical content, and an inclination to “cram”, as though the interview was an exam; I think a much better way to prepare for an interview is to do whatever it is you do that puts you in the best possible frame of mind to represent your true personality. For me, this happens to be going for a swim and then a soak in a jacuzzi, giving me time and space to relax and gather my thoughts. As an interviewer, I think it’s essential to make sure a candidate is relaxed and comfortable before starting to form an opinion of their suitability; it’s so obvious that a person who is stressed is not at their best and it’s not fair to judge on this alone. I like to open interviewers with ice-breakers, and try to get into a natural conversation flow as quickly as possible to disarm these stress reactions and give the best chance of succeeding.
A nice component of an interview for a technical role can be to include a pair-programming exercise. This is normally either a simple closed-scope TDD kata, or an extension to the candidate’s original technical test solution. Working in a pair is a skill in its own right, and is as much or more about collaboration and communication than about technical know-how. Pairing makes a good exercise because the interviewer can work with the candidate, and explore how they work, while forming rapport and understanding the candidate’s communication style. I like candidates in a pairing exercise to take the lead, and to talk about what they think they should do before doing it. I like to let candidates use their own machine, on the basis they will have set this up beforehand to their liking and be comfortable. I’m trying to give every opportunity for a candidate to relax, be themselves, and make their best case for a place in my team. It should most definitely never be an us/them thing, or about trying to trick or trip someone up!
Something that I see a lot of people worrying about is “being caught out” and not knowing the answer to a question. I actually like every candidate to say “I don’t know” or “I’m not sure” at least once in an interview, because it shows maturity and awareness; if someone clearly doesn’t know an answer but tries to bluff it is an instant failure. I think it’s essential to be open and honest about the current boundaries of knowledge, because that is a keystone for a mindset of learning and improvement. When I see someone who tries to mask a knowledge gap, the odds are this suggests a defensiveness that can be dangerous for a team. I’m not looking for individual superstars who work on pride and status, I’m looking for team players who will both offer and seek help from others when appropriate to get the best result for the team.
I think it’s a massive waste of time to use an interview to ask “trivia questions”, or to test how well someone has memorized specific content, or whether they can act as a human compiler. I’ve seen interviewers ask trivia about things like the inner workings of the language’s garbage collector – because for them personally this was an area of interest where they’d sought a deep level of knowledge. It’s not possible or sensible to try and memorize this kind of thing, partly because there’s so much of it and partly because it’s likely to change. There’s nothing worse than someone who “knows” how something works, and makes all kinds of assumptions based on this, only to find their knowledge was out of date! The more valuable skill by far is to know how to find information when needed. If I have a live programming exercise as part of an interview, it is absolutely always an “open-book” exercise where the candidate has full access to the internet to find answers as they go along. Again, I like to see this in action at least once, because it’s nice to see the skill of finding information in action rather than see someone who is on auto-pilot.
Most of the questions I try to as are deliberately open-ended. I want you to express your opinions on a topic, and to show your understanding of concepts. I’m looking for reasoning, as well as the ability to communicate this to me at an appropriate level. I often conduct developer interviews with a non-developer as well (who clearly identifies himself early on as such!), to make sure the candidate is able to talk at the right level of abstraction for both of us. We will have agreed beforehand that from time to time we will ask for a more/less technical explanation to give the candidate a chance to show their ability to switch communication styles and select appropriate analogies to explain a concept. As an example, I might ask about the differences between a bus or broker style in a message-based architecture and when one might be used over the other – a fairly involved technical topic, where I’m looking for a detailed answer – where my non-technical wingman will interrupt at some stage and ask for a simple introduction to both, to make sure the candidate is able to address both audiences. There should be a mix of appropriate technical questions, and process questions – perhaps I might ask about your preferred way of managing work items, or about collaboration within a team between specialisms.
I’ll often chose at least one topic that is highly subjective, and pitch the counter-argument. Sadly, there is still a lot of senseless dogma in our industry, and I think it’s important that people are able to understand when these things matter and don’t, and to be able to understand and respect alternatives. There is no single “one right way”, and context is really important. I’ll establish which side of a debate the candidate naturally favors, and ask them to explain when the alternative would be better. They should be able to articulate a reasoned explanation, and objectively evaluate the qualities of both approaches. I’m looking for people who are passionate and have opinions, but who are able to frame these with a suitability for the task at hand. Many of the biggest problems I’ve seen in projects come from a person blindly insisting on doing something their way, even though all the evidence suggests another approach would have been objectively better, and compounding the problem by refusing to re-evaluate even as this evidence accumulates!
Another question I make sure is always included it to ask a candidate to talk about something they are excited about. In our industry, this is often an emerging language or framework. I want the candidate to show me that they are passionate about what they do, and that they can spread enthusiasm to others. It doesn’t actually matter what it is that they are excited about; there are no wrong answers except “nothing”. I’ll ask what you’re reading, whether you can recommend some blogs or videos to me, and I do actually normally follow up and make the time to look into these – I’ve got a lot from it! I like to have teams who have a culture of sharing, and of looking proactively for ways to further their knowledge. I love it when a member of the team puts forward an idea that no-one else would have thought of that has come from their interest in the field, and some of the biggest wins on projects can come from these unscripted moments of inspiration.
After an interview, my non-technical wingman and I will discuss how the interview went, and decide whether to make an offer fairly quickly. I work on the basis that a candidate is either a definite, positive yes, or if there are any doubts or reservations it is a no and we keep looking. I always try to give fair feedback either way, because candidates who have come to an interview have given a considerable amount of their time and travelled, and are owed respect and honest treatment as a basic professional courtesy. If you find yourself rejected for a position but aren’t given (fair) feedback, consider yourself lucky – you’ve dodged a bullet! Always remember that recruitment is a 2-way thing; the recruiter doesn’t hold all the aces or have power over you, and it’s as much about you finding the right team and project for yourself as it is about the organization finding the right person to recruit!