Jul 2, 2022

Doing Interviews: The Other Side of the Table

Let’s talk about the interview process

Tech interviews have become legendary—sometimes in the worst possible way. Horror stories abound: brain teasers, whiteboard marathons, and logic puzzles that would stump a panel on University Challenge. And while a lot has been written from the candidate’s perspective, not enough covers what it’s like on the other side of the table.

This article is for managers and interviewers—especially those designing or running the process themselves. We’ll explore what makes interviews effective, efficient, and respectful for everyone involved.

Why do we interview?

At the core, we’re trying to answer a simple question:

Do we want to work with this person?

That breaks down into three main areas:

Technical skill: Can they do the work?
Culture fit: Will they work well with the team?
Role fit: Are they suited to this role, right now?

Our goal as interviewers is to assess those things quickly and fairly—and to make sure that, no matter the outcome, the candidate leaves with a positive impression of our company.

Interview structure: how many is enough?

Some companies run 6–10 interviews. That’s… a lot. At smaller companies or startups—where candidates are often fielding multiple offers—you’ll want to move faster.

I’ve found that a 2–3 stage process works well for most engineering roles:

First interview: Get to know each other and assess culture fit.
Optional take-home test: Used only when we need a better sense of coding ability.
Second interview: Technical deep dive with future peers.

Let’s walk through each of those.

First Interview: Culture Fit + Broad Technical Insight

This is usually the first live interaction—and often when candidates are most nervous. Your number one job here?

Be kind.

No matter the outcome, candidates should leave feeling like your company is a good place to work. That starts with treating them like people—not problems to solve.

What to ask:

Tell me about your current role. What are you working on?
How did you get into tech?
What’s a project you’re proud of? Why?
What’s a project that didn’t go well?
Any open source projects or tools you admire?
What’s the most interesting thing about your current stack?

Let them do the talking. Listen, nudge, absorb.

This interview isn’t about nitpicking. It’s about getting a feel for how they think, what excites them, and whether their motivations align with what your team needs.

What you’re looking for:

Technical insight: Are they thoughtful about how they build things?
Culture fit: Would you enjoy working with them? Would the team?
Role fit: Are they too junior (and need more support than you can provide), or too senior (and likely to get bored)?

At the end, I ask myself a gut-check question:

If I had to pitch this candidate to the CTO, how confident would I feel?

That intuition, paired with evidence from the conversation, usually tells me what I need to know.

Optional: Take-Home Test

We only use this when we need more signal on someone’s technical ability—often with junior candidates, graduates, or those switching stacks.

Instead of puzzles or trick questions, we offer a realistic, open-ended challenge. The candidate gets a basic codebase with some obvious places for improvement: adding features, writing tests, refactoring, improving documentation.

They choose how to approach it.

This gives us a sense of how they think, how they write code, and what they prioritize—without enforcing a one-size-fits-all solution.

Once submitted, the code is reviewed by our engineers via a shared internal mailing list. Reviewers provide written feedback and a simple recommendation: proceed or not.

Importantly, everyone who submits gets feedback. Even those we pass on should walk away with something constructive—and ideally, the sense that they could try again later.

Second Interview: Technical Deep Dive

This one is run by peers—not the hiring manager. It’s where the technical rubber meets the road.

If the candidate completed a take-home test, start by walking through it together. It’s familiar ground and helps settle nerves. Then move on to more involved technical exercises.

Remember: the goal isn’t to trip them up. You’re trying to understand:

How they solve problems
How they communicate while doing it
How they think through tradeoffs

Two options here:

1. Whiteboard

Great for architectural diagrams, system design, or algorithm flow.
Terrible for writing syntactically perfect code.

Use this for:

Designing a chat system from scratch
Sketching out how to track tweet counts in real-time
Walking through tradeoffs in tech choices

Don’t sit and silently judge. Stand with them. Ask questions. Collaborate.

2. Pair Programming

More hands-on? Set up a laptop with their preferred IDE and OS (ask ahead of time), and pair on something simple.

Even better: try fixing a real bug in your codebase.

Watch how they work, how they ask for help, and how they navigate unfamiliar territory. That’s much more valuable than whether they remember how to reverse a binary tree.

Deciding Whether to Hire

After both interviews, we collect feedback using a simple scale:

1 – Definite no: Not a fit.
2 – Marginal no: Some red flags, wouldn’t recommend.
3 – Marginal hire: Not a home run, but worth serious discussion.
4 – Definite hire: No-brainer.

We also ask for written feedback—constructive enough that we’d be comfortable sharing it with the candidate.

Why? Because under some state hiring laws, candidates can request interview notes. If they did, would your feedback help them improve—or just leave them confused?

Important: Be honest with yourself.
If you’re tempted to say yes just to “give them a shot,” but know deep down they’re not right—don’t. It’s much harder to undo a bad hire than it is to decline at the offer stage.

In Summary

Running great interviews takes empathy, structure, and a clear understanding of what success looks like—for the role, the team, and the candidate.

Keep your process short and clear.
Give candidates every opportunity to show who they really are.
Leave them better than you found them.
Stay fair, stay focused, and make decisions you’re proud of.

You won’t get it right every time. But with care and practice, you’ll build a hiring process that respects candidates, supports your team, and brings the right people through the door.

Good luck out there.