Introduction

One of the MANY LinkedIn aspects which bugs me is the 'how to interview developers' posts. There's a TON of them and they're in 3 camps:

1. The 'How would you move Mount Fuji?' approach with logic puzzles and brain teasers.
2. The 'Let's see how much you can remember from your Computer Science degree' approach with algorithmic questions.
3. The 'watch you while you write code' approach with coding exercises.

Over the years I've interview dozens of times and hired hundreds of Developers for various companies from Microsoft to Dell to tiny startups. I've also oddly been a Research Psychologist specialising in psychometrics (the science of measuring mental capacities) and a Software Developer. So I've seen the process from every side.

The Problem

Coding is often not a social activity. Sure 'soft skills' are vitally important but they're often orthogonal to the practice of writing code to solve user problems. So how do you interview someone for a job that's mostly about writing code?

Our profession is also rife with impostor syndrome. I've seen it in myself and in many others. It's a real thing. So how do you interview someone who's already feeling like a fraud?

Our profession is rife with the socially awkward (and yes like myself slightly autistic); an interview which is both stressful and requires social interaction while solving coding problems is a recipe for disaster. So how do you interview someone who's socially awkward?

The Solution

First read their resume; don't even talk to them if their resume doesn't make it clear they have experience sufficient for the job you're hiring for. This is not only respectful of their time but also yours.

Second, setting up the interview (or interviews) should be as stress free as possible for the participants. This means:

1. Give adequate notice. Don't spring an interview on someone with 24 hours notice (or worse the same day).
2. Make it clear what the interview format will be, who'll be there and expected outcomes (is it the final, a technical screen etc).
3. READ THE PERSON'S RESUME. I can't stress this enough. If you're interviewing someone you should know their resume inside out. This is not only respectful but it also gives you a chance to ask questions about their experience.
4. Make sure you have the details IN THE MAIL; if it's Teams / Zoom ensure they have the link. If it's in person make sure they know where to go.

The Interview

BE ON TIME; nothing makes a person more anxious than waiting for an interview to start. If you're late you're already starting off on the wrong foot. If they're late give them a few minutes; they likely haven't been in back to back meetings so their setup might be screwy.

Do they seem like someone who would fit with the team in terms of temperament; are they a good fit for the team? This is important; you can have the best coder in the world but if they're a jerk they're not worth it.

One tip I've come up with (after years of Fibonacci sequence questions, reversing arrays, linked lists etc) is.

CODERS LIKE TALKING ABOUT CODE THEY KNOW

This means that if you're doing a technical assessment the person doing the interview needs to be able to talk about the code they're seeing. If it's a framework you don't know (like me interviewing Angular devs) don't worry too much.

So before the interview with enough notice (5 days is generally good) tell them that you'll be asking them to talk about a piece of code they've written. I don't GENERALLY ask for a GitHub link (many people at even senior levels might not have this; I've worked on many projects which are proprietary and can't be shared).

Make it clear you're not asking for a big project / some amazing innovative code. It's just code they can talk about. MANY people have these 'family' things, chances are they haven't been a 365 day streak contributor to a major Open Source project.

You're not hiring based on how much free time someone has

WHY?

So why do I prefer this approach? Why do I think this is a better way to interview developers?

1. It's less stressful. The person being interviewed is talking about something they know. They're not trying to solve a problem they've never seen before; really most of the time when coding you're worried about HOW they write code when they're given time to write it. Most of us aren't whipping up crazy algorithms to do stuff that our framework of choice already does for us.
2. You can gauge whether they're lying about their experience. If they can't talk about a piece of code they've written then they probably didn't write it.
3. You can dig into the code in more natural ways; why they chose that approach versus a different one, why they didn't use a library etc.
4. You're seeing the code THEY want to show you. This is a big one. If you're asking them to write code on the spot you're seeing code they're writing under pressure. If you're asking them to talk about code they've written you're seeing code they've written when they're not under pressure. Again unless your workplace is a basket case most of the time you're not writing code under pressure.

Exceptions to the Rule

So there are exceptions here, super junior coders sometimes need a little coding exercise, but take it slow. Asking them to parse and refactor / fix some huge codebase is just cruel. For them you can ask about basic concepts like loops, conditionals etc (keep it focussed to the job you're hiring for). Patterns? Well I've seen a lot of people who can't name a pattern but can tell you when they've used it. So don't get too hung up on this.

Logic Puzzles? I've never seen the point of these. I've never seen a job where you need to move Mount Fuji. I've never seen a job where you need to know how many golf balls fit in a 747. I've never seen a job where you need to know how many piano tuners there are in New York.

Follow Up

After the interview make sure you follow up with the candidate. If they didn't get the job tell them why (you didn't show me enough oof your experience, you weren't clear when explaining your code etc). This is not only respectful but it also helps them improve for the next interview. If they did get the job make sure they know what to expect next.