Tell me about time when you were working on an initiative or goal and saw an opportunity to do something much bigger or better than the initial focus.
Asked at:
Amazon
Meta
Uber
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can recognize when the original framing is too small and responsibly expand the opportunity. Interviewers want to see judgment: not just ambition, but how you validated that the bigger move was worthwhile, aligned others, and converted an observation into real impact. At higher levels, they are also evaluating whether the size of the opportunity you noticed matches the scope expected for your role.
“Describe a time when a project started as something small, but you realized there was a chance to create much more impact.”
“Have you ever been working on one goal and discovered the real opportunity was broader than what was originally asked? What did you do?”
“Tell me about a situation where you expanded the scope of an effort because you saw a better or higher-leverage path.”
“What's an example of a time you looked past the immediate task and turned it into something more valuable?”
“Can you share a time when the initial problem statement was too narrow and you helped reframe it into a bigger opportunity?”
Key Insights
- You should explain why the bigger opportunity was genuinely better, not just larger or more technically interesting. Good answers connect the expansion to user value, business value, risk reduction, or team leverage.
- Don't stop at 'I noticed something more important.' Interviewers want to hear how you tested the idea, adjusted the plan, and carried it through rather than simply proposing a bigger vision.
- A common miss is telling a story where you unilaterally expanded scope and created churn. Show that you balanced initiative with judgment, especially if broadening the work affected timelines, priorities, or other people.
What interviewers probe atlevel
Top Priority
You do not need to own everything, but you should show that you helped move the bigger idea forward instead of only mentioning it.
Good examples
🟢After raising the idea, I took on the first pass at the shared fix and documented the cases I had verified so my lead could review a concrete proposal.
🟢I volunteered to update the original task into a version that handled the repeated cases, and I kept checking with my mentor to make sure I was still solving the right problem.
Bad examples
🔴I told my lead there was a larger opportunity, and after that I went back to my assigned task because it was really their call.
🔴I pointed out that we could solve the broader issue, and once people agreed it sounded good, I considered my part done.
Weak answers stop at observation; strong answers show follow-through proportional to junior scope.
Even at junior level, interviewers want to see that you checked your instinct with evidence or feedback instead of just running with it.
Good examples
🟢Before changing the approach, I asked my mentor and looked through recent bug reports to confirm the issue happened in more than the one case I was assigned.
🟢I put together a small comparison of the original fix versus a shared solution and checked with the people using the workflow to see which problem was actually costing them time.
Bad examples
🔴I felt the broader fix was obviously better, so I just started implementing it and showed my lead once I was mostly done.
🔴I assumed users would prefer the larger change because it removed extra steps, so I expanded the task without really confirming it.
Weak answers rely on instinct alone; strong answers show lightweight validation appropriate to the candidate's level.
Valuable
At staff level, interviewers want to see disciplined leverage, not platform maximalism.
Good examples
🟢I narrowed the broader initiative to the repeated problems shared by most teams and left team-specific variations local until there was enough demand to centralize them.
🟢I protected adoption by starting with the minimum shared layer that created leverage, instead of forcing a complete standardized solution immediately.
Bad examples
🔴Because multiple teams could benefit, I designed the solution to cover a broad range of future needs from the start.
🔴I used the initiative to drive a common approach everywhere so we would not have to revisit fragmentation later.
Weak answers optimize for conceptual completeness; strong answers optimize for leverage, adoption, and manageable change.
Close the loop: say what changed because you expanded the task and what it taught you about spotting better opportunities.
Good examples
🟢The shared validation removed several repeat bugs over the next release, and it taught me to look for repeated patterns instead of treating each ticket as isolated.
🟢Automating the handoff cut a manual step from the process, and I learned that small assignments can expose bigger workflow problems if you ask where the real delay is.
Bad examples
🔴The broader change was well received, and people seemed happy that I had thought bigger.
🔴It turned into a better solution overall, and I was glad I had taken initiative.
Weak answers end with personal satisfaction; strong answers show observable improvement and a learning loop.
Example answers atlevel
Great answers
On one task, I was supposed to add validation to a single form so bad input wouldn't create support tickets. While testing it, I noticed the same kind of input could get into the system from a few other screens too, so fixing just my form would only solve part of the problem. I checked recent bug reports and asked my mentor whether this was a recurring issue, and that confirmed it was. Instead of only patching my page, I proposed moving the validation into one shared place and I took on the first implementation with guidance. We still shipped the original fix on time, and after that we saw the same issue stop showing up from those other entry points as well. It taught me to ask whether a small bug is really an isolated case or a sign of a broader pattern.
I was assigned to make one lesson page responsive for mobile learners, and while testing it with a screen reader and keyboard navigation I noticed the same focus and labeling problems appeared on many lessons. Rather than patching only that page, I raised the issue with our product manager and UX designer and proposed a lightweight accessibility fix that could be applied across the course module. They approved a pilot, so I implemented proper ARIA labels, fixed tab order, and created a short checklist and reusable code snippets so other engineers could apply the same fixes. After we rolled those changes out, we got direct positive feedback from a student who relies on assistive tech and saw fewer accessibility-related support requests. The experience reinforced to me that small work done thoughtfully for real users can scale to a much bigger, meaningful improvement.
Poor answers
I was asked to fix a UI bug on one settings page, but I realized the whole settings area looked dated, so I updated all of it while I was there. It definitely made the product better because everything looked more consistent afterward. It did add some extra time, but I think it's usually best to take the opportunity to improve things fully instead of doing the minimum. My lead reviewed it at the end and we kept most of the changes.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late March, 2026
Mid-level
Late March, 2026
Amazon
Staff
Late July, 2025
Meta
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.