Running a technical interview well is harder than it looks, and most hiring managers figure that out the expensive way – after a candidate who aced every round turns out to struggle once the work gets messy and real. The problem usually isn’t a lack of effort. It’s that the developer interview questions being asked haven’t kept pace with how engineering work actually happens now, so the interview ends up measuring something close to, but not quite, the job itself.

This is a practical rundown of the questions worth asking, organized by what each one is actually trying to reveal.

Start With What You’re Actually Trying to Measure

Before writing a single question, it helps to separate the interview into distinct layers, because each one tests something different:

• Technical fundamentals – does the candidate genuinely understand the concepts they claim to know?
• Real-world problem-solving – can they apply that knowledge to messy, underspecified situations?
• System design judgment – can they reason about tradeoffs at a level appropriate to the role’s seniority?
• Collaboration and communication – can they explain their thinking, take feedback, and work well with others?
• Judgment around AI-assisted work – can they use modern tools effectively without losing the ability to reason independently?

A technical interview that only tests the first layer misses most of what actually predicts success on the job. If your evaluation process needs a broader rework beyond just the interview itself, our post on how to evaluate a software developer beyond their resume covers the wider picture, including portfolio review and paid trial projects.

Technical Fundamentals: Questions That Still Matter

Data structures, algorithms, and language-specific knowledge haven’t gone away – they’re still the baseline most technical interviews test first. A few reliable options:

• “Walk me through how you’d choose between an array, a hash map, and a tree for this specific problem, and why.”
• “What are the tradeoffs of the language you’re most comfortable with compared to an alternative you’ve used?”
• “Explain a concept you had to relearn recently because your understanding of it turned out to be incomplete.”

That last one is worth including deliberately. It signals whether a candidate is comfortable admitting the limits of their knowledge, which tends to correlate with how well they’ll handle being wrong on your team later.

Real-World Problem-Solving: Move Beyond Pure Algorithm Puzzles

Purely algorithmic brain teasers have fallen out of favor for good reason – they’re increasingly disconnected from what engineers actually do day to day. Practical, scenario-based questions tend to reveal more:

• “Here’s a system that’s suddenly slow under load – walk me through how you’d start debugging it.”
• “You’ve inherited a codebase with no documentation and a bug report with almost no detail. What’s your first move?”
• “Describe a time a fix you shipped caused an unexpected side effect elsewhere. How did you find it, and what did you change afterward?”

These questions reward structured thinking over memorized answers, and they’re much harder to prep for using generic interview question banks.

System Design: No Longer Just for Senior Roles

System design questions used to be reserved almost exclusively for senior engineers. That’s shifted – mid-level candidates are now expected to reason about design tradeoffs too, even if the scope of what they’re asked to design is smaller.

Questions Worth Asking at Different Seniority Levels

• Mid-level: “How would you design a simple rate limiter for an API?” or “How would you structure a database schema for a basic booking system?”
• Senior: “How would you design a system that needs to handle a sudden 10x traffic spike?” or “Walk me through how you’d approach data consistency across multiple services.”

What you’re listening for isn’t a single “correct” architecture – it’s whether the candidate can articulate tradeoffs clearly: consistency versus availability, simplicity versus scalability, and how they’d adjust their answer if a constraint changed mid-conversation.

Ask About AI Judgment Directly – Don’t Skip This

AI-assisted coding is now a standard part of how most developers work, which means a technical interview that ignores it entirely is missing a real and current signal. The goal isn’t to test whether a candidate uses AI tools – almost everyone does – it’s to understand how well they evaluate what those tools produce.

Questions That Work Well Here

• “Tell me about a time an AI coding suggestion was wrong. How did you catch it?”
• “How do you decide when to trust an AI-generated suggestion versus writing something yourself from scratch?”
• “Walk me through how you’d review a pull request you suspected was mostly AI-generated.”

Strong candidates tend to describe specific, concrete moments rather than general statements about being “careful” with AI output. Vague answers here are often a sign the candidate hasn’t actually thought critically about this yet.

Behavioral Questions: Use STAR, But Push Past the Script

Most candidates have prepared behavioral answers using the STAR method – Situation, Task, Action, Result – and that’s fine; a well-structured answer is still useful. The value comes from pushing past the rehearsed version with a follow-up.

A Few Reliable Behavioral Questions

• “Tell me about a time you disagreed with a technical decision your team made. What did you do?”
• “Describe a situation where you had to work closely with a difficult colleague.”
• “How do you typically respond to tough feedback on your code?”

For each one, listen for accountability rather than blame, and for evidence they eventually moved forward productively rather than staying stuck in the disagreement. A candidate who can only describe being right, never wrong, is worth a second look.

Get Specific About Their Past Projects

“Walk me through the most complex project you’ve worked on” is a deceptively simple question that reveals a lot – as long as you follow up properly. The goal is figuring out what the candidate actually owned versus what they simply touched.

Good follow-ups include:

• “Which part of that project’s architecture did you personally decide on?”
• “What would you do differently if you rebuilt it today?”
• “Who else was involved, and what did they own versus what you owned?”

Candidates who can clearly separate their individual contribution from the team’s broader effort tend to have a more accurate, grounded sense of their own skill level – which is itself a useful signal.

Don’t Forget to Test Collaboration, Not Just Correctness

A live coding or pair programming segment reveals things a solo take-home test can’t – specifically, how someone communicates while they’re stuck, and whether they can incorporate a hint gracefully instead of shutting down. This matters even more if you’re building or scaling a distributed team, where clear real-time communication under pressure carries extra weight. Our guide on building a high-performing remote engineering team goes into why this collaborative signal matters so much once a team is geographically spread out.

Let Candidates Ask You Questions Too – And Pay Attention

By the end of a strong technical interview, a good candidate should have thoughtful questions of their own. A candidate who has nothing to ask, or only asks about logistics, is often signaling lower genuine interest. Questions like “what’s something in the codebase you’d love to fix given unlimited time” or “what separates engineers who grow quickly here from those who plateau” tend to come from candidates who’ve thought seriously about the role – and they’re worth noting on your scorecard, not just answering politely and moving on.

Remember: The Interview Is Also Being Evaluated

It’s easy to forget that a technical interview isn’t a one-way filter – candidates are forming an opinion of your company throughout it too. A disorganized panel, an interviewer who seems checked out, or a coding exercise that feels more like an obstacle course than an evaluation can cost you a strong candidate before you ever get to the offer stage. Our post on why candidates reject job offers covers this in more depth – a genuinely good technical interview process is one of the simplest ways to reduce offer dropouts later on.

Building This Into a Repeatable Checklist

The most reliable technical interviews aren’t improvised – they’re built around a consistent scorecard that maps each question to a specific thing you’re trying to learn. A simple structure to start with:

1. Technical fundamentals – one or two core questions per interview loop.
2. A real-world scenario or debugging exercise.
3. A system design conversation, scaled to seniority.
4. An explicit AI-judgment question.
5. Two behavioral questions with genuine follow-up.
6. A specific, detailed walk-through of one past project.

Consistency across candidates makes comparisons fairer and makes it much easier to spot when your interview process itself needs adjusting.

Where Immersive Technology Can Help

Building and running a strong technical interview process takes ongoing calibration, especially as the skills and tools candidates use keep shifting. If you’d like support refining your hiring process end to end, our services and solutions pages outline how we help teams across different industries build interviews that actually predict on-the-job performance. You can also check our blog for more hiring guidance, learn more about us, or get in touch directly.