Tell Me About a Time You Solved a Difficult Problem
Every graduate scheme asks a version of this question — and most candidates answer it by describing the problem in detail and rushing past the one thing interviewers actually care about: what you did. Here's how to fix that.
Why Employers Ask This Question
"Tell me about a time you solved a difficult problem" (or one of its close relatives — "describe a challenge you faced and how you overcame it," "tell me about a time you found a creative solution") is one of the most frequently asked competency-based interview questions across graduate schemes. It appears in first-round phone interviews, HireVue-style video interviews, and assessment centre panel interviews alike, because problem-solving sits near the top of almost every employer's competency framework — alongside teamwork, leadership, and resilience.
Unlike a purely technical question, this one is not really testing whether you can solve puzzles. It is testing your process — how you approach uncertainty, break a messy situation into something workable, and follow through when the obvious answer isn't available. Interviewers are listening for evidence of structured thinking under real constraints, not just a happy ending.
| What Interviewers Are Really Assessing | Signal | Why It Matters to Them |
|---|---|---|
| How you define the problem | Analytical clarity, ability to isolate the real issue | Junior employees who misdiagnose a problem waste time solving the wrong thing |
| The options you considered | Breadth of thinking, willingness to weigh trade-offs | Shows you don't jump to the first idea without considering alternatives |
| The action you actually took | Initiative, ownership, follow-through | Distinguishes candidates who acted from those who merely identified the issue |
| How you handled setbacks mid-solution | Resilience, adaptability | Real problems rarely resolve on the first attempt — employers want to see persistence |
| What you'd do differently | Self-awareness, continuous improvement mindset | Reflective candidates are seen as lower-risk long-term hires |
Interviewers do not expect a story about turning around a failing department. A candidate who clearly and specifically describes how they diagnosed and fixed a scheduling clash for a five-person student project will consistently outscore a candidate who vaguely describes "solving a major operational issue" they can't actually explain step by step. Precision beats scale.
This question also tends to generate genuine follow-up probing — "what else did you try?", "how did you know that was the right call?" — because interviewers want to check the story is real and not just a rehearsed script. That makes preparing the underlying facts of your example, not just the headline narrative, essential.
How to Choose the Right Problem
Most candidates struggle with this question not because they've never solved a problem, but because they haven't decided which one best proves they can think under pressure. Before drafting an answer, test every candidate story against these five filters.
| Filter | Ask Yourself |
|---|---|
| Genuine ambiguity | Was there no single obvious "correct" answer available from the start — did you actually have to work it out? |
| Real constraints | Was there a limit on time, resources, information, or authority that made the problem genuinely harder to solve? |
| Your own reasoning | Can you explain why you chose your approach over the alternatives, not just what you eventually did? |
| A concrete resolution | Did the problem actually get resolved — even partially — rather than trailing off unresolved? |
| Something you can defend under questioning | Could you comfortably answer two or three probing follow-up questions about the details? |
Good sources if you have limited work experience
Problem-solving stories do not need to come from a job. Strong examples regularly come from group coursework (resolving a data or methodology issue in a dissertation), part-time or hospitality work (fixing a recurring rota or stock problem), society or committee roles (resolving a budget shortfall or a logistics clash), and personal projects (debugging a side project, reworking a training plan after an injury). What interviewers assess is the thinking, not the setting.
The strongest answers describe a state that was genuinely broken or stuck, and a state afterwards that was measurably better — a missed deadline avoided, a recurring error stopped, a group that was going to fail a deadline that then met it. If you can't clearly separate the "before" from the "after," the story will struggle to land as a real problem that was actually solved.
The DARE Framework
Structure your answer using DARE — a problem-solving adaptation of the standard STAR interview technique that puts extra weight on how you reasoned through the problem, since that reasoning is exactly what this question is designed to surface.
| Step | What to Cover | Roughly How Long |
|---|---|---|
| D — Define | What the problem actually was, why it mattered, and what made it genuinely difficult (ambiguity, constraints, stakes) | 20–25% of your answer |
| A — Analyse | The options you considered and why you ruled some out — this is where analytical thinking shows | 15–20% |
| R — Resolve | The specific action you took, including how you adapted if your first attempt didn't fully work | 30–35% |
| E — Evaluate | The concrete outcome, plus what you learned or would do differently next time | 20–25% |
Why "Analyse" is the step most candidates skip
Under time pressure, most candidates jump straight from describing the problem to describing what they did — skipping the reasoning in between. That skip is costly, because the Analyse step is exactly what separates "I solved a problem" from "I can think through a problem." Even a single sentence — "I considered X, but ruled it out because Y, so I went with Z instead" — gives the interviewer direct evidence of judgement, not just outcome.
That's roughly 220–320 words. Practise your answer out loud with a timer rather than reading it silently — spoken delivery is reliably slower than most candidates expect, and a rambling six-minute answer to this question is a common reason otherwise strong candidates lose the interviewer's attention halfway through.
6 Example Answers by Background
Below are six condensed scenarios covering different starting points, so you can adapt the underlying structure to your own experience instead of forcing a script that doesn't fit.
| Background | Problem Example | Key Skill Demonstrated |
|---|---|---|
| Group coursework / dissertation | A core data source became unavailable weeks before a deadline, forcing a redesign of the research methodology | Analytical adaptability, resourcefulness under deadline pressure |
| Part-time retail/hospitality job | Diagnosing why a particular shift consistently ran short-staffed and proposing a rota fix that management adopted | Root-cause analysis, initiative, stakeholder buy-in |
| Society or committee role | Resolving a double-booked venue clash for two events happening the same week with no budget for a second venue | Negotiation, resourcefulness, calm decision-making |
| Sports team or captaincy | Working out why a consistently strong team was losing close matches, and identifying a tactical or fitness gap to address it | Diagnostic thinking, structured problem-solving under pressure |
| Internship or placement year | Spotting a recurring error in a manual process and building a simple checklist or spreadsheet fix that reduced it | Attention to detail, initiative, practical process improvement |
| Personal project | Debugging a persistent, hard-to-reproduce fault in a personal coding or DIY project through systematic elimination | Patience, methodical troubleshooting, technical resilience |
Full worked example
"During my final-year group project, the dataset our entire analysis depended on was withdrawn by the provider three weeks before submission, with no direct replacement available. The problem was that our whole methodology had been built around that specific dataset's structure, and simply switching to a different dataset would have meant redoing most of our analysis from scratch with only three weeks left. I considered two options: requesting an extension, which our department rarely grants, or finding a substitute dataset and adapting our method rather than starting over. I spent a day identifying two publicly available alternatives, tested which one most closely matched our original variables, and proposed to my group that we restructure two of our four analysis sections around it rather than all four, keeping the parts that didn't depend on the missing data unchanged. We finished a day before the deadline and actually received positive examiner feedback on how we'd handled the methodology change transparently in our write-up. It taught me that under a hard deadline, a good-enough adapted plan executed quickly beats waiting for a perfect solution — which is exactly the kind of pragmatic thinking I'd bring into a fast-moving graduate role."
It states the constraint plainly (three weeks, no direct replacement), shows two options being weighed rather than jumping to the first idea, names a specific action taken (testing alternative datasets, restructuring only two of four sections), gives a concrete result (finished a day early, positive feedback), and closes with a reflection tied to the role — all in under 200 words.
Employer-Specific Angles
The DARE structure stays constant, but which part of it to emphasise shifts depending on the employer. Research each employer's published competency framework and lean your emphasis toward what they say they value most.
| Employer | What They Tend to Value in This Answer |
|---|---|
| Goldman Sachs | Rigorous, structured reasoning through the Analyse step; comfort being pressed on why you ruled out alternatives |
| PwC / Deloitte / EY / KPMG | Problem-solving within a team or client context, and clear communication of the resolution to stakeholders — these firms explicitly list problem-solving among their core graduate competencies |
| Amazon | Ownership of the fix and a bias for taking action quickly rather than waiting for perfect information — themes that map onto Amazon's published Leadership Principles |
| Microsoft | A growth-mindset framing: what the problem taught you and how your approach to similar problems has evolved since |
It's tempting to sprinkle in phrases lifted from a careers page to sound aligned with a firm's culture — but experienced interviewers notice when a candidate is performing corporate vocabulary rather than genuinely connecting their story to the role. Let the problem and your reasoning speak for themselves, and make any explicit connection briefly in the Evaluate step, not by repeating buzzwords throughout.
Problems to Avoid
Not every problem you've faced makes a strong interview answer, even if solving it felt satisfying at the time. Some categories consistently undermine rather than strengthen your case.
| Type of Problem | Why It Tends to Fall Flat |
|---|---|
| Problems caused entirely by someone else's mistake | If the story is really about someone else failing and you cleaning up after them, it can read as blaming rather than problem-solving |
| Purely technical puzzles with no human or business context | A logic puzzle you solved for fun demonstrates aptitude, not judgement under real-world constraints — pair it with context if you use one |
| Problems that were solved by luck rather than your action | If the problem would have resolved itself regardless of what you did, there's no genuine skill to evaluate |
| Problems still unresolved by the end of your story | An account that trails off without a clear resolution leaves the interviewer unsure whether your approach actually worked |
| Anything requiring extensive unrelated backstory | If you need two minutes of context before the actual problem starts, it eats into your limited answer time |
When choosing between two candidate stories, pick the one you can go two or three follow-up questions deep into without hesitation. Interviewers regularly probe this answer further — "what would you have done if that hadn't worked?" is a common one — so the story needs to hold up under scrutiny, not just sound good on the first pass.
5 Mistakes That Undermine Your Answer
- Mistake 1: Spending most of the answer describing the problem and rushing the solution. The Resolve step is where you actually demonstrate problem-solving — it should be the longest part of your answer, not an afterthought.
- Mistake 2: Skipping the reasoning behind your chosen approach. Stating what you did without saying why — or what else you considered — leaves the interviewer unable to assess your judgement, only your luck.
- Mistake 3: Describing a problem that wasn't genuinely difficult. If the "problem" had an obvious single solution that anyone would have reached immediately, it does not showcase problem-solving ability.
- Mistake 4: Leaving out what happened when your first attempt didn't fully work. Real problems rarely resolve in one clean step — omitting any adaptation makes the story feel rehearsed and less credible.
- Mistake 5: Ending on the result with no reflection. Without a brief closing thought on what you learned, the interviewer is left to guess why this story, of all the ones you could have told, was the one you chose.
Frequently Asked Questions
Practise the Tests That Come Before the Interview
A strong problem-solving answer gets you through the interview — but most graduate schemes screen with a numerical, verbal, or inductive reasoning test first. Practise the SHL-style tests employers actually use, then read the full problem-solving question bank to prepare for every variation of this question.