I’ve sat through enough interviews to know that most “expert” advice on how to ask good questions in an interview is complete nonsense. You’ll find plenty of articles telling you to ask about “company culture” or “five-year growth plans,” as if those scripted answers actually tell you anything about the day-to-day reality of the job. I don’t care about their mission statement; I want to know if the team actually follows an on-call rotation or if they just hope nothing breaks on a Friday afternoon. If you spend your time rehearsing polite, superficial inquiries, you aren’t interviewing them—you’re just performing for them.
I’m not here to give you a list of clever parlor tricks to impress a recruiter. Instead, I want to share the specific, slightly unpolished questions I use to figure out if a team is actually competent or just lucky. We’re going to focus on the mechanics of how they work—the deployment failures, the technical debt, and the way they handle a production outage at 2:00 AM. My goal is to help you find out what the job actually is before you sign a contract you’ll regret.
Table of Contents
Moving Beyond Generic Behavioral Interview Techniques
Most companies rely on the same tired behavioral interview techniques: “Tell me about a time you had a conflict with a coworker” or “Where do you see yourself in five years?” I’ve sat through dozens of these, and frankly, they’re useless. They invite rehearsed, polished stories that tell you nothing about how a person actually thinks when the pressure is on. If you want to move past the script, you have to stop looking for the “correct” answer and start looking for the logic behind the decision.
Instead of asking for a sanitized version of a past success, try using more aggressive probing questions for hiring managers to dig into the messy middle of a project. Ask them to walk you through a time they made a technical decision that turned out to be completely wrong. I’m not looking for them to admit a mistake; I’m looking to see if they can explain why it was wrong and what the specific trade-offs were. This is how you actually start identifying red flags in interviews—not by catching them in a lie, but by seeing if they lack the self-awareness to recognize a bad architectural choice when it’s staring them in the face.
Using Probing Questions for Hiring Managers to Find Truth
When you’re the one sitting on the other side of the table, the interview isn’t just about vetting the candidate; it’s about vetting the reality of the role they’re walking into. Most standard candidate assessment strategies fail because they focus on the “what” instead of the “how.” If a candidate asks, “What is the tech stack?” and you answer, “We use Go and Kubernetes,” you haven’t actually told them anything about their future quality of life. To find the truth, you need to use probing questions for hiring managers—or rather, you need to be prepared for the candidates to turn the mirror back on you.
I’ve learned that the most telling moments happen when a candidate pushes past the polished company slide deck. If they ask, “When was the last time a deployment failed, and how did the team react during the post-mortem?” they aren’t just being difficult; they are looking for the scars. If you can’t give a concrete answer, you aren’t measuring cultural fit, you’re just performing a scripted dance. A good candidate wants to know if you actually have a process for when things go sideways, or if “on-call” just means “unsupervised chaos.” Don’t take offense at the depth of their questions; take it as a sign that they actually care about the systems they’ll be building.
Five ways to stop interviewing for resumes and start interviewing for reality
- Ask for the “post-mortem” version of their projects. Instead of “Tell me about a time you succeeded,” try “Tell me about the last time a deployment went sideways and you were the one on call.” If they can’t walk you through the messy middle of a failure, they probably weren’t actually the ones driving the change.
- Test for the “why,” not just the “how.” When they describe a stack or a pattern, push past the syntax. If they say they used Kafka, ask why they didn’t just use a simple pub/sub or a database queue. I’ve seen too many engineers who can implement a pattern but can’t justify the overhead it adds to the system.
- Look for the “unspoken trade-offs.” Every technical decision is a compromise. If a candidate presents a solution as a perfect, silver-bullet architecture with no downsides, they are either lying or haven’t thought deeply enough. A good engineer should be able to tell you exactly what they gave up to get what they wanted.
- Use the “System Drift” probe. Ask them how they ensure the code they write today stays maintainable two years from now. It’s easy to write clever code; it’s much harder to write code that a tired engineer can understand during a production incident at 3:00 AM. You want the person who values legibility over cleverness.
- Watch how they handle being wrong in the room. Throw a slightly incorrect technical premise their way—not to trick them, but to see their reaction. Do they blindly agree to be polite, or do they have the backbone to say, “Actually, I think that’s a misconception”? I’d rather hire someone who corrects me than someone who lets a bug slide into my codebase just to avoid an awkward moment.
The Bottom Line
Stop looking for “correct” answers; look for how they handle being wrong. The best engineers I’ve worked with are the ones who can walk you through a failure without trying to polish it into a success story.
If a candidate can’t explain the trade-offs of their favorite tool, they probably don’t understand the tool. I’d much rather hire someone who knows why a specific database is a bad idea for a certain scale than someone who just knows the syntax.
Use your questions to find the gap between what’s on their CV and what happens when the pager goes off. You aren’t hiring a textbook; you’re hiring a person who has to navigate the mess we all inevitably create.
The Bottom Line
At the end of the day, interviewing isn’t about checking boxes on a rubric or seeing if someone can recite the definition of a microservice. It’s about peeling back the layers of a polished answer to see how a person actually thinks when the pressure is on. By ditching the scripted behavioral questions and focusing on real-world friction—the messy, unscripted moments where things actually go wrong—you get a much clearer picture of who is joining your team. You aren’t just looking for technical proficiency; you are looking for the ability to navigate ambiguity without panicking when the dashboard turns red.
I’ve spent enough years in production to know that the best engineers aren’t the ones who claim to never make mistakes, but the ones who can explain exactly why they made them and how they fixed the underlying system. When you change your interview style to prioritize this kind of honesty, you stop hiring “performers” and start hiring problem solvers. It makes the hiring process feel less like an interrogation and more like a conversation between two people who both care about building things that actually work. If you get this right, you won’t just be filling a headcount; you’ll be building a team that can survive the 2:00 AM calls.
Frequently Asked Questions
How do I tell the difference between a candidate who is actually experienced and one who has just memorized the right buzzwords to pass the screen?
Buzzwords are cheap; scars are expensive. If a candidate says they “optimized a microservices architecture,” don’t stop there. Ask them what the bottleneck actually was. Was it a connection pool exhaustion, or just a poorly tuned garbage collector? Someone who’s actually lived through a production outage will talk about the trade-offs, the specific metrics they watched, and the things they regret doing. The person who memorized the textbook will just give you the “correct” theoretical answer.
What do I do if a candidate gives me a perfect, textbook answer that feels suspiciously rehearsed and lacks any real-world grit?
If they give you the textbook answer, stop following the script. They’ve clearly practiced the “STAR” method in a mirror. I usually pivot by stripping away the theory. I’ll say, “That sounds like the right way to do it on paper, but tell me about a time the theory failed you.” I want to hear about the mess, the workaround, or the mistake. If they can’t describe a moment of friction, they haven’t actually been in the trenches.
How much technical depth should I actually push for during a first interview before I risk running out of time for the cultural stuff?
I used to try and cover everything, only to realize I’d spent forty minutes on a database schema and zero minutes finding out if the candidate actually likes working in a team.
If I'm interviewing someone more senior than me, how do I ask probing questions without looking like I don't know what I'm doing?
Don’t try to out-tech them; you’ll just look like you’re reading a Wikipedia page. Instead, pivot from “how it works” to “why it failed.” If they suggest an architecture, don’t ask how it scales—ask what the breaking point is. Ask about the trade-offs they hated making. You aren’t testing their knowledge of syntax; you’re testing their judgment. A senior engineer’s value isn’t knowing the right answer, it’s knowing when the “right” answer is actually a trap.
