Interviewing candidates for a job is tricky. We've got at most a couple of hours to make a decision about whether someone will fit in with the team, is capable of doing the job we need them to do and has aspirations and ambitions that are compatible with Gibe's. Finally we need to give the candidate enough information about Gibe and how we work for them to be confident that this is somewhere they'd like to work. We'd typically have myself, Pete (the managing director) and a senior developer present at different points during the interview. We have a policy where everyone has to vote "Yes" for us to take someone on. Anyone who gets a "Maybe" or a "No" means we won't be offering them the role. We're a pretty small team and taking on the wrong person is too disruptive for us to take any risks.
Sharing Background
The first part of the interview we'd give a background of Gibe, we hope that anyone interviewing will have at least skimmed our website, but it's useful to give a bit of background and describe how we work, the make up of the team and what the day to day of the role consists of and what we're looking for with the role. We try to keep things informal and relaxed, nobody is at their best when they're nervous or stressed. Obviously an interview is a stressful situation so you want to put people at ease as best you can.
The next part we'd ask the candidate to give us a summary of their recent history, what sort of projects they've been working on, how things work at their current company etc. (I'm always fascinated about how other companies work and what we can learn from how they approach their projects) . We like to ask and encourage people to ask questions as they come up throughout the interview. The best interviews we've done have felt more like a discussion than something like a technical grilling etc.
Live coding and technical discussion
As part of the interview we get candidates for a developer role to write some code in the interview. This part of the interview involves using Visual Studio to implement a function that has to perform a given operation. Depending on the experience level of the candidate we pick from a range of different requirements. We can then run a set of pre-built unit tests to check the function does what it's supposed to. All of these require knowledge of just basic concepts, functions, loops, conditions, data structures, arrays etc. We're not testing to see if you know the intricacies of something like the System.IO library. Nor are we setting out to catch people out or pick up little typos or syntax mistakes, we have a set of aims for the coding part of the interview.
Firstly we want to see how they approach problems and how they structure their code. The final goal is to create a shared understanding of a problem so that we have something we can then base some discussion around. We can now drill into alternative ways of solving the problem and the pros and cons of those different approaches, for example, what we might do differently if performance of the function was critical. From here we can move to a more general technical interview, we also both have knowledge of a problem that we can refer to. I find the best technical interviews work when we can discuss a problem and how to solve it and let that discussion develop and having a detailed understanding of the problem helps to kick start that.
Whilst there have been lots of opinions on coding during interviews shared online, and it seems like it's contentious. I think many companies are doing it badly or for the wrong reasons. I've found the coding part of the interview is the single best indicator of whether someone can do the job. Not everyone has public GitHub repos or code they have written that they can share so it's really useful to see some code during the interview. You wouldn't interview a chef without seeing how they cook.
Wrapping up
This is the opportunity for anyone to ask questions that came up during the interview that need answering to be confident that we're a good match. I'll often have a few question marks around a candidate, perhaps whether their ambition is to eventually manage a team, or perhaps they would they rather stay away from becoming a manager and stick to hardcode development. Most people will have some questions about the role, or the company and this is the time to ask them. At this point we need to be trying to satisfy any concerns or questions that stop us from voting "Yes" for someone.
