Most technical interviews test the wrong things.
LeetCode problems measure whether a candidate has practiced LeetCode problems. Whiteboard exercises measure how someone performs under artificial pressure with a marker in their hand. Take-home projects measure whether someone has 8 free hours on a weekend.
None of these reflect what engineers actually do at work.
What engineers actually do — especially on agile teams — is break down ambiguous problems, estimate effort under uncertainty, collaborate with people who have different context, and articulate their reasoning clearly. These are the skills that separate a great hire from a frustrating one. And almost no interview process tests them directly.
There's a technique that agile teams use every sprint to do exactly this. It's called planning poker. And with a small shift in framing, it makes one of the most revealing engineering interview formats you can run.
What Planning Poker Actually Tests
Planning poker is a group estimation technique used in agile software development. A facilitator presents a user story or task, every participant privately selects a card representing their effort estimate, and everyone reveals simultaneously. Where estimates diverge, the group discusses why — and that discussion is where the real value happens.
In a sprint planning context, the goal is consensus on story points. In an interview context, the goal is something more interesting: you're watching how a candidate thinks about complexity.
Consider what a candidate reveals when they estimate:
Do they ask clarifying questions before voting, or do they just pick a number? Senior engineers know that an estimate without context is fiction. A candidate who immediately asks "what's the expected error handling?" or "do we need to support mobile?" before selecting a card is demonstrating exactly the kind of thinking you want on your team. A candidate who confidently picks 3 on a story they clearly haven't fully read is showing you something too.
When their estimate differs from the team's, can they explain why? This is the most revealing moment in the entire exercise. A candidate who estimated 13 when the team estimated 5 might be flagging a real complexity the team has normalised. Or they might be revealing a gap in their technical knowledge. Either way, you learn something concrete. This moment — "walk me through why you picked that number" — produces better signal than almost any interview question you can ask directly.
Do they consider edge cases, dependencies, and risks, or just the happy path? Engineers who have been burned before estimate differently than engineers who haven't. Someone who has shipped to production knows that "add a notifications feature" is a 2-point story on paper and a 13-point story in practice. Their estimate reflects that experience even before they explain it.
How do they handle uncertainty? A well-designed estimation deck includes cards for "I need more information" and "I'd need to spike this first." Candidates who use these cards appropriately are demonstrating professional self-awareness. Candidates who never reach for them may be overconfident. Candidates who reach for them on everything may struggle to commit.
How to Run a Planning Poker Interview
The setup is straightforward. You need an online planning poker tool, 5–8 prepared user stories, and 30–45 minutes.
Step 1: Prepare the stories
Use real user stories from your actual backlog if possible, anonymised to remove internal context. Real stories work better than invented ones because they reflect genuine ambiguity — the same ambiguity your new hire will face. If using real stories isn't appropriate, write fictional ones at roughly the complexity level you'd expect a candidate in this role to handle.
A good set of stories for a mid-level backend engineer interview might include: one clearly-scoped CRUD endpoint (should estimate small), one story with an obvious external dependency (should prompt questions), one story with a hidden performance implication (separates experienced from inexperienced), and one deliberately vague story that requires decomposition before it can be estimated at all.
Step 2: Include one or two real team members
This is important. Don't run the session with just the interviewer and the candidate — include one or two engineers from the actual team. This does three things: it gives you a calibration baseline (you know how your team estimates, so you can see how the candidate compares), it makes the exercise feel more authentic to the candidate, and it lets your engineers assess whether they'd actually want to work with this person.
Step 3: Set expectations upfront
Tell the candidate exactly what you're doing and why. "We use planning poker in our sprint planning every two weeks. Today we're going to run a short estimation session with some user stories — similar to what you'd be doing on the team. We're less interested in whether your numbers match ours and more interested in how you think through complexity. Ask any questions you'd ask in a real planning session."
This framing matters. You want to see how they perform in a realistic context, not how they perform under the additional pressure of not knowing the rules. Candidates who are good at estimation will shine under this framing. Candidates who bluff will also reveal themselves quickly, because bluffing is harder when everyone shows their card at the same time.
Step 4: Run the session
Present each story, give everyone 60–90 seconds to read and think, then reveal simultaneously. For any story where the candidate's estimate differs from the team's by more than one card value, ask them to explain their thinking. Don't correct them or signal that the team estimate is "right" — just listen. The discussion is the interview.
Pay attention to:
- How they handle the first story (nervous, systematic, impulsive?)
- Whether their estimates improve as the session goes on (fast learners calibrate quickly)
- How they respond when the team disagrees with their estimate (defensive, curious, or genuinely interested?)
- Whether they change their estimate in the next round based on the discussion, or stubbornly repeat the same number
Step 5: Debrief
After the session, ask two questions. First: "Was there a story where you were most uncertain about your estimate? What made it hard?" Second: "Was there a story where you felt the most confident? What made that one clearer?" These questions reveal self-awareness and often produce the most interesting part of the conversation.
What Different Candidates Look Like
After running a few of these sessions, patterns emerge quickly.
The overconfident junior estimates quickly and consistently underestimates. They pick 2 on a story the team picks 8. When asked to explain, they describe only the happy path. They haven't shipped enough to know what they don't know yet. This isn't necessarily disqualifying for a junior role — it's useful information about the kind of mentoring they'll need.
The experienced engineer who's been burned asks two or three clarifying questions before every estimate. They have strong opinions about the vague story ("I wouldn't estimate this at all — we need to decompose it first"). Their estimates trend slightly higher than the team's, and they can explain exactly why. This is often your best candidate.
The communication-first engineer doesn't always have the highest calibration, but every time their estimate differs they produce a clear, articulate explanation that the team finds useful. "I went with 8 because I'm assuming we'll need to handle the case where the third-party API is down — are we okay with eventual consistency there?" This person makes the team better even when they're wrong.
The anxious high-performer knows their stuff but freezes slightly when asked to explain divergent estimates. They often change their estimate to match the team's without discussion rather than defending their reasoning. This is useful to know before you hire them — they may need psychological safety investment before they'll speak up in real sprint planning.
Why This Works Better Than Other Formats
The fundamental problem with most technical interviews is that they're adversarial. The interviewer has the answers, the candidate is trying to produce those answers, and both parties know it. This dynamic produces performance, not authentic behaviour.
Planning poker is collaborative by design. The interviewer doesn't have a "correct" answer. The team estimates alongside the candidate, not above them. The discussion that follows is genuinely mutual — sometimes the candidate will flag something the team overlooked, and that's a good outcome for everyone. This collaborative dynamic relaxes the performance pressure just enough that candidates behave more like themselves.
It's also considerably more predictive than abstract problem-solving exercises for roles that involve agile ceremonies. If a candidate will be sitting in your sprint planning every two weeks, seeing how they actually behave in that context is more relevant than seeing how they reverse a linked list.
Practical Considerations
Time: A full estimation session with 8 stories, including discussion, takes about 35–40 minutes. That's a reasonable interview slot and leaves time for debrief.
Remote-friendly: Online planning poker tools work well for remote interviews. Candidates join via link, no account needed. The format is actually slightly better remote than in-person because simultaneous card reveals are cleaner digitally than physically.
Legal and process concerns: Check with your HR team that a non-standardised format fits within your hiring process. In some organisations, all candidates for a role must complete identical assessments. The way to handle this is to standardise the story set — every candidate for a given role gets the same 7 stories in the same order.
Combining with other formats: This works best as one component of a broader interview loop, not as the only technical assessment. Pair it with a short technical conversation about past work and a cultural values discussion. The estimation session handles "how do you think about complexity" — other formats handle the rest.
Getting Started
You don't need any special tooling to try this. Any online planning poker tool with a shareable link works. Create a session, add your user stories to the backlog, share the link with the candidate and your team members, and run it exactly as you would a sprint planning session.
If you want to try it with your next engineering hire, ScrumJam has a free planning poker tool on our planning poker page — no account required to join, and sessions can be set up in under two minutes. The Fibonacci deck works well for interviews, though some teams prefer the T-shirt size deck for candidates who are less familiar with story points. For background on the ceremony itself, see the beginner's guide to planning poker and the planning poker handbook.
The first time you run this, the debrief conversation will likely be the most interesting part of your interview week. You'll learn things about how candidates think that you simply can't surface with a whiteboard problem.
ScrumJam is a free planning poker and retrospective tool for agile teams. Teams at BBC, Sony, NordVPN, and Hostinger use it for sprint ceremonies — and now, apparently, for hiring.