Introduction

One of the MANY things that bug me on LinkedIn is the "how to interview developers" post. There are tons of them, and they almost all fall into three camps:

1. The classic brain-teaser "How would you move Mount Fuji?" style.
2. The "What can you remember from your CS degree?" approach.
3. The "Write code while we watch you" approach.

Over the years I've interviewed dozens of times and hired hundreds of developers for various companies — from Microsoft and Dell to tiny startups. I also had a former life as a research psychologist specializing in psychometrics (the science of measuring mental capacities). So I've seen the process from every side.

The Problem

Writing code is often not a social activity. Sure — soft skills matter. But they're often orthogonal to the actual practice of writing code to solve real 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 countless others. How do you interview someone who already feels like a fraud?

And we are often a socially awkward bunch (myself included). An interview that is both stressful and requires live problem-solving is a recipe for disaster.

So how do you interview someone who's nervous, awkward, or already doubting themselves?

The Solution

First: Read the Resume

Don't even start unless their experience lines up. That respects their time and yours.

Second: Set Up a Stress-Free Interview

Make the process clear and human. That means:

1. Give adequate notice. No same-day interviews.
2. Make the format, participants, and expected outcomes clear.
3. READ THEIR RESUME. If you're interviewing them, you should know it better than they do.
4. Include all joining details clearly. Zoom/Teams link, or directions if in-person.

The Interview

Be on time. Anxiety spikes while waiting. If they're late, give them a few minutes — chances are they're not in back-to-back meetings like you are.

Ask yourself: Would they fit the team temperamentally? A brilliant coder who's a jerk is a net loss.

After years of Fibonacci questions and linked list marathons, I learned one core truth:

Coders love talking about code they know.

That's the secret. And it only works if the interviewer actually understands what's being shown. If you don't know the framework (Angular, React, whatever) — still fine. Focus on structure, clarity, naming, intent.

So — tell them in advance (5 days is fair) that you'll want to discuss code they've written. No pressure. No trick. Just: Show me something you can talk about.

They might not have GitHub – that's ok. A personal or work snippet is fine. The goal isn't to find genius. It's to find ownership.

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

Why This Works

I personally leave coding interviews these days. It makes me MASSIVELY anxious — though I've built hundreds of systems. It's UNNECESSARY.

Here's why this approach is better:

1. It's less stressful. They're talking about familiar code — not panic-writing something under pressure.
2. It reveals truth. If they can't explain code they "wrote", they probably didn't write it.
3. It leads to natural exploration:
   • Why that approach?
   • Why not use a library?
   • What were the constraints?
4. You see code they wrote with time — not while sweating. Unless your workplace is chaos, people don't normally code under panic conditions.

Exceptions to the Rule

Junior candidates may need a small practical test — but keep it humane. Don't make them refactor a 4,000-line legacy file.

Ask about loops, conditions, real-world basics. Keep it tied to the job.

Design patterns? Many people use them daily without knowing the name. Don't get hung up on labels.

Logic puzzles? Never once needed them in real work. Never once seen a real use for knowing how many piano tuners exist in New York.

Follow Up

Whether the candidate gets the role or not — follow up.

If they didn't get it: Explain why. Give them something useful to take away.

If they did get it: Tell them what to expect next. Let them breathe.

Because ultimately:

An interview should reveal ability — not protect ego. It should add value — even when the answer is no.

The Bottom Line

The most accurate interview I've ever found is simple: Let candidates talk about code they're proud of. Because in code, honesty shows. Pressure hides it.

When people leave your interview feeling respected — even when rejected — you've already built something worth joining.