Tell me about a time when you spot an opportunity to improve your company, and you drive that
Asked at:
Amazon
Visa
Canva
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see whether you do more than execute assigned work: do you notice meaningful gaps, form a point of view on what should change, and carry that change forward. They are also testing whether your sense of "improvement" is grounded in real impact rather than personal preference. At higher levels, they want to hear increasing scope, better judgment about where to spend improvement energy, and stronger ability to influence others without waiting to be told.
“Describe a time you saw something at work that could be better and took the lead on improving it.”
“What's an example of an initiative you started because you noticed your team or company could operate more effectively?”
“Tell me about a change you drove after identifying a gap or inefficiency in the organization.”
“Have you ever spotted a problem nobody had assigned to you and decided to fix it? What happened?”
“Walk me through a time you identified an opportunity for improvement and turned it into a real change.”
Key Insights
- You need to tell a story about driving improvement, not just noticing a problem. Many candidates stop at "I raised it" or "I suggested it," which signals observation, not ownership.
- Pick an opportunity that was consequential enough for your level. A tiny convenience fix can work for a junior engineer, but senior and above usually need a story that improved how multiple people or teams operated.
- Show how you knew the opportunity was worth pursuing. Strong answers make it clear you separated a real company need from a personal annoyance and then validated that the change actually helped.
What interviewers probe atlevel
Top Priority
At junior level, the bar is noticing a real local inefficiency and showing you understood why it mattered to others, not just to you.
Good examples
🟢I noticed new engineers were each spending a day or more getting their dev environment working, including me, so I proposed simplifying the setup steps because it was slowing onboarding for the whole team.
🟢I saw that the same customer issue was being triaged repeatedly because the runbook was incomplete, so I treated that as a team efficiency problem rather than just a documentation gap.
Bad examples
🔴I thought our local setup script was annoying, so I rewrote it because I prefer a different tool. It made my workflow nicer.
🔴I noticed our standup notes looked messy, so I made a new template and asked everyone to use it, mainly because the old one bothered me.
Weak answers confuse personal convenience with team value; strong answers show the candidate recognized a problem that affected shared outcomes.
You do not need to have led alone, but you should show you did more than point at the issue and wait for someone else to solve it.
Good examples
🟢I gathered the setup failures I hit, drafted a simpler version of the onboarding guide, tested it with another new hire, and then worked with my mentor to roll it out.
🟢I created the first pass of the missing runbook steps, asked the on-call engineer to review them, and stayed with the task until the team adopted the updated version.
Bad examples
🔴I told my tech lead the setup process was bad and then they eventually fixed it.
🔴I mentioned in a team meeting that our runbook needed work, and later someone added more details.
Weak answers outsource the real work; strong answers show initiative, follow-through, and partnership appropriate to a junior engineer.
Valuable
Even at junior level, do not end with 'we changed it'—show some evidence that the change helped.
Good examples
🟢After we updated the onboarding steps, the next two hires got through setup in a few hours instead of over a day, and they did not need the same manual help I needed.
🟢Once the runbook was revised, the repeated support issue stopped coming to engineers directly as often, and the on-call engineer told me the handoff became smoother.
Bad examples
🔴I updated the onboarding guide and people seemed happier after that.
🔴I improved the runbook, and I think support questions dropped.
Weak answers imply success; strong answers provide concrete signals that the improvement changed outcomes.
A strong junior answer shows you did enough discovery to avoid solving the wrong problem and scaled your actions to your role.
Good examples
🟢I first listed the setup issues that actually blocked new hires and focused on the top few failures instead of trying to redesign everything.
🟢I looked at which support questions came up most often and started by improving the troubleshooting guide for the highest-volume issue.
Bad examples
🔴I saw setup was slow, so I rewrote the whole development environment because that seemed like the cleanest fix.
🔴I noticed support questions repeated a lot, so I created a large documentation overhaul without checking which questions actually caused the most delays.
Weak answers jump to oversized or poorly targeted solutions; strong answers show prioritization and right-sized action.
Example answers atlevel
Great answers
In my first few months on the team, I noticed that getting the local environment running was taking new hires a long time because the setup guide had drifted from the actual process. I hit the same issues myself, so I wrote down every failure point as I went and then checked with another newer engineer to see if they were seeing the same thing. I drafted a simpler setup guide, added a small script for two of the manual steps, and asked my mentor to review it so I didn't accidentally change something important. After we published it, the next two engineers got through setup much faster and needed a lot less help in chat. What I liked about that experience was learning that even as a junior engineer, I could improve the team by being observant and following through.
At my first job on a small consumer app team, I noticed our support queue filled up every week with users saying they hadn’t received important push notifications. I dug into the logs, reproduced the problem, and discovered transient network errors were causing our notification task to drop messages instead of retrying. I proposed a small change: add a lightweight retry-and-persist step plus a simple alert when retry rates spike, and I implemented it with guidance from a senior engineer and wrote tests. After we shipped it, the related support tickets fell by about 60% over the next month and the product manager added the alert to our standard dashboard. That experience taught me that focusing on one customer-facing pain point can deliver big, measurable value even when you’re new.
Poor answers
At my last company, I saw that our setup process was kind of outdated, so I rewrote it in a way I thought was cleaner. I prefer having fewer manual steps, so I changed the instructions and shared them with the team. People appreciated that I took initiative and made the docs look much better. I try to improve things whenever I see something inefficient.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid March, 2026
Amazon
Senior
Early February, 2026
Amazon
Senior
Mid January, 2026
Visa
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.