Interview questions · Problem solving

Interview questions for problem solving: 15 behavioral questions and how to evaluate the answers.

Field-tested behavioral questions for assessing analytical thinking, judgment under uncertainty, and creativity — plus the evaluation guidance most question banks skip.

How to use these questions

Don't ask all 15. Ask two or three — consistently.

Pick the questions that match what the role actually demands — analytical depth for a data role, calm triage for an on-call engineer, cross-functional influence for a product manager — and ask every candidate the same ones, in the same order. Consistency is what makes answers comparable: if each candidate gets a different interview, you end up comparing impressions, not evidence. Problem solving rewards a tidy narrative more than most competencies, so depth matters even more — two questions pursued through follow-ups beat six asked at the surface.

Decide what a strong answer covers before the interview.

Each question below includes “what to listen for” — turn those into the criteria on your scorecard.

Score immediately after the interview, not at the debrief.

Memory flattens fast, and the most confident storyteller shouldn't be the tiebreaker.

If you want question variants tuned to a specific role, the free AI interview question generator produces behavioral questions like these for any competency and seniority.

The questions

The 15 problem-solving interview questions.

Analytical depth and data

“Tell me about a complex problem you solved using data and analytics. What was your approach?”

What to listen for

They can explain why the data they chose was the right data, not just that they had a dashboard.
There's an actual interpretation step — they turned numbers into a decision, rather than letting the chart decide.
They name a limitation of the data and how they worked around it.

Follow-ups

How did you decide which data points actually mattered?
What did the data not tell you, and how did you handle that gap?

“Tell me about a time you identified a problem that others hadn't noticed yet. What was it, and how did you address it?”

What to listen for

They describe how they verified it was real and worth attention, not just a hunch.
They got others to take it seriously — a problem nobody acts on isn't solved.
They can say what would have happened if it had gone unaddressed.

Follow-ups

What signal or pattern made you notice it first?
How did you convince others it needed attention?

“Describe a situation where you had to solve a problem with incomplete information. How did you approach it?”

What to listen for

They separated what they knew from what they were assuming, and tested the assumptions.
They made a defensible call under uncertainty rather than freezing or waiting for perfect data.
They set up a way to course-correct as more became known.

Follow-ups

How did you decide you had enough to act on?
What would you have done if a key assumption turned out wrong?

“Tell me about solving a recurring problem by addressing its root cause rather than just treating the symptoms.”

What to listen for

They went looking for the cause with a method (five whys, fishbone, tracing the failure) rather than guessing.
They can distinguish the symptom they were tempted to fix from the cause they actually fixed.
Something they put in place kept the problem from coming back.

Follow-ups

How did you confirm you'd found the real root cause, not another symptom?
What stopped it from recurring after you fixed it?

Resilience and adaptability

“Describe a time when your initial approach to solving a problem didn't work. How did you pivot?”

What to listen for

They noticed it was failing reasonably early, from a real signal, rather than pushing on out of stubbornness.
They can explain why the second approach was different, not just that they tried again.
They took something from the failed attempt into the next one.

Follow-ups

What told you the first approach wasn't going to work?
How did you manage expectations while you changed course?

“Tell me about a time you had to quickly solve an unexpected problem. What was your process?”

What to listen for

There's still a process under the speed — they triaged rather than just thrashing.
They were explicit about the speed-versus-thoroughness tradeoff they made.
They followed up afterward rather than leaving a fragile fix in place.

Follow-ups

What did you deliberately skip to move fast, and was that the right call?
What would you have done differently with more time?

“Share an example of solving a problem under significant resource constraints — time, budget, people. How did you approach it?”

What to listen for

They prioritized ruthlessly and can explain the basis for it.
They found a creative way to do more with less, not just a way to ask for more.
They were honest about the tradeoffs the constraints forced.

Follow-ups

How did you decide what to cut?
What would have been different with the resources you wanted?

“Share an example of when you had to solve an ambiguous problem with no clear solution path. How did you approach it?”

What to listen for

They imposed some structure on the ambiguity — framed the problem, defined the boundaries — before solving.
They used a framework or mental model deliberately, not as a buzzword.
They knew what “good enough” looked like and stopped there.

Follow-ups

How did you create structure around something that started out shapeless?
How did you decide the solution was good enough to ship?

Collaboration and stakeholders

“Describe a situation where you solved a problem through collaboration. What was your specific role, and how did you work with others?”

What to listen for

They can isolate their own contribution honestly, neither hogging credit nor disappearing into “we.”
They made room for other people's input and changed their view when someone was right.
They handled disagreement about the approach without it stalling the work.

Follow-ups

What did you do when someone disagreed with your approach?
What did collaboration get you that solving it alone wouldn't have?

“Describe a time you solved a problem that affected multiple departments or stakeholders with different priorities. How did you handle it?”

What to listen for

They actually understood each group's real priority, not just their stated demand.
They found common ground or a fair tradeoff rather than picking a winner by default.
The solution held up across the parties, not just for the loudest one.

Follow-ups

How did you surface what each group actually needed?
Where did interests conflict, and how did you resolve it?

“Describe a situation where you had to solve a problem involving technical complexities you weren't initially familiar with. How did you approach it?”

What to listen for

They had a real learning strategy — the right resources, the right people — not just “I Googled it.”
They balanced learning fast against actually shipping a solution.
They came out of it more capable, and can say what they'd reuse next time.

Follow-ups

How did you find the right resources or people to learn from quickly?
How did you balance learning the area against solving the problem?

Impact and systems thinking

“Tell me about a time you implemented a solution that significantly improved a process or system. What was your approach?”

What to listen for

They diagnosed the current state before redesigning it.
They got the people affected on board and handled the resistance change creates.
They measured the improvement rather than asserting it.

Follow-ups

How did you get buy-in from the people the change affected?
How did you measure whether it actually improved things?

“Tell me about a problem you solved that required creative thinking or an innovative approach. What made your solution unique?”

What to listen for

They can explain why the conventional approach wasn't enough, so creativity was warranted.
They pressure-tested the creative idea for feasibility rather than just loving it.
They navigated the resistance an unconventional solution attracts.

Follow-ups

How did you check the creative idea would actually work before committing?
What resistance did the unconventional approach meet, and how did you handle it?

“Tell me about a time when you turned a problem into an opportunity. What was your mindset and approach?”

What to listen for

The reframe is genuine — a real upside they captured, not a problem they merely survived and relabeled.
They brought others along to see the opportunity, not just themselves.
There's an outcome beyond “we avoided the worst case.”

Follow-ups

When did you realize the problem held an opportunity?
How did you get others to see it that way?

“Describe a time when you solved a problem that had significant financial implications. What was your approach?”

What to listen for

They quantified the financial stakes rather than gesturing at “a lot of money.”
They weighed solutions on cost-effectiveness, not just on what was technically cleanest.
They can point to a financial outcome they tracked afterward.

Follow-ups

How did you estimate the financial impact?
How did you compare the cost and return of the options you considered?

Evaluation

How to evaluate the answers.

The questions get you stories. Evaluation is what turns stories into a hiring decision — and with problem-solving questions, the polished story is the trap.

Specificity

A real problem, real constraints, and a real outcome — ideally one they can quantify. Weak answers stay generic (“I broke it down and prioritized”) or describe the method in the abstract without ever landing on what they actually did.

The actual thinking, not just the framework

Strong candidates show the analysis and the judgment call inside it. Naming a framework — five whys, a 2x2, an MVP — proves nothing on its own; the signal is the decision they made within it and why.

Owns what didn't work

The best problem-solving stories include a wrong turn, a tradeoff, or a constraint they couldn't beat. An answer where everything went perfectly is usually a rehearsed answer, not a real one.

Reflection

What they'd do differently, what the experience taught them. “Why that approach and not another?” separates someone who reasoned their way to a solution from someone who got lucky once and kept the slide deck.

Red flags: a tidy framework with no real decision inside it; all outcome and no method; “we just brainstormed and it worked”; answers that can't survive one level of “why that approach and not another?”

Getting past a rehearsed answer is a matter of going deeper on one story rather than moving to the next question. Our guide to asking interview follow-up questions walks a single answer through seven dimensions — what to probe, and what each layer reveals.

Then put the judgment on a scorecard, not in your memory. Decide the criteria in advance (the “what to listen for” bullets are a starting set), rate each one independently right after the interview, and write down the evidence behind each rating. Scoring this way is what makes two interviewers comparable and a debrief about evidence rather than vibes. If you're assembling this from scratch, interview scorecard software exists to make that the default rather than a discipline you have to maintain by hand.

From questions to hiring evidence

Everything above works with a notebook.

The reason to systematize it is consistency at scale: the third problem-solving interview this month should be as rigorous as the first. Yardstick is a structured-interview ATS — teams create job-specific interview plans, run consistent interviews, and collect scorecards, so every interview produces usable hiring evidence. Questions like these live in an interview plan with the criteria attached; interviewers score against the same rubric; and AI assembles the evidence into a decision brief for the hiring team — with humans making the actual call. AI assists; the hiring decision stays with people.

You can start free: Yardstick's interview guide builder includes three lifetime interview guides, and the AI question generator is free to use. New to the approach? What is a structured interview explains the method these questions fit into.

Every interview produces usable hiring evidence when the criteria are set before the interview and scored on a scorecard.

FAQ

Common questions about problem-solving interviews.

Why use behavioral questions instead of hypothetical puzzles for problem solving?

Behavioral questions ask what someone actually did, which is a far better signal than a brainteaser or a “what would you do” hypothetical. Hypotheticals reward people who think well on their feet in an interview room; they don't tell you whether the candidate has done the messy, constrained, real-world version of the work. “Tell me about a time” forces a concrete example you can probe with follow-ups.

How many problem-solving questions should I include in an interview?

Two or three, explored deeply with follow-ups — not a checklist of ten. Problem solving especially rewards a smooth, well-structured narrative, so depth is your defense: one story pursued through “why that approach?” and “what did the data not tell you?” reveals more than six surface answers. If problem solving is central to the role, give it its own interview in the loop.

What should I look for in a candidate's answers — strong signals versus red flags?

Strong signals: a specific problem with real constraints, the actual thinking and decisions (not just a named framework), ownership of what didn't work, and reflection on what they'd change. Red flags: a tidy framework with no real decision inside it, all outcome and no method, “we just brainstormed and it worked,” and answers that fall apart on the first “why that approach and not another?” Score these against criteria you set in advance, rather than reacting to how confident the answer sounded.

How can I adapt these questions for different experience levels?

Keep the competency, change the scope. Early-career candidates can draw on coursework, projects, or a part-time job — the incomplete-information, ambiguous-problem, and quick-unexpected-problem questions work well. For mid-level roles, weight functional problems of moderate complexity. For senior roles, emphasize the cross-functional, root-cause, systems-improvement, and financial-impact questions, and expect answers with real organizational stakes.

How do I evaluate problem-solving skills objectively across different candidates?

Decide the criteria before the interviews — problem definition, analysis, decision-making, execution, and reflection are a good starting set — and rate every candidate against the same ones, using concrete examples from their answers. Score independently right after each interview and write down the evidence behind each rating, then compare candidates on those notes rather than on who sounded most polished. A scorecard disciplines that decision; it shouldn't automate it — keep human judgment in the loop.

Run the interview, keep the evidence.

Generate role-specific behavioral questions for free, or see how Yardstick connects questions, scorecards, and hiring decisions in one workflow.

Generate interview questions See how Yardstick works