“Tell me about a time you improved a process or system” is testing whether you can spot inefficiency, understand the cause and make a practical improvement that produces a measurable benefit.
The interviewer is rarely interested in change for its own sake. A strong answer shows what was wrong, how you knew it was a problem, what you changed and how you checked that the new process was actually better.
Want more interview answers to practise?
The full guide contains 250+ popular interview questions and sample answers, including process improvement, problem solving and change questions.
What the interviewer is really testing
🔎 Problem recognition: could you identify a recurring issue rather than treating every case separately?
📊 Evidence: did you use data, feedback or direct observation to understand the problem?
💡 Initiative: did you suggest or lead an improvement rather than simply complain about the process?
🤝 Involvement: did you speak to the people who used the process before changing it?
📈 Impact: can you show that the new process saved time, reduced errors, improved service or created another useful result?
How to answer using B-STAR
💭 Belief: briefly explain your approach to continuous improvement.
📍 Situation: describe the inefficient process and the impact it was having.
🎯 Task: state what you personally wanted to improve.
🛠️ Action: explain how you investigated the issue, involved others and implemented the change.
📈 Result: show the measurable or clearly evidenced improvement.
Example answer: improving a bug-tracking process
Belief: I believe process improvement should remove friction from important work rather than simply introducing a new tool.
Situation: In a software project, our bug-tracking process involved several manual steps and did not distinguish clearly between minor defects and issues that could stop a release. Critical bugs were sometimes reaching developers too late.
Task: I wanted to simplify the workflow and make sure the highest-risk issues were identified and acted on quickly.
Action: I reviewed recent defects to understand where delay was occurring and spoke with developers, testers and project managers about what information they actually needed. The problem was partly the tool but also inconsistent severity definitions and duplicate hand-offs.
I introduced a simpler workflow with clearer severity rules, automatic notifications for critical defects and one agreed owner at each stage. I piloted the process with one team first, gathered feedback and changed the form so people only entered information that was genuinely useful.
I then trained the wider team and tracked defect age, time to first response and reopened issues so we could see whether the change was working.
Result: Critical defects were identified and assigned faster, average resolution time reduced and the team spent less time updating duplicate records. The clearer prioritisation also made release decisions easier because risk was more visible.
Example answer: improving a process without being asked
Belief: I believe small recurring problems are worth fixing when they create avoidable work for several people.
Situation: In an administrative team, customers were frequently contacting us for updates because confirmation emails did not explain how long the next stage would take.
Task: Although nobody had formally asked me to change the process, I wanted to reduce unnecessary status queries and make the customer journey clearer.
Action: I reviewed the most common follow-up questions and found that many customers simply did not know when they should expect another update. I drafted a short standard paragraph explaining the current stage, expected timeframe and when to contact us again if nothing had changed.
I shared the wording with my supervisor, incorporated their feedback and tested it in my own communications. I then compared the number of repeat status queries before and after the change.
Result: Follow-up queries reduced and colleagues spent less time answering requests for information that could have been provided automatically. The wording was adopted more widely by the team.
Practise more common interview questions
Use the complete guide to compare process-improvement answers with other behavioural interview examples.
Common follow-up questions
❓ How did you know the existing process needed to change?
❓ Who did you involve before making the improvement?
❓ What resistance did you face?
❓ How did you measure whether the new process was better?
❓ What would you do differently if you repeated the change?
Common mistakes
❌ Jumping straight to a solution: show how you understood the problem first.
❌ Making the improvement sound cosmetic: explain why it mattered to the team, customer or business.
❌ Ignoring other users: involve the people who actually use the process.
❌ Calling a new tool the result: the result is the improvement created by the tool.
❌ Using no evidence: give the interviewer a clear before-and-after outcome.
Prepare for the questions employers ask most often
