Technical interviews

Technical interviews have drifted far from the realities of building software. We cycled from puzzle solving to timed algorithms, and now AI has eroded whatever usefulness those exercises once had. The result is weak signal and strained conversations that do little to reveal how someone actually works.

After running many loops across different teams, I settled on a simple framework that produces clearer insight and feels more like real collaboration. Candidates consistently describe it as more engaging and more reflective of the work they want to do.

Round 1 – The "Intro" call

This first conversation is usually led by the hiring manager or the person the candidate will report to.

Structure:

• 30 minute call
• Skip the resume walkthrough
• Focus on two questions:
  • What have you built?
  • What do you want to build or do next?

Candidates often drift into long background stories. Your job is to guide them back to these two questions. They give you the clearest view into impact, motivation, and how they think about their work.

Round 2 – The "Technical" deep-dive

This session is structured as a pairing conversation where you take the role of the navigator. You share your screen and work in a real environment using your normal tools. The goal is to observe how the candidate reasons, communicates, and makes decisions under natural conditions.

Depending on the sensitivity of your codebase, you can choose one of two approaches. The structure remains the same in either case:

• 60 minute video pairing session (in person also works)
• You, the interviewer, share your screen
  • Use the same tools and setup you normally use when pairing with your team

Option 1: Code Review

• Select a branch or code change you recently shipped to production
• Clone it and open it in your usual editor
• Give the candidate enough context to understand the change
• Ask them to walk through it and perform a code review

This reveals how they navigate unfamiliar code, how they form a mental model, what they prioritize, and how they articulate concerns or tradeoffs. It avoids artificial puzzles and focuses entirely on real engineering judgment.

Option 2: Debug Session

Recreate a real bug your team recently fixed and walk the candidate through the setup. Keep the environment and tools identical to how you normally debug with your team.

• Prepare a minimal reproduction of the bug
• Share the necessary context so the candidate understands the expected behavior
• Let them explore, ask questions, and drive the debugging process
• Step in only to provide hints or clarify domain specifics

This shows how they explore unknown territory, form and test hypotheses, communicate their thinking, and adjust based on new information. It gives you direct insight into their problem solving under realistic conditions.

Round 3: Culture and Product Mindset

This final step centers on how the candidate thinks about users, teams, and long term product quality.

• 45 minute video call

• Product manager leads, hiring manager or team member shadows

• Ask questions that reveal their approach to product thinking and collaboration:

  • What is your favorite product and why
    • Dig deep on this one
  • How would you improve it and how would you measure that improvement
  • What do you need to be a successful developer
  • What would make you leave this company within your first year?

You are looking for how they think about experience, tradeoffs, and long term quality, as well as whether their values align with how your team works.

Making a Decision

At this stage the team has enough signal to decide. Move forward only if everyone involved can confidently answer yes to all of the following:

• Are you excited to work with them
• If any growth areas were identified, can they be coached within six months
• Should we extend an offer right now before another company does

A no to any of these questions means you should pass.

---

The best interviews feel like real work with real people. Anything else is noise.

– Ismael.