How I Interview People

No one has the perfect interview technique.

That one true method that finds the diamond in the rough, never fails and always pulls everything you need to know without resorting to ‘impress me’ questions simply does not exist.

A lot of companies think they’ve nailed it, but they haven’t as it’s not something you can nail. But you can create an interview process that provides candidates with enough opportunities to show you their strengths and work through their weaknesses.

And while it’s great to have the opportunity to hire the people you know, and the people you’ve heard about on social media, it’s not always that easy.

Often the best developers are those you’ve never heard of, who might not have targeted social circles to get them their next job through word of mouth or through a lucky introduction.

The following is how I structure an entire interview process from start to finish. It’s not perfect, as above nothing can be, but it does provide candidates enough opportunities to show what they can do and where their strengths really are.

Stage 1 - Telephone Introduction

First thing to state is this part is not an interview, it is simply a hello, allowing the candidate to find out about me, the role and the company, and for me to find out what they’re looking for.

this part is not an interview, it is simply a hello

What are they hoping to get out of the role, do they know what the role consists of, and do they think their experience covers them for it? What’s the culture of the team and what are they interested in bringing to it?

This doesn’t need to take more than 15 minutes, but it’s an invaluable part of the process as we put voices to names and an understanding behind the job advertisement.

To my detriment, I don’t always do this, as it depends on how many applicants we receive and want to bring in for interview. For example in my last role we’d generally receive about 10-20 CVs a week, and want to speak to about 50% of them.

I simply didn’t have the time to do an initial telephone introduction with them all, but I do know this was the wrong decision. I suspect we had more than a handful of applicants who didn’t want to move onto the next stage because they hadn’t spoken to a person from the team beforehand.

applicants who didn’t want to move onto the next stage because they hadn’t spoken to a person from the team

Stage 2 - Programming Tests

The second part of the process is when it starts to get technical. This part is all done online as there are so many tools out there that dragging people into an office to sit in a cold dimly lit room and asking them to work on a PC they are unfamiliar with just isn’t necessary.

I’ve usually used HipChat to conduct this part of the interview as they have guest access in their free plan unlike Slack.

This part is split into two sections, both of which are carried out within the same block of time.

Theory Testing

The first part is a multi-part theory test, covering a range of topics from language syntax, structure and usage to various maths disciplines and software engineering techniques.

The test is structured so that the candidate doesn’t have to complete all of it, only the parts they are strongest in (for example, section 2 might be maths, but they only answer part 1 which is probability). By doing it this way, we’re giving the candidate the opportunity to focus on their strengths, rather than having to complete an obstacle course of questions we’ve plucked out of thin air.

we’re giving the candidate the opportunity to focus on their strengths

As long as they complete the correct number of parts over each section to showcase a range of strengths they can usually complete it easily enough.

This part usually takes about an hour.

Practical Testing

A programming interview without any programming is not a programming interview.

What this programming test focuses on depends on the role the candidate is going for. It could be to write a JavaScript algorithm, fix a broken C++ program or a C# WinForm that needs be finished based on a given specification.

I always try to support multiple methods of development (so offering the test via Visual Studio and Xcode for the C++ one for example) so the candidate can again use tools they are familiar with.

Because, what’s the point of asking a candidate to complete a programming test in VS2015 when all they’ve ever used is Xcode? The majority of their time will be spent looking for the right key combinations to progress.

Usually the candidate will get an existing framework and be asked to develop from that. This gives us the opportunity to provide self validation tests for the application (usually in the form of initially failing unit tests) to give the candidate encouragement as they progress.

Why is a programming element so important in a programming interview? Because they’re going to be programming most of the time day-to-day, and it’s amazing how many people with decent CVs fall over on this stage…

The length of this section depends on the type of programming being done, it’s usually scheduled between 1–3 hours.

Stage 3 - Whiteboard Tests

I use the whiteboard to interview candidates.

I know there is a lot of vitriol around whiteboard use in interviews, but how many times have I had discussions with other developers around a whiteboard that show how much of a part of our role whiteboard work is.

It’s the type of tasks and problems to be solved on a whiteboard that drive the negativity behind it, not the act of using a whiteboard itself.

It just depends on how you use the whiteboard when you’re interviewing someone

Though it’s worth noting that if the candidate want’s to, I’m more than happy for them to do it with paper and pen.

Depending on the role, this stage is often broken down into a few different parts, all of which follow a pretty consistent structure

• It’s the team that does the interviewing. The team are the guys who will work with the applicant day after day, and it’s the team that have the responsibility to deliver a product, so they should have the responsibility to bring on the people they think suit the team the best
• The interviewers get up and stand with the candidate at the whiteboard. There’s nothing worse for a candidate to be stood in-front of 2 or 3 glowering interviewers while they try to work through a problem you’ve just given them
• It’s a two way conversation. No discussion in the history of the world between two developers consists of one developer doing all the work and the others standing there in silence. The interviewers are offering opinions, asking for clarification, pointing out good ideas as they crop up and guiding the candidate away from bad ones
• There is no right answer. While some candidates can go way of base (and it’s the interviewers responsibility to bring them back), if the applicant has managed to discuss, rationalise, iterate and think about a solution, it’s not a problem if they get to the end without a complete answer

The kinds of problems we look at solving with the candidate could be any of the following

• Given the desire to build a specific sub-system (AI, combat, effects etc.) discuss how you would structure that system. This part is looking at data and object ownership, relationships, dependancies and coupling
• What algorithms (not capital-A Algorithms, we’re just talking about logic and behaviour) and data structures would you use to solve a specific problems. Here we’re looking specifically as their use of different data structures, how those data structures are manipulated and used to generate a solution
• Given a piece of (usually small and pretty crap) code, run through a code review based on what you would improve, issues you see and what you might change. Since the majority of code reviews are done digitally away from the compiler, this is a valid use of non-pc based code inspection
• Given some restrictions, design something cool. While this is not focused on the technical aspect of their role, it gives them an opportunity to explore their understanding of the domain in which they want to work, and how that marries up with your expectations

All of these (and more) are used in combination depending on the type of developer I’m looking for. While this part does focus on the whiteboard, it’s focused in a way that developer use whiteboards in their day to day work, and again provides the candidate multiple opportunities to show where their skills are, rather than having to jump through a number of hoops to impress the right person.

While this part does focus on the whiteboard, it’s focused in a way that developers use whiteboards in their day to day work

And that’s it, after that it’s hopefully an offer for the candidate and a start date in the near future.

Interviewing Is Hard

It’s worth noting again, as covered at the beginning the following.

Interviewing is a difficult thing to do, both for the interviewee and also the interviewer, and creating a process that never fails is impossible.

But you can create a process that provides enough options and avenues for a candidate to show you what they can do, and to leave the interview feeling as though they were given all the opportunity possible to highlight the skills they have.