Problem solving interview questions
Problem solving interview questions test execution, not intelligence: how a candidate turns a messy situation into a scoped problem, a sequence of steps, and a shipped fix. The 13 below work for any role. Ask for real problems, then follow the process — where they started, what they tried, what they did when the first attempt failed.
All 13 questions
Problem solving behavioral interview questions
- 01Tell me about a problem where the hard part was working out what the problem actually was. How did you pin it down?
- 02Describe the last time you turned a vague request into a concrete plan. What did you do before any real work started?
- 03Tell me about a time you were stuck waiting on someone else to make progress. How did you get moving without them?
- 04Tell me about a problem you fixed with a workaround you knew was temporary. Did the permanent fix ever happen?
- 05Describe a problem that came back after you'd already solved it once. What did you do differently the second time?
Problem solving questions about working with AI
- 06Walk me through the last real problem you handed to an AI tool. What did you do when its first answer didn't work?
- 07Describe a problem where an AI tool kept you going in circles. How did you notice you were stuck, and how did you get out?
- 08When you take on a new problem, how do you decide which parts go to an AI tool and which you work through yourself? Give me a recent example.
- 09Tell me about a time an AI tool gave you a fix that worked but that you didn't fully understand. What did you do before using it?
Live scenarios to watch problem solving happen
- 10A routine process breaks this morning, the one person who understands it is away all week, and customers are starting to notice. Walk me through your first 30 minutes.
- 11A tool your whole plan depends on will be unavailable for a week, and the deadline doesn't move. How do you rebuild the plan?
- 12Your manager hands you a one-line problem: 'Onboarding is losing customers — fix it.' What do you do before proposing any fix?
- 13You've tried the two obvious fixes and the problem is still there. It's mid-afternoon and this needed solving today. What's your next move?
Questions 1–5
Problem solving behavioral interview questions
Tell me about a problem where the hard part was working out what the problem actually was. How did you pin it down?
A strong answer shows deliberate scoping: the candidate names what the problem first looked like, what it turned out to be, and the specific checks — data, questions, observation — that closed the gap.
What to look for
- Names the gap between the reported symptom and the real problem.
- Used a checkable method to narrow it: data, direct observation, asking the affected people.
- Resisted fixing the symptom while the cause was still unknown.
Example answerRed flags
Example answer
Support kept escalating 'the export is broken'. I sat with three of the complainers and watched: the export worked, but it silently dropped rows over 10,000 — so people thought their filters had failed. The real problem was a missing warning, not the export. One banner, tickets down 80% in a month.
Red flags
- Jumped straight to a fix and only reframed the problem after it failed.
- Can't say how they knew they'd found the real problem rather than a plausible one.
Describe the last time you turned a vague request into a concrete plan. What did you do before any real work started?
Strong candidates show a repeatable opening move: clarify what done looks like, find the constraint that shapes everything else, and sequence the steps so the riskiest unknown gets tested first.
What to look for
- Asked what done looks like before estimating anything.
- Identified the constraint — budget, date, dependency — that dictated the sequence.
- Put the riskiest or most uncertain step first, not the easiest.
Example answerRed flags
Example answer
'Make our reporting better' was the request. I spent one day asking the four people who read the reports what decision each report fed — two fed none, so we killed them. The plan became three items in order: fix the revenue number everyone distrusted, automate the weekly pull, then redesign. Distrust was the risk, so it went first.
Red flags
- Started executing on their own interpretation and checked it only at delivery.
- The 'plan' is a task list with no ordering logic behind it.
Tell me about a time you were stuck waiting on someone else to make progress. How did you get moving without them?
Good answers show the candidate treats a blocker as a problem to route around: they resequenced work, found a partial substitute, or escalated with a specific ask — while keeping the blocked person informed, not blamed.
What to look for
- Resequenced: pulled forward work that didn't depend on the blocker.
- Made the ask smaller — a partial answer, a draft, ten minutes — instead of waiting for the full thing.
- Escalated cleanly when needed, with a date and a specific request.
Example answerRed flags
Example answer
I needed legal sign-off on new contract wording and legal was buried — three weeks quoted. I couldn't ship, but I could prepare: built the rollout for both plausible outcomes, and asked legal one narrow question — 'is clause 4 the risky part?' — instead of 'review everything'. It was. They cleared clause 4 in two days; the rest followed.
Red flags
- Waited the full three weeks and reported the delay as someone else's fault.
- Went around the blocker in a way that created rework or broke trust.
Tell me about a problem you fixed with a workaround you knew was temporary. Did the permanent fix ever happen?
The strong answer defends the workaround as the right call under the constraint, then answers the second question honestly — the permanent fix shipped because they tracked it, or it didn't and they own why.
What to look for
- The workaround was a conscious trade-off with a named cost, not a habit.
- They created a forcing function for the real fix: a ticket, a date, an owner.
- Honest about the outcome — 'it's still the workaround' is a fine answer if they own it.
Example answerRed flags
Example answer
Our invoicing tool couldn't handle one client's currency, so I ran their invoices through a spreadsheet every month — 40 minutes, error-prone, but it kept revenue flowing. I logged the fix with finance and re-raised it each quarter. It took three quarters to get built. The month it shipped I deleted the spreadsheet so nobody could quietly keep using it.
Red flags
- Workarounds are their default mode — every story ends with one still running.
- Claims the temporary fix 'became permanent' with no acknowledged cost.
Describe a problem that came back after you'd already solved it once. What did you do differently the second time?
Strong answers admit the first fix treated a symptom, show what the recurrence revealed about the real cause, and describe a second fix aimed at that cause — plus how they verified it stuck.
What to look for
- Explains why the first fix looked sufficient at the time — no revisionism.
- The second pass dug into the cause: asked why the condition kept arising.
- Verified durability: checked back after weeks, or built a check that would catch a return.
Example answerRed flags
Example answer
Twice I 'fixed' late vendor deliveries by chasing harder. The third slip I stopped and mapped the chain: our own purchase orders went out late, so vendors deprioritized us. I moved PO cutoff a week earlier and added a flag for any order inside lead time. Deliveries have been on time for a year — chasing was never the fix.
Red flags
- The second attempt was the first attempt done louder.
- No check exists that would tell them if the problem returned a third time.
Questions 6–9
Problem solving questions about working with AI
2026 · AIWalk me through the last real problem you handed to an AI tool. What did you do when its first answer didn't work?
This tests iteration discipline. Strong candidates treat the failed first answer as information — they change the input, add missing context, or split the problem — rather than retrying the same prompt or giving up.
What to look for
- Diagnosed why the answer failed before asking again.
- Changed something specific on the retry: context, constraints, a smaller sub-problem.
- Knew when to stop — could name the point where doing it themselves became faster.
Example answerRed flags
Example answer
I asked a model to reconcile two exported customer lists and it kept matching on names — useless with duplicates. Instead of re-asking, I looked at what it was missing: a stable key. I had it match on email first and flag the 30 leftovers for me to do by hand — ten minutes instead of a day.
Red flags
- Retried the identical request several times hoping for a different result.
- Abandoned the tool at the first failure and now cites that as proof AI doesn't work.
Describe a problem where an AI tool kept you going in circles. How did you notice you were stuck, and how did you get out?
Strong answers name a real spiral — plausible answers that never quite land — and a concrete exit: a time limit, a switch to first principles, or a colleague. The skill being tested is noticing, not prompting.
What to look for
- Can describe the moment they realized effort was going in, nothing was coming out.
- Has a personal circuit-breaker: a time box, a rule of thumb, a person to call.
- The exit involved re-scoping the problem, not just more tooling.
Example answerRed flags
Example answer
Debugging a broken spreadsheet formula, I spent 40 minutes pasting variants into a chatbot — each 'fix' broke differently. My rule now is two failed rounds means the frame is wrong. I stopped, rebuilt the calculation on paper in ten rows, and saw the source data had merged cells. No prompt was ever going to find that.
Red flags
- Doesn't recognize the spiral pattern — the story is an hour of retries told as persistence.
- The only exit they know is escalating to someone else to break the loop for them.
When you take on a new problem, how do you decide which parts go to an AI tool and which you work through yourself? Give me a recent example.
A strong answer has an actual decision rule — verifiable and low-stakes goes to the tool, judgment and unfamiliar territory stays human — applied to a named recent problem, not stated as philosophy.
What to look for
- A rule they can state and that their example actually follows.
- The split hinges on verifiability: they delegate what they can check.
- Keeps the problem definition and the final call for themselves.
Example answerRed flags
Example answer
Last month I had to find why our best customers were downgrading. The model got the grunt work: summarizing 60 cancellation notes, drafting the interview guide. I kept the calls themselves and the conclusion — because the notes said 'price' but five calls said 'we stopped using it after your redesign'. The tool can't smell a polite lie.
Red flags
- No rule — the split is whatever they felt like that day.
- Delegates the framing of the problem itself, then works on whatever comes back.
Tell me about a time an AI tool gave you a fix that worked but that you didn't fully understand. What did you do before using it?
This probes the ship-versus-understand trade-off. Strong candidates scale verification to blast radius: they test the fix, understand at least its failure modes, and won't ship what they couldn't debug at 2am.
What to look for
- Names the specific thing they didn't understand, not vague modesty.
- Verified behavior with a test or a controlled trial before relying on it.
- Weighs blast radius: what happens, and to whom, if the fix breaks later.
Example answerRed flags
Example answer
An assistant gave me a one-line spreadsheet formula that fixed our commission report — array functions I'd never seen. Before trusting it, I ran it against last quarter, where I knew the right numbers by hand, and broke it on purpose with a blank row. Only then did it go in the live sheet, with a comment explaining it.
Red flags
- Shipped it because it worked once — understanding was someone else's problem.
- Refuses anything they didn't personally derive, even for trivial, testable tasks.
Questions 10–13
Live scenarios to watch problem solving happen
A routine process breaks this morning, the one person who understands it is away all week, and customers are starting to notice. Walk me through your first 30 minutes.
Strong answers triage in order: contain the customer impact first, then diagnose with what exists — docs, logs, the last person who touched it — and set a communication rhythm before diving deep.
What to look for
- Contains impact first — a stopgap for customers before any root-causing.
- Hunts for existing knowledge: runbooks, history, whoever touched it last.
- Tells someone what's happening and when they'll hear more, unprompted.
Example answerRed flags
Example answer
Minute one: how many customers, how bad — that decides everything else. If it's visible, support gets a holding line immediately. Then I'd trace the last change: most breaks follow a change. I'd message the expert one question they can answer from a phone — 'where would you look first?' — and post a status update before I go heads-down.
Red flags
- Spends the whole 30 minutes diagnosing while customers hear nothing.
- First move is declaring it blocked until the expert returns.
A tool your whole plan depends on will be unavailable for a week, and the deadline doesn't move. How do you rebuild the plan?
The strong answer resequences before it panics: pull forward everything that doesn't need the tool, find a manual or degraded substitute for what does, and renegotiate scope with whoever owns the deadline — with options, early.
What to look for
- Separates tool-dependent work from everything else and reorders around the outage.
- Looks for a degraded substitute — manual, partial, borrowed — and prices its cost.
- Goes to the deadline owner with options and a recommendation, not just bad news.
Example answerRed flags
Example answer
First I'd list what actually needs the tool — usually less than the plan assumes. That work moves to next week; everything else moves up. For the blocked part I'd ask what a manual version costs: if it's two days of tedium, that might beat slipping. The deadline owner gets three options and my pick on day one, not day four.
Red flags
- The plan's only change is compressing the same work into the remaining days.
- Doesn't tell the deadline owner until the slip is unavoidable.
Your manager hands you a one-line problem: 'Onboarding is losing customers — fix it.' What do you do before proposing any fix?
This tests scoping under vagueness. Strong candidates size the problem first — how many customers, where in the flow, since when — and come back with a narrowed problem statement before any solution talk.
What to look for
- First moves are measurement: how big, where exactly, when did it start.
- Talks to lost customers or watches real sessions, not just dashboards.
- Returns with a narrower, testable problem statement — and checks it with the manager.
Example answerRed flags
Example answer
I'd ask the data three questions: what share of signups we lose, at which step, and whether that changed recently — a new leak and a chronic one are different problems. Then five calls with people who quit. I'd come back with 'we lose 60% at the data-import step, here's why' — a fix proposal before that is a guess.
Red flags
- Proposes a redesign in the first breath — solution before size or location.
- Plans a quarter of research with no early checkpoint back to the manager.
You've tried the two obvious fixes and the problem is still there. It's mid-afternoon and this needed solving today. What's your next move?
Strong answers change strategy rather than intensity: question the assumption both fixes shared, shrink the problem to its smallest reproducible case, or add a fresh pair of eyes — and warn the stakeholder now, not at 6pm.
What to look for
- Asks what both failed fixes assumed — the shared assumption is the suspect.
- Shrinks the problem: smallest case where it still happens, or the last time it worked.
- Warns whoever's waiting while there's still time to react, and names a fallback.
Example answerRed flags
Example answer
Two failed fixes mean my model of the problem is wrong, so the next hour buys a better model, not a third fix. I'd find the smallest case that still fails and work back from the last time it worked. Explaining it to a colleague finds it half the time. The stakeholder hears 'at risk' at 3pm, not 6.
Red flags
- The next move is a third variation of the same idea, tried harder.
- Keeps the risk private to preserve the appearance of control.
Scoring rubric
| Score | Evidence anchor |
|---|---|
| 1 | Describes solutions with no visible process — problems 'got handled'. Can't reconstruct where they started, what they tried first, or why. Blocked means waiting. |
| 2 | Real problems, but the process is reactive: fixes symptoms, retries the same approach when it fails, and progress stalls whenever another person or a tool doesn't cooperate. |
| 3 | Scopes before solving and sequences work sensibly on familiar ground. Under pressure or in new territory the discipline slips — late escalation, workarounds that quietly become permanent. |
| 4 | Consistent method across stories: sizes the problem, tests the riskiest assumption first, routes around blockers, ships, and closes the loop on temporary fixes. Uses AI tools inside that process without surrendering it. |
| 5 | The process is explicit enough to teach: named decision rules, circuit-breakers for spirals, verification scaled to blast radius, and recurrence checks after every fix. Their problems stay solved, and their stories prove it with dates and numbers. |
Frequently asked questions
What are good interview questions about problem solving?
The best interview questions about problem solving ask for a real problem, then probe the process: where the candidate started, what failed along the way, and whether the fix held. Avoid brainteasers — they test puzzle practice, not work.
What are problem solving behavioral interview questions?
Problem solving behavioral interview questions ask candidates to walk through a problem they actually solved — 'tell me about a time…' — so you can inspect the real process they used. The first bucket above is built entirely from this type.
How is problem solving different from critical thinking in interviews?
Problem solving questions test execution: scoping, sequencing, unblocking, shipping a fix. Critical thinking questions test the reasoning behind conclusions and decisions. This page covers execution — see the critical thinking set for the judgment half.
How should candidates answer problem solving interview questions?
Expect candidates to narrate a tidy arc: problem, action, result. Your probes should test the untidy parts — what they tried that failed, when they escalated, what the fix cost. Candidates who did the work survive those follow-ups; rehearsed ones don't.
How many of these questions fit one interview?
Four or five with follow-ups fills a 45-minute round: two behavioral, one AI, one live scenario. Kira can run a broader subset by voice in a first-round interview, so your human round starts from transcripts instead of zero.