How to interview for problem solving
On this page
- Why a story about the past isn't enough on its own
- Design a role-neutral case
- What to watch for, in order
- Questions to ask during the exercise
- A rubric for problem solving
- A worked example
- What fluency hides
- Mistakes hiring managers make with this
- A checklist before this interview
- Questions people ask
Interview for problem solving by giving the candidate a real, moderately ambiguous case and scoring how they work through it, not by asking them to describe how they solve problems in general or by running a brainteaser with a single clever trick. Watch four things in order: how they clarify the problem before solving it, how they structure their approach, how they handle a piece of new information you introduce partway through, and how they defend or revise their answer under a follow-up.
Why a story about the past isn't enough on its own
"Tell me about a time you solved a hard problem" produces a rehearsed story, told the way the candidate wants it told, with the messy parts smoothed out in the retelling. It's still useful, but it shows you the narrative someone chose, not their reasoning as it actually happens. A live case, even a short one, adds something a story can't: you watch the process unfold in real time, including the parts a polished story would edit out.
Skip brainteasers and puzzle questions entirely. A riddle with one clever trick tests whether the candidate has seen that riddle before, which mostly measures interview-prep time, not the reasoning skill you actually need on the job. Use a case grounded in something close to the real work instead.
Design a role-neutral case
Build one case you can reuse across candidates for the same role. Good ones share three properties:
- Genuinely ambiguous. There's no single hidden right answer you're waiting for them to find; a good case supports more than one defensible approach.
- Close to the real work. Even simplified, it should resemble a decision this role actually makes, not an abstract puzzle borrowed from a big-tech interview guide.
- Has room for a follow-up twist. Build in one piece of new information you can introduce halfway through, to see how they handle their plan changing under them.
A reusable case template:
Setup (2-3 sentences): describe a real, simplified situation this
role would actually face, with a decision that needs to be made and
incomplete information.
Prompt: "How would you approach this? Think out loud -- I'm more
interested in how you get to an answer than the answer itself."
[Let them work for 5-8 minutes with minimal interruption]
The twist: introduce one new, realistic piece of information that
changes the picture. "One more thing -- [new constraint or fact].
Does that change your approach?"
[Watch what they do with it for another 5-8 minutes]
Close: "Walk me through how confident you are in this, and what
would change your mind."
An example for a customer support lead role: "Support tickets on one feature have tripled this month, but customer satisfaction scores on that feature haven't moved. How would you figure out what's going on?" The twist: "One more thing: the tripling started the same week we shipped an update to a completely unrelated feature." A strong candidate updates their theory toward checking for an unrelated release breaking something rather than assuming the obvious feature is at fault.
The same template works for roles that aren't analytical on paper. For an office manager role, the case might be a double-booked event space with two departments both claiming they reserved it first; the twist could be that the booking system shows a third, unrelated hold nobody flagged. For a sales role, the case might be a long-time client suddenly going quiet on renewal, with the twist that a competitor just launched in their specific market. The mechanics stay the same regardless of the field: ambiguity, a decision, and one new fact that tests whether the candidate updates or digs in.
What to watch for, in order
| Stage | What a strong candidate does | Red flag |
|---|---|---|
| Clarifying the problem | Asks one or two sharp questions before diving in, to confirm what's actually being asked and what constraints are real | Starts solving immediately with no clarifying questions, or asks so many that they're stalling |
| Structuring the approach | Lays out a rough plan or a few possible angles before committing to one, and says which angle they're starting with and why | Jumps straight to a single answer with no visible structure, or gets lost in the first branch they try |
| Handling the twist | Visibly updates their approach in light of the new information, rather than forcing the new fact to fit the old plan | Ignores the new information, or restarts from scratch with no memory of the useful parts of their first pass |
| Defending the answer | States their confidence level honestly and names specifically what would change their mind | Overclaims certainty on a genuinely ambiguous case, or abandons a sound answer the moment you push back at all |
Questions to ask during the exercise
| Question | What it tests |
|---|---|
| "What are you assuming right now that you're not sure is true?" | Whether they can separate what they know from what they're guessing, mid-process |
| "What would you do first if you only had an hour?" | Prioritization under a real constraint, not an ideal-world plan |
| "What's the strongest argument against your own approach?" | Whether they can genuinely stress-test their own thinking, not just defend it |
| "How would you know in two weeks if this was the wrong call?" | Whether they think in terms of checkable outcomes, not just plausible-sounding plans |
A rubric for problem solving
| Dimension | 1 — Weak | 2 — Developing | 3 — Solid | 4 — Strong |
|---|---|---|---|---|
| Clarifying before solving | No clarifying questions; solves the wrong problem or misses a constraint | One clarifying question, somewhat surface-level | Sharp clarifying questions that shape the approach | Same, plus explicitly states what's in and out of scope before starting |
| Structure | No visible plan; jumps around or fixates on one narrow angle | Some structure, but the plan isn't stated out loud | Clear, stated approach with a reason for starting where they did | Same, plus names alternative angles and explains why they chose this one |
| Adapting to new information | Ignores the twist or forces it to fit the original plan | Notices the twist but the update to their approach is minor or unclear | Genuinely revises the approach in light of the new fact | Same, plus explains specifically what about the new fact changed their reasoning |
| Calibrated confidence | Wildly overclaims or completely collapses under any pushback | Some hedging, but can't say specifically what would change their mind | States confidence honestly and names what would change their mind | Same, plus proposes how they'd actually go test it if this were real |
A worked example
Invented, using the support-ticket case above.
Candidate response: "Before I guess, I want to know: is this all customers or a segment, and did anything else ship around the same time? ... Okay, given that, I'd first check if the ticket increase is actually about confusion versus a real bug, since those need different fixes. I'd start by reading ten of the tickets directly rather than trusting the category tag."
After the twist (unrelated feature update shipped the same week): "That changes my theory. I'd now specifically check whether that update touched anything shared, like an API or a shared component, before I keep investigating the original feature at all. I'd say I'm now more confident it's the update than the feature itself, maybe 70/30, and I'd confirm by rolling the update back for a small group and watching the ticket volume."
Score: 4 across all four dimensions. Clarified before solving, stated a structured plan, genuinely updated on the twist rather than forcing it into the old theory, and gave a calibrated confidence level with a concrete way to check it.
What fluency hides
- Confident delivery isn't sound reasoning. Some candidates narrate a wrong or shallow approach with total confidence. Score the structure and the clarifying questions, not the tone.
- Speed isn't quality. A candidate who answers instantly may be pattern-matching to a case they've seen before rather than actually reasoning through this one. A short, thoughtful pause before answering is a good sign, not a bad one.
- A "textbook" framework recited from memory isn't the same as using it. Watch whether they apply the framework to the specifics of your case or just narrate the framework's steps in the abstract.
Mistakes hiring managers make with this
| Mistake | What it costs you |
|---|---|
| Using a brainteaser instead of a job-relevant case | You measure puzzle exposure, not the reasoning skill you need |
| Jumping in to help the moment the candidate goes quiet | You lose the chance to see how they work through discomfort on their own |
| Scoring only the final answer | You miss the process, which is the part that actually transfers to the job |
| Using a different case for every candidate | Scores stop being comparable across the pool |
| Penalizing a wrong final answer that came from sound reasoning | You filter out candidates who reason well on genuinely ambiguous problems, which is what most real work looks like |
A checklist before this interview
- You have one reusable case, close to the real work, with a built-in twist.
- The same case is used for every candidate at this stage.
- You're scoring clarifying questions, structure, adaptation and calibrated confidence, not just the final answer.
- You've decided in advance how much you'll intervene if the candidate goes quiet.
- You're distinguishing confident delivery from sound structure when you score.
Interview Signal's scorecards let you attach the specific quote behind each dimension score, which matters here: "adapted well to the twist" is easy to write and hard to defend later, while the exact line the candidate said when the new information landed is not.
Questions people ask
Should I use a brainteaser to test problem solving?
No. Puzzles with a single clever trick test whether someone has seen that puzzle before, not how they reason, and they favor candidates with interview-prep time over candidates who are good at the actual job. Use a case grounded in real, job-relevant ambiguity instead.
How long should a live problem-solving exercise take?
Fifteen to twenty minutes is usually enough to see the full process: how they clarify the problem, structure it, and reach a defensible answer. Longer than that tests stamina and rehearsal as much as reasoning.
What if the candidate gets the wrong final answer?
Score the process more heavily than the final number or conclusion, unless the role specifically requires getting to a precise right answer under pressure. A candidate who reasons soundly and reaches a defensible wrong answer is often a stronger hire than one who guesses right.
Can problem solving be tested without a live exercise, over a resume review alone?
Past-behavior questions about a specific problem the candidate solved add real evidence, but they show you the story the candidate chose to tell, not their reasoning as it happens. A live exercise, even a short one, adds something a story can't.