Interview questions by topic
Problem solving interview questions, with sample answers
IraAI writerAI interviewing editor
Published by the Itya team · Updated
7 questions · strong and weak answers in candidates' words · anchored 1-to-5 scale
Answers from Nitin, Aparna and Ajay, three illustrative candidatesWhat interviewers listen for
- The problem defined before the solution. Who has the problem, what it costs, and what 'solved' would look like, before anyone builds anything.
- Hypotheses, tested in a sensible order. A few possible causes, the likeliest or cheapest to check first, and the evidence that ruled each one in or out.
- Evidence, and its limits. Data used to decide, with a sense of what the numbers can't show and who to ask about the rest.
- Their own reasoning. What the candidate thought and did, step by step, even when a team solved it together.
- Checking that it worked. How they confirmed the fix held, and what they changed so the problem stays solved.
Meet the candidates
Three candidates from different jobs answer the questions below. Each is strong on some and thin on others, the way real candidates are, so you hear both kinds of answer side by side.
Nitin Goyal
Supply chain analyst, pharmacy retail · 7 years · Jaipur
Plans stock for a chain of sixty pharmacies across Rajasthan. Good at turning a vague problem into numbers he can test, and at listening to the people in the stores; uneasy deciding before the data is complete.
Aparna Menon
QA engineer · 4 years · Kochi
Tests a hospital appointment app used by clinics across Kerala. Methodical at reproducing and isolating bugs; less sure where to start when a problem arrives without a clear definition.
Ajay Rathore
Plant maintenance manager · 22 years · Pune
Keeps the machining lines running at an auto-components plant. Superb at tracing faults on the shop floor and calm when a line is down; trusts his own experience over spreadsheets, and over other people's ideas.
Illustrative people. The names are invented, the portraits are AI-generated, and their words were written by our AI writers to show what candidates sound like. Any resemblance to a real person is a coincidence.
The questions
Tell me about the hardest problem you've solved at work. How did you work out what was really going on?
Whether the candidate has a method for getting from symptoms to a cause, and can explain their own reasoning rather than the team's result.
Follow up with
- What did you think it was at first, and how did you rule that out?
- What evidence convinced you that you'd found the cause?
- What would you do faster next time?
Ajay RathorePlant maintenance manager · 22 years · Pune“A CNC line making brake-caliper housings was failing the bore-size check on about one part in fifty, only on the night shift. Everyone blamed the operators, so I spent one night watching them: they were following the procedure exactly. So I asked what else was different at night. Same machines, programs and tools. But the loading-bay shutters stayed open for dispatch, and on winter nights the shop was about six degrees colder by 3 a.m. I had the bores measured hourly for three nights, against the temperature: failures started below about 22 degrees. The spindle wasn't warming up properly after the night break. We added a ten-minute warm-up cycle after breaks and closed the shutter nearest that line. Rejects fell to nearly zero, and the operators were cleared.”
What makes it strong
Describes the symptoms, the hypotheses they formed, how they tested and ruled each one out, the evidence that pointed to the real cause, the fix, and how they confirmed it held. Their own reasoning is clear even when others helped.
Aparna MenonQA engineer · 4 years · Kochi“The hardest was a bug where some patients' appointments disappeared from the app. It took the whole team about two weeks. We tried a lot of different things, and in the end one of the developers worked out it was a time zone problem. It was really satisfying when it was finally fixed.”
What gives it away
Tells the story as 'we' with no reasoning of their own, jumps from problem to solution, or credits luck. Cannot say what was ruled out or why.
Tell me about a time you were handed a problem that was vague or badly defined. What did you do first?
Whether the candidate turns an ambiguous request into a defined problem, with a measure of success, before trying to solve it.
Follow up with
- Who did you talk to, and what did you ask them?
- How did you know what 'solved' would look like?
- What did you decide to leave out?
Nitin GoyalSupply chain analyst, pharmacy retail · 7 years · Jaipur“My manager said, "We're throwing away too much expired stock. Sort it out." That could mean twenty things. First I asked how much: write-offs were 2.1 percent of sales, and finance wanted them nearer one. I called five store managers, then split the write-offs by product and store. It was really three problems: slow movers stocked in every store, short-dated stock from one distributor, and stores not putting older stock in front. I wrote one page with the goal, write-offs at 1.2 percent of sales in six months, measured monthly, and agreed it with my manager before doing anything. We started with the slow movers. By month five we were at 1.4.”
What makes it strong
Finds out who has the problem and what it costs them, breaks it into smaller questions that can be answered, writes down what success would look like, and agrees that definition with the person who asked before doing the work.
Aparna MenonQA engineer · 4 years · Kochi“When a product owner tells me something like "the app feels slow", I ask for proper requirements first: which screens, what response time is acceptable. Until that's written down, I can't really test it. So I raised it in sprint planning and asked them to create a ticket with acceptance criteria.”
What gives it away
Waits for someone else to define it, starts building the first solution that comes to mind, or asks for 'clear requirements' and goes no further.
Tell me about a decision you made based on data. What did the data tell you, and what couldn't it tell you?
Whether the candidate uses evidence to decide, and knows the limits of the numbers they relied on.
Follow up with
- Where did the data come from, and how did you check it?
- What would have changed your mind?
- What did the data miss?
Nitin GoyalSupply chain analyst, pharmacy retail · 7 years · Jaipur“We were deciding whether to stock a costlier insulin brand in all sixty stores. Sales data said demand was small, about forty units a month across the chain. But sales only show what we had on the shelf, not what customers asked for. So I asked stores to log every request they couldn't fill for four weeks: nearly two hundred a month, mostly in twelve stores near two big hospitals. I recommended stocking those twelve only, with a reorder level for each, and a review after a quarter. Sales in those stores reached about 170 a month. What the data couldn't tell me was why; the pharmacists could. Doctors at those hospitals prescribed it.”
What makes it strong
Names the decision, the data and where it came from, how they checked it, what it showed, what it couldn't show and how they covered that gap (asking people, a small trial), and what happened after.
Ajay RathorePlant maintenance manager · 22 years · Pune“To be honest, in maintenance, after twenty years you know which machines will give trouble. Last year I decided to replace the hydraulic units on two old presses before they failed. Management wanted downtime data to justify it, so I pulled the numbers together afterwards. My feeling was right; both units were in bad shape.”
What gives it away
Decides on instinct and pulls numbers together afterwards to support it, quotes a figure without knowing where it came from, or treats the data as the whole story.
Case, 15 minutes: customer complaints doubled last month, and nobody knows why. You have a week to find out. How would you approach it?
How the candidate structures an unfamiliar problem: checking it is real, splitting it into parts, forming hypotheses and testing the likeliest first.
Follow up with
- What's the first piece of data you'd ask for?
- What are your top three hypotheses, and how would you test each?
- What would you report at the end of the week if you still weren't sure?
Aparna MenonQA engineer · 4 years · Kochi“First I'd check the doubling is real: a new complaint form, a new channel or a renamed helpdesk tag can do that on its own. Then I'd split the complaints by type, channel, app version and the date they started. If they jump on one day, I'd ask what changed that day: a release, a price change, a partner outage. My first hypotheses would be a release, a policy change, and one big customer having a bad month, tested in that order, because a release is the easiest to check. By Wednesday I'd have read fifty complaints from the biggest group and sat with two support agents for an hour. On Friday I'd report what we know, what we've ruled out, and what's still open.”
What makes it strong
Checks the rise is real (did the counting change?), splits complaints by type, channel, product and date, asks what changed last month, forms a few hypotheses and tests the likeliest first, talks to the people who handle the complaints, and reports what is known and unknown at the end of the week.
Nitin GoyalSupply chain analyst, pharmacy retail · 7 years · Jaipur“I'd start by pulling every complaint from the last twelve months into one dataset and building a proper dashboard: by category, region, product, everything. Most of the week would probably go on getting the data clean. Once it's all in one place, the pattern should show itself, and then I'd know where to look.”
What gives it away
Jumps to a solution (more support staff, a survey), or plans to gather everything before forming any idea of the cause. No plan for the week, and no check that the rise is real.
Tell me about a time your first solution to a problem didn't work. What did you do next?
Whether the candidate learns from a failed attempt and changes approach, rather than repeating it or defending it.
Follow up with
- What did the failure tell you that you didn't know before?
- How long did you give the first fix before deciding it hadn't worked?
- What did you tell the people waiting for it?
Aparna MenonQA engineer · 4 years · Kochi“Patients reported that they sometimes got no reminder before an appointment. My first guess was the notification service failing under load, so I sent five hundred reminders at once. Every one arrived, so it wasn't load. I went back to the complaints and saw they were all for appointments booked less than an hour before the reminder was due. Reminders were scheduled by a job that ran once an hour, so a late booking fell between two runs. I wrote a test that booked forty minutes ahead, just after the hourly job had run, reproduced it every time, and gave the developers the exact case. I told the product owner my first theory was wrong and what we now knew. The fix shipped that sprint, and my test is in our regression suite.”
What makes it strong
Describes what they tried and why, how they knew it hadn't worked, what the failure revealed about the problem, how they changed approach, and what they told the people waiting.
Ajay RathorePlant maintenance manager · 22 years · Pune“Honestly, I can't think of many. After twenty-two years on the floor, my first fix usually works. If it doesn't, I try the next most likely thing until the machine runs. That's maintenance.”
What gives it away
Can't recall a first solution failing, kept trying fixes until something worked without learning why, or blames the problem for changing.
Tell me about a time you had to act on a problem quickly, before you had all the information you wanted.
Whether the candidate can make a sound, reversible decision under time pressure and keep checking it as information arrives.
Follow up with
- What did you know, and what were you guessing?
- What would have made you change course?
- What did you do once you knew more?
Ajay RathorePlant maintenance manager · 22 years · Pune“The main hydraulic pump on our biggest press started overheating mid-shift, in a week we had a large customer shipment due. I didn't know if it was the oil, the cooler or the pump itself, and a full diagnosis would take a day. What I did know: running it hot could wreck the pump, and a new one was six weeks away. So I stopped the press, moved the most urgent parts to a smaller press at lower output, and had the cooler checked first, because it was the quickest to rule out. It was blocked. We cleaned it, ran the press at half load for two hours watching the temperature, then full load. Stopping cost us five hours; a wrecked pump would have cost six weeks. We shipped on time, and the pump is still running.”
What makes it strong
Separates what they knew from what they assumed, chooses the action that limits harm and can be undone, checks the quickest possibilities first, keeps watching as information arrives, and says honestly whether the call was right.
Nitin GoyalSupply chain analyst, pharmacy retail · 7 years · Jaipur“During a bad fever season, stores started running short of a common fever medicine and asked what to order. I didn't want to recommend quantities on two weeks of data, so I told them to keep their usual orders until I had a clearer trend. By the time I had a month of data, demand had already peaked.”
What gives it away
Waited for complete information while the problem got worse, or acted on a guess and never checked it. Cannot separate what they knew from what they assumed.
Tell me about a problem where someone else's idea turned out better than yours. How did you realize it?
Whether the candidate judges ideas on evidence regardless of whose they are, and can let go of their own solution.
Follow up with
- What did you think of their idea at first?
- What convinced you?
- What do you do now to hear other ideas earlier?
Nitin GoyalSupply chain analyst, pharmacy retail · 7 years · Jaipur“I'd built a reorder model for our stores from six months of sales, and about a third of them still ran out of chronic medicines at the end of the month. A store manager in Ajmer told me what the model was missing: most of her customers bought their monthly medicines in the first week after payday, so demand wasn't spread evenly. My model averaged it out. I was skeptical, so we checked, and the first-week spike was there in twenty stores. We used her idea, a separate reorder level for the first week, in those stores, and month-end shortages there halved within two months. Now I call three store managers before I build anything.”
What makes it strong
Describes their own idea and the other person's fairly, how they compared them (a test, data, a trial), what convinced them, and how they credited the other person. Has changed how they gather ideas since.
Ajay RathorePlant maintenance manager · 22 years · Pune“In my experience my own approach usually works, because I've seen most of these problems before. Once a graduate engineer on my team suggested a vibration sensor for a bearing problem, but I'd already planned to replace the bearing, so we did it my way. It worked, so I don't think it mattered.”
What gives it away
Cannot think of an example, or dismissed the other idea without testing it. Credits themselves for the outcome.
Rating the answers
Rate straight after the interview, alone, against these anchors, and write down the line the candidate said that earned the score.
| Rating | What it looks like |
|---|---|
| 5 · Strong | Defines the problem first, breaks it into testable parts, forms and tests hypotheses in a sensible order, uses evidence and knows its limits, acts sensibly when information is incomplete, and confirms the fix held. |
| 3 · Mixed | Follows a sensible approach and reaches a fix, but tests few alternatives. Defining the problem, the limits of the evidence or checking the result comes out only when prompted. |
| 1 · Weak | Jumps from symptom to solution, cannot explain how they found the cause, or credits luck or the team. Waits for clear instructions when a problem is vague. |
If you are the candidate
- Choose a problem where the cause wasn't obvious, and spend most of your answer on how you found it: what you suspected, what you checked, what you ruled out.
- Say 'I'. If the team solved it together, say which part of the reasoning was yours.
- Use numbers where you can: how often it happened, what it cost, what changed after the fix.
- In a case question, think aloud. Say how you'd define the problem, what you'd check first and why. A clear method with an imperfect answer beats a confident guess.
- Freshers: a final-year project that wouldn't work, a college event that went wrong, or a recurring headache in a part-time job all make good examples.
Never ask
- Don't ask brainteasers or riddles ('How many tennis balls fit in a bus?', 'Why are manhole covers round?'). Why: they test practice at puzzles, not how someone solves the problems the job brings, and they put good candidates on edge. Use a problem from the job instead.
- Don't ask candidates to solve a live, unsolved problem from your business as part of the interview. Why: it is unpaid consulting, candidates rightly resent it, and you end up judging them against an answer nobody has. Use a past problem you have already solved, or an invented one.
- Don't ask timed mental-arithmetic or abstract-reasoning puzzles the job does not use. Why: a test that is not job-related and screens out some groups more than others invites a disparate-impact claim in the US, and it is unfair anywhere. Test the reasoning the work actually needs.
- Don't ask 'What's the hardest thing you've overcome in your life?' to probe problem solving. Why: it invites disclosures about health, family or money that you cannot use and should not hold. Keep to problems from work, study or volunteering.
Questions people ask
- How do I answer 'Tell me about a problem you solved'?
- Pick a problem where the cause wasn't obvious. Describe the symptoms, what you first suspected, how you tested it, what you ruled out, the cause you found, the fix, and how you checked it held. The method matters more than the size of the problem.
- What are interviewers looking for in a problem-solving case question?
- How you structure it, more than the final answer. They listen for you to check the problem is real, ask what data exists, split it into parts, form a few hypotheses, and say which you would test first and why. Thinking aloud helps them rate you; a long silence followed by an answer does not.
- Are brainteasers good problem-solving questions?
- No. They mostly test whether someone has practiced puzzles. A short case built from the job's real problems, or a question about a problem the candidate actually solved, tells you far more.
- How many problem-solving questions should one interview include?
- Usually two: one behavioral question about a real problem, probed well, and one short case from the job, about fifteen minutes each. Ask every candidate the same ones and rate them against the same anchors, as in any structured interview.
Ask it the same way every time.
Itya puts these questions in every interviewer's guide, records the answers, and drafts a scorecard that quotes the line behind each rating. The AI drafts; your team decides. Free plan, unlimited teammates.