To answer “tell me about a time you improved a process,” pick one workflow you changed, state how it performed before with a number, explain how you found the cause and what you changed, and finish with the after number and who still uses the new way. The interviewer is checking whether you can see inefficiency, fix it with evidence rather than opinion, and bring other people along. A clear before/after metric and honest credit to the team are what make the answer stick.
What is the interviewer really testing with “tell me about a time you improved a process”?
Process questions are common in operations, engineering, product, finance and customer roles because almost every job has repeated work that could be faster, cheaper or less error-prone. The interviewer is looking for:
- Diagnosis. Did you find the real bottleneck, or just the most annoying step?
- Evidence. Did you measure before and after, or does the story rest on “it felt smoother”?
- Change management. Did people actually adopt the new process, and how did you get them to?
- Durability. Is the improvement still in place, or did it fade when you moved on?
Some employers spell out this expectation. Amazon's Leadership Principles (as of October 2026) include Invent and Simplify, about always finding ways to simplify, and Insist on the Highest Standards, which describes making sure problems stay fixed. A good process story touches both: it simplifies something, and the fix lasts.
How do you show a before-and-after metric?
The metric is the spine of this answer. Choose the one that the people affected actually care about, and state it the same way before and after so the comparison is fair.
| Process type | Useful before/after metrics | Example phrasing |
|---|---|---|
| Engineering and release | Build time, deploy frequency, lead time for changes, failed deploys, time to restore | “Builds dropped from 38 to 11 minutes” |
| Operations and finance | Cycle time, error rate, rework, hours per week, cost per unit | “Month-end close went from 8 working days to 5” |
| Customer and support | First response time, resolution time, repeat contacts, satisfaction score | “Repeat contacts fell from 22% to 13%” |
| Sales and marketing | Lead response time, handoff errors, time to quote | “Quotes went out in one day instead of four” |
| People and team | Onboarding time, meeting hours, review turnaround | “Code review wait time halved” |
If you never measured precisely, give an honest estimate and say how you estimated it: “We sampled 50 tickets before and after.” An approximate number with a stated method is more credible than a suspiciously precise one. If there is a second-order benefit, such as fewer weekend pages or less overtime, add it in one sentence.
How to structure the answer (and credit the team)
- Situation: the process, who used it and the before number.
- Task: your role. Were you asked to fix it, or did you take it on?
- Action: how you found the cause (data, shadowing, interviews), the change you made, how you piloted it and how you won adoption.
- Result: the after number, adoption, and what it freed people to do.
Process changes are rarely solo work, so crediting the team is part of the answer, not a courtesy. Use “I” for the decisions and work you personally did and “we” for the shared parts, and name roles rather than hiding them: “the finance lead suggested we pilot it on one entity first.” Interviewers notice when a candidate claims a whole team's result, and they also notice when a candidate hides behind “we” and never says what they did.
3 example answers we wrote
These are examples we wrote to show the structure, not real candidates' answers. Use your own process and your own numbers.
Example answer we wrote: engineering (slow CI pipeline)
Situation: On my previous team, our continuous integration pipeline took about 38 minutes per pull request. Engineers batched changes to avoid waiting, which made reviews larger and riskier, and failed builds often meant losing most of an hour.
Task: I volunteered to own build speed for a quarter, with a target my manager and I agreed on: under 15 minutes without reducing test coverage.
Action: I started by measuring instead of guessing. I pulled timing data for a month of builds and found three causes: tests ran serially, dependencies were downloaded fresh every run, and a large end-to-end suite ran on every change even when only documentation changed. I added dependency caching, split the test suite into parallel shards, and with the QA lead we agreed on rules for when the end-to-end suite runs. I rolled the changes out one at a time behind a flag so we could see each effect and roll back if flaky tests increased. I wrote a short page explaining the new rules and answered questions in our team channel for the first two weeks.
Result: Median build time fell from about 38 minutes to 11, and pull requests got noticeably smaller over the next quarter because engineers stopped batching. The QA lead deserves credit for the test-selection rules, which were the riskiest part. Two other teams copied the setup.
Example answer we wrote: operations (month-end close)
Situation: I was a senior accountant at a mid-sized company where the month-end close took eight working days. Most of the delay came from manual reconciliations that three of us rebuilt from exported spreadsheets every month.
Task: My controller asked me to find ways to shorten the close without adding headcount.
Action: I shadowed each step of one close and logged the hours spent on every task. About a third of the time went to two reconciliations that pulled the same data from different systems in slightly different formats. I proposed standardized templates with lookups that matched transactions automatically, and flagged only the exceptions for review. One colleague worried the automation would hide errors, so we ran the old and new methods side by side for two months and compared results line by line. After the parallel run matched, we switched over and I trained the team in two short sessions.
Result: The close dropped from eight working days to five, and reconciliation errors caught in review fell by more than half. The colleague who was skeptical ended up owning the templates, and her checks made them stronger than my first version.
Example answer we wrote: customer support (repeat contacts)
Situation: I was a support team lead for a subscription app. About 22% of customers contacted us a second time about the same issue within a week, which doubled work and frustrated customers.
Task: I wanted to cut repeat contacts, and my manager agreed I could spend part of each week on it if our response times held.
Action: I read a sample of 100 repeat conversations and grouped the causes. Most came from two issues: agents closing tickets before confirming the fix worked, and unclear instructions for resetting a payment method. I worked with two senior agents to write a short checklist for closing tickets and rewrote the payment-reset help article with screenshots. We piloted both on one shift for three weeks while the other shifts worked as usual, so we had a fair comparison.
Result: On the pilot shift, repeat contacts fell from 22% to 13%, and satisfaction scores rose slightly. We rolled the checklist out to every shift, and the two senior agents trained new hires on it. It taught me that the people doing the work usually know where the process breaks; my job was to measure it and make the change easy.
Weak vs strong process-improvement answers
| Element | Weak answer | Strong answer |
|---|---|---|
| Before state | “It was inefficient” | A number: time, errors, cost or volume |
| Diagnosis | Jumps straight to the solution | Explains how the cause was found |
| Rollout | “We switched over” | Pilot, comparison, then wider rollout |
| Credit | All “I” or all “we” | “I” for your decisions, named roles for others |
| Result | “Everyone liked it” | After number, adoption and what it freed up |
Mistakes to avoid
- Describing a tool purchase as a process improvement. Buying software is not the story; how you found the need and got people to change is.
- Criticizing whoever designed the old process. Explain why it made sense at the time.
- Skipping adoption. A better process nobody uses is not an improvement.
- Overloading with jargon. Name the method if you used one, but explain it in plain words.
Follow-up questions to expect
- “How did you measure the before number?”
- “Who pushed back, and how did you handle it?”
- “What trade-offs did the new process introduce?”
- “Is it still in use? What happened after you left the team?”
- “What would you improve next?”
Process stories overlap with several other prompts. If you started the effort unprompted, the same facts can answer “tell me about a time you showed initiative”. If the heart of it was measurement, consider “tell me about a time you used data to make a decision”, and if the cause was hard to find, the difficult-problem question may suit it better. The full list of “tell me about a time” questions helps you map one story to several prompts, and our behavioral STAR examples show more complete stories.
Practice it
Process stories tend to get long because there is a lot of setup. Rehearsing out loud is the fastest way to find what to cut. Use CoPilot Interview's AI interview assistant in Mock Interview mode: give it your résumé and the job description, and it asks questions drawn from both, reads them aloud and scores each spoken answer out of 10 with what to fix and a model answer. Listen for whether your before and after numbers come through clearly. The free plan includes 15 minutes a day with no account, and you can draft the story first in the free STAR builder. Follow each employer's rules, and use AI to prepare beforehand; the process, numbers and credit should be yours.
Say your process story out loud before the interview
Answer a question built from your résumé and the job description, get a score out of 10, and see exactly which part of the story to tighten.
Try a free AI mock interviewFAQ
What is a good example of improving a process at work?
A good example names one specific workflow, gives a before number such as hours, errors or days, explains how you found the cause, describes the change and how it was piloted, and ends with an after number and who adopted it.
What if I do not have exact numbers?
Give an honest estimate and say how you got it, for example by sampling tickets or timing a few runs. A stated method makes an approximate number credible.
How do I credit my team without underselling myself?
Say "I" for the decisions and work you personally did and name the roles of others for their contributions. That shows both your impact and your ability to work with people.
Can I use a process improvement from outside work?
Yes, if you are early in your career. A student club, volunteer group or part-time job can work, as long as there is a clear before and after and other people adopted the change.
Should I mention methods like Lean or Six Sigma?
Mention a method only if you actually used it, and explain what you did in plain language. Interviewers care more about your diagnosis and results than the label.
What if the improvement was later reversed?
You can still use it if you explain why it was reversed and what you learned. Many interviewers appreciate honesty about how changes hold up over time.