Probing & Follow-ups
The initial STAR answer is just the surface. Probing is how you find out whether the candidate actually did the work — and how deeply they understand what they did.
Why probing matters
A polished STAR story sounds great. But how much of it was actually the candidate's work? People naturally absorb team accomplishments into their personal narratives. They're not lying — they just blur the line between "I" and "we" over time.
Probing solves this. When you dig into the details, two things happen:
- People who did the work can go deeper. They'll explain the tradeoffs, the surprises, the things that almost went wrong. They'll use specific technical details without rehearsal.
- People who were peripheral will hit a wall. They'll repeat the same high-level story, deflect to team-level language, or give vague answers about the "how."
The depth test
Think of probing as a depth test. Each follow-up question takes the candidate one level deeper:
| Level | What you hear | What it tells you |
|---|---|---|
| Surface | "We built a new data pipeline" | They know the project existed |
| Involvement | "I designed the schema and wrote the ingestion layer" | They had a specific role |
| Understanding | "I chose Kafka over SQS because we needed replay capability and our throughput was 50K events/sec" | They made technical decisions and can explain why |
| Mastery | "In hindsight, I'd have added a dead-letter queue earlier — we lost about 2 hours of events during the first incident because I hadn't accounted for poison messages" | They internalized the lessons and can critique their own work |
You don't need the candidate to be a domain expert in your area. If they truly owned the work, they can explain it so clearly that you understand it — even if you've never touched Kafka, data pipelines, or whatever technology they describe. That ability to make the complex understandable is itself strong signal.
What to probe for
Interesting details you heard: When something in the story catches your attention — an unusual decision, an unexpected outcome, a moment of conflict — follow that thread. "You mentioned the team pushed back on your approach. Tell me more about that."
Things that might be under the covers: Every project has hidden complexity. If the story sounds too clean, probe for what went wrong. "What was the hardest part of this that you haven't mentioned yet?"
The 'I' vs. 'We' boundary: When the candidate uses "we," gently redirect. "You said 'we decided' — what was your specific role in that decision?"
The reasoning behind decisions: Don't accept "I chose option A." Ask why. "What were the alternatives you considered, and what made you pick that approach?"
Probing phrases that work
Keep these natural and conversational — probing shouldn't feel like an interrogation:
| Purpose | Phrase |
|---|---|
| Go deeper | "Tell me more about how you specifically contributed to that." |
| Clarify ownership | "When you say 'we,' what was your individual role?" |
| Explore reasoning | "Walk me through your thinking when you made that decision." |
| Find hidden complexity | "What was the part of this that didn't go as planned?" |
| Test understanding | "If you had to explain that tradeoff to a non-technical stakeholder, how would you describe it?" |
| Explore learning | "What would you do differently if you faced this situation again?" |
When probing reveals weak signal
Sometimes probing reveals that the candidate's contribution was smaller than the initial story suggested. That's not a failure — it's the system working. You've generated real data. A candidate who can't go deep on their own story is giving you honest signal about their level of involvement.
Exercise: Identify the probing opportunities
Read this candidate's initial answer and identify three places where you would probe deeper.
Question asked: "Tell me about a time you had to deliver a project under a tight deadline."
Candidate's answer:
"Last year we had a major client who needed a custom reporting dashboard by the end of the quarter — about six weeks out. The existing system couldn't handle their data volume. We decided to rebuild the aggregation layer and add a caching tier. I worked with the frontend team to redesign the UI while the backend changes were happening. We shipped two days early and the client renewed their contract for another year."
Probing opportunities:
→ "We decided to rebuild the aggregation layer" — who decided? The candidate used "we" for the biggest technical decision in the story. Probe: "Walk me through how that decision was made. What was your role in choosing to rebuild vs. other approaches?"
→ "I worked with the frontend team" — what does 'worked with' mean? This could mean they led the redesign, or it could mean they attended meetings. Probe: "What specifically did you own in the frontend redesign? What decisions did you make?"
→ The story is very clean — nothing went wrong. A six-week rebuild of an aggregation layer with a caching tier and UI redesign, delivered early? Probe: "What was the biggest risk or setback you encountered during those six weeks?"
→ "The client renewed" — was that because of the dashboard? The Result connects the project to a business outcome, but the causal link is asserted, not proven. Probe: "How did you know the dashboard was the reason the client renewed? Did they give specific feedback?"
A candidate says 'We decided to migrate to microservices.' What is the best follow-up?
You probe a candidate about a technical decision and they give a clear, detailed explanation — but you don't have expertise in that technology. How should you interpret this?
After probing, you discover the candidate's actual contribution was smaller than their initial story suggested. What should you conclude?