Problem-Solving Interview Questions: 12 Questions & Worked STAR Answers
Problem-solving is a core competency at every employer. Here's exactly how to answer every variant — with worked examples for graduates, career changers, and experienced professionals.
What Interviewers Are Really Assessing
Problem-solving questions appear in nearly every competency-based interview. Employers frame them many ways: "Tell me about a time you solved a difficult problem," "Describe a situation where you had to think creatively," "Give me an example of when you identified an issue and resolved it." Despite different wording, they all probe the same underlying competency.
Interviewers are not primarily interested in whether the problem was difficult or the solution was clever. They are assessing a specific set of cognitive and behavioural traits:
| What They're Assessing | What It Looks Like in Your Answer |
|---|---|
| Structured thinking | You broke the problem into components before trying to solve it. You did not jump straight to a solution. |
| Evidence-based reasoning | You gathered data, tested assumptions, or validated your diagnosis before acting. |
| Autonomy and initiative | You took ownership of the problem rather than waiting for someone to tell you what to do. |
| Impact orientation | The solution you found actually improved something measurable — not just "it worked out." |
| Learning agility | You reflected on what you would do differently and applied that learning to future situations. |
A candidate who solved a modest logistical problem with clear structured thinking will score higher than one who solved a complex problem through luck or brute force. Interviewers are hiring for a repeatable process, not a single brilliant outcome. Show your thinking, not just the result.
STAR Framework for Problem-Solving Answers
The STAR framework (Situation, Task, Action, Result) is the standard structure for all behavioural interview answers. For problem-solving specifically, the Action section benefits from an additional sub-structure.
- Situation (15%): Briefly set the scene. What was the context and what was the nature of the problem? Quantify the problem if possible — "a 23% error rate in our data pipeline" is stronger than "there were some data issues."
- Task (10%): What was your specific responsibility? What was at stake if the problem wasn't resolved?
- Action (55%): The core of your answer. Walk through your problem-solving process: (1) How did you diagnose the root cause? (2) What options did you consider? (3) How did you decide on your approach? (4) How did you implement and iterate? Use "I," not "we."
- Result (20%): What was the measurable outcome? What did you learn? Have you applied that learning since?
The most common mistake in problem-solving answers is jumping from "there was a problem" straight to "here is what I did to fix it." A strong answer spends time explaining how you diagnosed the root cause before acting. This is what demonstrates structured thinking rather than reactive firefighting.
Analytical Problem-Solving — 3 Worked Examples
These examples involve problems requiring data analysis, logical reasoning, or quantitative investigation — common in consulting, finance, technology, and strategy roles.
S During my finance internship, the team was struggling to understand why a client's gross margin had declined 8 percentage points over 18 months despite stable revenue growth. Multiple theories were circulating but no one had pinpointed the root cause.
T My manager asked me to investigate and come back within two days with a root cause analysis and recommendations.
A I started by building a simple decomposition tree: margin = revenue minus COGS, so I needed to separate pricing effects from volume effects from cost effects. I obtained three years of monthly transaction data from the client's finance team and segmented by product line, customer type, and region. This revealed that the margin decline was almost entirely concentrated in one product line and one customer segment — the two largest enterprise accounts. I dug deeper and found that both accounts had negotiated retroactive volume discounts 18 months earlier that were being applied inconsistently in the billing system, creating an effective price reduction that hadn't been flagged in the P&L commentary. I validated this with the finance controller before presenting my findings, to make sure I wasn't misreading the data.
R The root cause turned out to be a billing system configuration error, not a commercial or pricing strategy issue. The client fixed the billing system and recovered approximately £180k in under-billed revenue. My manager described the analysis as the most thorough he had seen from an intern and included it in the engagement final report.
S As social media officer for our university's student newspaper, engagement had dropped 40% over six months and the editorial team assumed it was a content quality issue. We were about to commission a complete rebrand.
T Before committing to a costly rebrand, I wanted to test whether the content was actually the problem or whether there was a different root cause.
A I pulled three months of post-level analytics from Instagram Insights and built a simple spreadsheet tracking engagement rate by post type, day of week, and time of day. The data showed something unexpected: our engagement rate per post had not declined — but our post frequency had increased by 70%, flooding our followers' feeds. Reach per post had dropped sharply as a result of algorithmic suppression of accounts that post too frequently without proportional engagement. I cross-checked this with two competitor student publications whose engagement had remained stable — they were posting at roughly half our current frequency. I prepared a one-page recommendation: reduce posting frequency by 50%, prioritise quality over volume, and test a new weekly newsletter format.
R After implementing the changes, engagement per post increased 65% over the following eight weeks. We shelved the rebrand. I presented the analysis at the editorial team meeting and the editor-in-chief adopted the data-first content review as standard practice.
S While preparing a financial model for a client pitch at my internship, I noticed that the working capital assumptions in one section were inconsistent with the cash flow projections in another. The discrepancy was small — about £50k — but in a model with £5m in projected annual revenue, small inconsistencies can indicate structural errors.
A Rather than accepting the discrepancy or simply flagging it to my manager, I traced every working capital line back to its source input. After 90 minutes I found that the accounts receivable days assumption was different in two separate parts of the model — one section used 45 days from the client's current performance, the other used 30 days from an industry benchmark table I had built. Neither was wrong, but they needed to be consistent. I also found a secondary issue: the tax calculation was using nominal rather than effective tax rates. I corrected both, documented the changes clearly in the model version log, and then briefed my manager before the partner reviewed the model.
R The corrected tax assumption changed the projected IRR by 1.1 percentage points — significant for a PE client evaluation. My manager told me that catching the inconsistency before the partner review had saved the team from significant embarrassment. The pitch was successful.
Process or System Failures — 3 Worked Examples
These involve operational failures, broken processes, or systems that aren't working as intended — common in operations, technology, project management, and general management roles.
S At my part-time retail job, the stock replenishment process for high-demand items relied on manual weekly counts by floor staff. This consistently resulted in popular items being out-of-stock for 2–3 days before reorders were placed, which was visibly frustrating customers.
A I raised it with my supervisor and asked if I could investigate the root cause. I tracked the timing of out-of-stock events over four weeks and mapped them against when floor counts were done. The pattern was clear: counts happened on Mondays, but high-demand items typically sold through by Friday afternoon. I proposed a simple fix: daily threshold alerts for the 20 fastest-moving SKUs, triggered when stock fell below a reorder point I calculated based on average daily sales. I built the threshold list in a shared spreadsheet and trained three colleagues on how to update it. I piloted it for two weeks before presenting the results to my manager.
R Over the following month, out-of-stock incidents for those 20 SKUs dropped by 80%. My manager adopted the system store-wide and cited it in my performance review as an example of showing initiative beyond my role. I learned that operational problems often have simple systemic solutions — the barrier is usually that no one has taken ownership of diagnosing the root cause.
S In my placement year role, the monthly financial reporting process required two team members to spend approximately 12 hours manually formatting data exported from three different systems into a single Excel template. This happened every month without question.
A I asked to shadow the process once to understand it fully before suggesting changes. I identified that approximately 70% of the formatting work was repetitive and rule-based. I spent three evenings building a macro in Excel that automated the data import, applied the formatting rules, and generated the standard outputs. I tested it against three months of historical reports to verify accuracy, documented how it worked, and trained both team members who had been doing the manual process.
R The monthly process time dropped from 12 hours to under 2 hours. Over the course of the year, this saved approximately 120 person-hours. My manager escalated the solution to the wider finance team and it was adopted for two additional reporting processes. I was cited in a team recognition award at year-end. This taught me that inefficiencies in stable processes often persist simply because no one questions them.
S The evening before a major group presentation worth 35% of a module grade, our shared slide deck was corrupted after a teammate accidentally saved over the main file with an older version. We lost approximately four hours of work, including the final data analysis slides.
T We had 14 hours before the presentation. The group was panicking. As the team lead, I needed to triage quickly.
A I immediately stopped any further attempts to recover the file — each failed attempt was risking further corruption. I sent the corrupted file to two tech-savvy friends to attempt recovery in parallel. While waiting for that outcome, I allocated the team to rebuild from memory: I took personal responsibility for recreating the analysis because I had drafted the original. I asked two teammates to focus on the slides they each owned, and I asked the fourth to compile our reference sources so we had everything we needed. I also identified which slides were genuinely essential versus which added context — we rebuilt only what was critical. After 90 minutes one recovery attempt succeeded, recovering a version from earlier that day. We only needed to redo two hours of work instead of four.
R We presented on time with a complete deck. We received a 2:1 grade. More importantly, we implemented a simple cloud backup process going forward. Under pressure, my instinct was to triage — stop the bleeding, assess what's recoverable, rebuild in parallel — and I found that approach holds up well.
Creative Solutions Under Constraints — 3 Worked Examples
These questions probe lateral thinking, resourcefulness, and the ability to generate solutions when the standard approach isn't available.
S As events officer for a university society, our main annual event fell through when the venue cancelled two weeks beforehand due to a booking conflict. We had 200 ticket-holders, a booked performer, and catering arranged.
A I first made a list of constraints: we needed a venue available on the original date, capacity for 200+, catering facilities, and ideally within our existing budget. Rather than approaching mainstream event venues (which were either unavailable or vastly over-budget), I contacted three university departments with large seminar spaces, two local businesses with event spaces that I knew from a previous event, and one local hotel that the university had a preferred supplier relationship with. I also reached out to another society that had a venue relationship I knew about. Within 48 hours I had three viable options. I evaluated them against the constraints, negotiated a 40% rate reduction with the hotel by offering to write a case study for their events website, and confirmed the booking within 72 hours of the original cancellation.
R The event ran on the original date with 185 of the 200 attendees present. Post-event feedback was the highest we had recorded. I also built a venue backup list for all future society events as a standard contingency measure.
S During a university consulting competition, our team needed to produce market sizing research for a sector we had no prior knowledge of, in 48 hours, with no access to paid databases or external experts.
A I started by mapping what was freely available: annual reports from public companies in the sector, ONS and government statistical datasets, and academic papers via the university library. I also identified three people in my network who had direct sector experience and reached out for 20-minute informal interviews, framing it clearly as student research rather than a commercial engagement — which they were generally willing to support. I used these to pressure-test the assumptions I had derived from the secondary sources. Rather than trying to build a bottom-up market size from scratch, I triangulated three different approaches — revenue multiples from comparable public companies, headcount data from LinkedIn for private firms, and a top-down from total addressable market estimates in government reports — and then averaged them with explicit uncertainty ranges.
R Our market sizing analysis was cited by the judges as the most rigorous of the eight competing teams. One judge — a sector specialist — told us that our triangulation approach was the methodology he uses in his own practice. I learned that resourcefulness is less about what you don't have and more about systematically using what you do have.
S On a research project studying graduate employment outcomes, our team's primary data collection method — an in-person survey — was disrupted mid-project when a key partner university withdrew access following a policy change. We had 40% of our target sample and no budget to replace it.
A I mapped the consequences: we couldn't hit our original target sample with in-person methods. I asked two questions: what minimum sample gave us statistical validity, and what data sources could supplement what we had? The answer to the first question was that 40% of target was borderline — significant but not sufficient on its own. For the second, I identified LinkedIn as a proxy data source for employment outcomes, cross-referencing against publicly available graduate survey data from HESA. I proposed supplementing our primary data with a targeted online survey distributed through LinkedIn to members matching our target demographic, combined with HESA data to provide external validation. I drafted the approach and shared it with our supervisor before implementing.
R Our supervisor approved the hybrid methodology. We hit 80% of our original target sample through the combined approach, and the supervisor noted that the HESA comparison actually strengthened the research rather than weakening it. The project was submitted on time and received a Distinction.
Problem-Solving Under Pressure — 3 Worked Examples
These examples combine problem-solving with time pressure, high stakes, or incomplete information — all of which are common in real professional environments.
S As shift supervisor at a catering venue during a large event, our main supplier's delivery arrived 40 minutes late and was missing one-third of the ingredients for the evening's main course — with 200 guests arriving in 90 minutes.
A I had three options: wait for a re-delivery (unlikely in 90 minutes), substitute with available stock (possible but would change the dish), or inform the event organiser immediately and offer an alternative menu item. I spent five minutes assessing feasibility: the missing items were protein-based and could not be replaced from our stock without a fundamentally different dish. Waiting was not viable. I made the call to inform the event organiser immediately, before they heard from a guest — giving them maximum time to manage their guests' expectations. I simultaneously asked the chef to develop a substitute dish using available stock and had a cost estimate ready within 10 minutes. The event organiser appreciated the early warning and chose the substitute option. I also called our supplier to request a partial credit for the delivery failure.
R The event ran smoothly. The organiser later wrote a positive review specifically mentioning the professional handling of the supply issue. I learned that under time pressure, being transparent and fast is almost always better than trying to solve the problem invisibly.
S During exam period, I was simultaneously managing a society event I had organised, completing a deadline-critical dissertation chapter, and covering for an absent colleague at my part-time job. All three had demands landing in the same 72-hour window.
A I spent 30 minutes writing down every pending action across all three workstreams and categorising each by deadline and consequence of failure. The dissertation chapter was non-negotiable — missing that deadline would affect my degree grade. The event had a natural team I could delegate to; I identified four specific tasks I could hand to committee members and briefed them clearly. The work cover was the most flexible — I negotiated with my manager to shift my hours to non-peak times, which she agreed to. Having mapped everything explicitly, I was able to commit each hour of the 72-hour window to a specific output without the anxiety of feeling like everything was equally urgent.
R All three commitments were met. The dissertation chapter was submitted on time, the event ran successfully with no significant issues under delegated management, and I covered my work shifts without any impact on the team. I now build a "task triage" as a routine step whenever I feel overloaded rather than trying to manage everything mentally.
S For my dissertation, I was investigating whether a specific pricing anomaly in energy derivatives markets was explained by liquidity risk or by regulatory constraints. The challenge was that no single dataset contained all the variables I needed, and the academic literature had conflicting findings.
A I started by mapping what each existing explanation predicted empirically and identifying which predictions were observable in publicly available data. I sourced tick data from three separate platforms and merged them — which required significant data cleaning and alignment. Rather than choosing between the competing hypotheses, I designed a test that could distinguish between them: if liquidity was the primary driver, the anomaly would cluster around low-volume periods; if regulation was primary, it would cluster around reporting dates. I ran the analysis, found the data strongly supported the regulatory explanation, and then sought out two counter-examples that would challenge my conclusion — to make sure I wasn't confirmation-biased. The counter-examples turned out to have specific structural characteristics that actually strengthened the regulatory hypothesis when examined closely.
R My dissertation received a Distinction. My supervisor submitted it for a departmental prize, which it was shortlisted for. More importantly, the discipline of adversarial testing — actively trying to disprove my own conclusion — is something I now apply in any analytical work. It makes the analysis more robust and more credible to others.
Structured Problem-Solving Frameworks
For consulting interviews and analytical roles, referencing a structured problem-solving approach signals professional-grade thinking. You don't need to name a framework explicitly, but demonstrating you used one is highly effective.
| Framework | When to Use It | What It Looks Like in an Answer |
|---|---|---|
| Issue Tree / MECE | Complex analytical problems, business cases | "I broke the problem into its mutually exclusive components: price, volume, and cost. Then I tested each one systematically." |
| Root Cause Analysis (5 Whys) | Process failures, operational problems | "I kept asking why until I got to a root cause that was actionable, rather than treating the symptom." |
| Impact/Effort Matrix | Prioritisation problems, multiple solutions available | "I mapped each option against its impact and implementation effort to identify the highest-leverage action." |
| Hypothesis-Led Analysis | Consulting, research, analytical roles | "I started with a hypothesis, identified what data would disprove it, and tested it — rather than building the full analysis first." |
| Decision Tree | Uncertain outcomes, multiple decision paths | "I mapped the key decision points and outcomes, which made the trade-offs explicit and easier to discuss with the team." |
Using a framework doesn't require formal labels. Simply demonstrating that your thinking was structured — that you decomposed the problem, tested assumptions, and evaluated options systematically — signals exactly what these frameworks teach.
For roles that involve aptitude tests, note that the numerical reasoning test and Watson Glaser critical thinking test directly assess the same structured analytical thinking you demonstrate in problem-solving interview answers.
Common Mistakes to Avoid
- Jumping straight to the solution. A strong answer spends meaningful time on diagnosis — how you understood the problem before acting. Interviewers who see candidates skip straight to solution-mode assume they are reactive rather than analytical.
- Choosing a trivial problem. "I figured out a better way to organise my email folder" does not demonstrate meaningful problem-solving capability. Choose a problem with genuine professional or academic stakes.
- Describing a group effort as your own. "We solved the problem" tells the interviewer nothing about you. Use "I" throughout the Action section. If others were involved, you can mention them briefly, but the focus must be on your specific contribution.
- Failing to quantify the outcome. "It worked out well" is weak. "Reduced processing time by 40%," "recovered £180k in revenue," or "saved 120 person-hours annually" are strong. Always try to quantify the Result.
- Not including a learning. Problem-solving questions frequently end with "what did you learn?" Even if the interviewer doesn't explicitly ask, adding a genuine learning point shows self-awareness and growth orientation — both highly valued competencies.
If your answer ends with "I brought it to my manager and they solved it," you have described problem identification, not problem-solving. The question is asking for an example where you drove the resolution. It's fine to involve others, but the core diagnostic and resolution process should feature you as the primary driver.
Frequently Asked Questions
Prepare for Every Interview Competency
Problem-solving is just one of the competencies you'll face. Practice aptitude tests alongside your interview prep to ensure you pass every stage.