How to Interview a Candidate Who Sounds Great But Says Nothing Specific
Marcus Chen shakes your hand, makes perfect eye contact, and settles into the interview chair like he's done this a hundred times. He has. Eight years at a well-known tech company, led a team of six, built "scalable microservices architecture." Every sentence is fluent, articulate, and almost completely devoid of specifics. "We implemented a distributed caching layer that reduced latency by 40%." We. You ask a follow-up and get another "we." You ask about a failure and hear a pre-packaged learning experience wrapped in a bow. Thirty minutes in, you realize you know everything about what his team accomplished and nothing about what he personally did. Your engineering team desperately needs a senior hire. A wrong hire at this level costs $200K and six months. Marcus sounds perfect. And that is exactly the problem.
Why This Conversation Goes Wrong
You mistake fluency for depth. Marcus speaks beautifully. Complete sentences, smooth transitions, confident delivery. But fluency is a presentation skill, not an engineering one. Some of the best engineers you will ever interview stumble over words. Some of the smoothest interviewees have been managing rather than coding for three years.
You accept "we" answers without pressing for "I." Every time Marcus says "we built" or "we decided," there is a hidden question: what did you specifically build? What did you specifically decide? Teams accomplish things together, but interview answers that never use first-person singular are a red flag, not a sign of humility.
You let the resume anchor your expectations. The brand-name company on Marcus's resume creates a halo effect. You assume that anyone from that company at that level must be individually strong. But organizations carry people, and titles at large companies sometimes reflect tenure more than capability.
You skip the failure question when the first attempt gets deflected. Marcus pivots your failure question to a "learning experience" with no real vulnerability. Most interviewers accept this and move on. The candidate who cannot name a genuine failure is either hiding something or lacks the self-awareness you need at a senior level.
The Peel-Back Protocol
STAR-method questions are standard. The problem is that experienced candidates have rehearsed STAR answers to the point of polish. The Peel-Back Protocol uses layered follow-up questions to move past prepared answers and into territory where rehearsal runs out — the specifics that only the person who actually did the work can provide.
Start broad and let them perform
"Tell me about the most impactful technical project you've led." Let Marcus give his polished answer. Do not interrupt. The prepared answer is useful data — it tells you what he wants you to believe. Your real questions start when he finishes.
Zoom into the specific
"You said 'we built a distributed caching layer.' Walk me through the moment you personally sat down to design it. What was on your screen? What was the first decision you had to make?" This is where vagueness collapses. Someone who designed it can describe the technical tradeoffs. Someone who managed the team that designed it cannot.
Ask for the ugly middle
"What went wrong during that project that no one outside the team would know about?" Polished candidates prepare for "tell me about a challenge." They do not prepare for "what went wrong that you've never told an interviewer." The pause that follows is the most diagnostic moment of the interview.
Test the learning with a hypothetical
"If you were starting that project today with what you know now, what would you do differently?" This question cannot be answered with a rehearsed story. It requires genuine reflection and technical depth. The answer reveals whether Marcus learned from the experience or just survived it.
The moment that changes everything
He's not lying. He's narrating someone else's work.
Marcus is not a fraud. He was genuinely part of important projects at a strong company. But his role was closer to project manager than architect — coordinating the work of a tech lead who made the real design decisions. Marcus used "we" so many times not to be modest, but because the honest version of many answers would start with "my tech lead decided, and I coordinated the execution." This is not a disqualifying truth. Coordination at scale is a real skill. But you are hiring for a hands-on senior engineer, and Marcus has been managing rather than coding for the past two years. His hands have atrophied. He knows this, which is why he applied for this role — he genuinely wants to get back to technical work. The interview is not about catching Marcus in a lie. It is about understanding whether he is a senior engineer today, or someone who was on the path to becoming one before management pulled him sideways.
What to Say (and What Not To)
Instead of
"Tell me about a time you led a project."
Try this
"Walk me through a specific technical decision you personally made on that project — what were the tradeoffs?"
Instead of
"That sounds like a great accomplishment."
Try this
"Help me understand your specific role in that. What parts did you personally design versus coordinate?"
Instead of
"Tell me about a time you failed."
Try this
"What went wrong on that project that you've never told an interviewer before?"
Instead of
"Do you have experience with distributed systems?"
Try this
"If I looked at the caching layer code, which files have your fingerprints on them? What would I see?"
Instead of
"Sounds like you were a great team leader."
Try this
"If you were starting that architecture from scratch today, what would you change? Walk me through your reasoning."
The Bigger Picture
A 2023 study by the Josh Bersin Company estimated that a bad senior engineering hire costs between $200,000 and $400,000 when accounting for salary, onboarding, lost productivity, and eventual replacement. But the hidden cost is worse: a senior hire who cannot do the technical work they were hired for creates a bottleneck that slows the entire team for months before the problem is visible enough to address. The interview is the highest-leverage point in the entire hiring process.
Research from Schmidt and Hunter's landmark meta-analysis on hiring — updated in 2016 and still the gold standard — found that structured behavioral interviews predict job performance at 0.58 correlation, compared to 0.18 for unstructured interviews. But the critical modifier is follow-up question quality. Interviews with generic STAR questions perform little better than unstructured ones. The predictive power comes from probing follow-ups that force candidates beyond rehearsed territory.
There is a broader pattern worth naming: the rise of "management drift" in senior IC roles. As engineering organizations grow, strong individual contributors often get pulled into coordination roles without a formal title change. They spend 18 months managing schedules and stakeholders, their coding skills atrophy, and they apply for IC roles at other companies using their team's accomplishments as their own. This is not deception — it is a genuine identity confusion that the interview process needs to diagnose.
Practice This Conversation
10 minutes · AI voice roleplay with Marcus Chen
Reading about this is step one. Practicing it changes everything. Sonitura lets you rehearse this exact conversation with Marcus Chen, a realistic AI senior software engineer candidate, 8 years experience who reacts to your words in real time. It takes 10 minutes. The next time a candidate gives you a flawless answer that reveals nothing, you'll know exactly which question peels back the polish.
Practice This Scenario Free →Related Guides
Human Resources
How to Get the Truth in an Exit Interview When They're Being Polite
7 min read · 8 min practice
Human Resources
How to Respond When a Key Employee Brings a Competing Offer You Can't Match
7 min read · 8 min practice
Human Resources
How to Rescue an Onboarding That's Quietly Failing
6 min read · 7 min practice