Describe a situation when you had a scope creep
Asked at:
Amazon
Meta
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see whether you can recognize when a project is expanding beyond its original intent and respond with judgment rather than just working harder. They want evidence of ownership under changing requirements: how you clarified the new scope, protected delivery, communicated tradeoffs, and adjusted plans. At higher levels, they are also assessing whether you can shape scope for others, not just survive it yourself.
“Tell me about a time a project grew beyond what was originally planned. What did you do?”
“Describe a situation where requirements kept getting added after work had already started.”
“Have you ever been on a project that started small and became much bigger? How did you handle it?”
“Walk me through a time you had to push back or reframe work because the scope kept expanding.”
Key Insights
- You do not get credit just for enduring extra work. Strong answers show that you noticed the change in scope, made the change explicit, and helped the team decide what to do about it.
- Do not frame scope creep as 'the business kept asking for things' and stop there. Show that you understood why the requests were happening and translated that into options, tradeoffs, and a better plan.
- A good answer often includes prevention, not just recovery. Explain what you changed afterward so future work had clearer boundaries, checkpoints, or decision points.
What interviewers probe atlevel
Top Priority
At junior level, the key is showing that you can tell the difference between normal iteration and work that is drifting beyond what was agreed.
Good examples
🟢I noticed we had moved from a small bug fix into redesigning part of the workflow, so I asked my mentor to help me confirm whether the goal had changed.
🟢When new edge cases and UI changes kept getting added, I called out that we were no longer working on the initial narrow task and that the estimate needed to be revisited.
Bad examples
🔴The ticket kept getting updated, so I just kept adding whatever was asked until it was done. That's pretty normal in software.
🔴I assumed the extra asks were all part of the original feature because they sounded related, so I didn't think it needed any special discussion.
Weak answers normalize uncontrolled expansion; strong answers show awareness that the shape of the work changed and needed to be surfaced.
You are not expected to control the whole project, but you are expected to raise concerns, ask clarifying questions, and help contain the problem.
Good examples
🟢I wrote down the original task and the new asks and brought that to my lead so we could decide what should stay in the current work.
🟢I asked whether we should finish the core fix first and create follow-up tasks for the extras, which helped us stop mixing everything together.
Bad examples
🔴I just kept taking the new requests because I didn't want to be difficult, and I figured someone else would decide if it was too much.
🔴Once I realized the work was growing, I waited for my lead to bring it up because I didn't feel it was my place.
Weak answers surrender agency; strong answers show appropriate initiative within the candidate's level.
Valuable
A strong junior answer ends with a concrete lesson you now apply, not just 'it was a good learning experience.'
Good examples
🟢After that, I started confirming acceptance criteria before I began and checking when new asks should become separate tasks.
🟢I learned to surface changes early instead of assuming they were small, and my lead later told me that made planning much easier.
Bad examples
🔴It taught me that projects change a lot, so now I'm just more prepared for surprises.
🔴Since then I've tried to work faster when requests start piling up.
Weak answers offer generic lessons; strong answers show a changed behavior that would prevent recurrence.
A strong junior answer shows simple but useful structure: breaking work down, clarifying what is core, and avoiding a blur of changing requests.
Good examples
🟢I separated the original fix from added enhancements and tracked them as distinct items so we could see what was truly required to finish.
🟢I asked for acceptance criteria on the main task so I could stop treating every new idea as part of done.
Bad examples
🔴I worked on whatever seemed most urgent each day because the requests were changing a lot.
🔴I kept all the asks in my head and handled them one by one as they came up.
Weak answers let ambiguity run the work; strong answers impose a basic structure that makes progress and scope visible.
Example answers atlevel
Great answers
In an internship, I was assigned what was supposed to be a small bug fix in our internal dashboard. After I started, a few related requests came in, including new validation rules and a small layout change, and I realized the task had turned into more than the original fix. I wrote down the original ask versus the new requests and reviewed it with my mentor so we could decide what really needed to ship. We agreed to keep the bug fix and one required validation change in scope, and we created follow-up tasks for the rest. That helped me finish the core issue on time, and afterward I got into the habit of confirming acceptance criteria early and asking when new requests should become separate work.
At a small startup I was asked to build a quick prototype for a prospective client so the account team could demo our product. As I worked, the client and our account manager kept asking for extra integrations and custom UI tweaks that would have doubled the work. I listed every new request, estimated the added time for each, and set up a short call with the account manager and our product lead to decide what was truly needed for the demo. We agreed to ship a focused prototype that matched the original deadline and capture the other items as a paid follow-up; that allowed us to keep the client conversation moving without overcommitting the engineering team. I now always create a one-page scope summary and share rough impact estimates before I start, which makes these conversations much easier.
Poor answers
I had a task where people kept adding related improvements while I was working on it. I thought it made sense to just do them all together since I was already in the code, so I kept taking the updates as they came in. It took longer than expected, but the final result covered more cases and people were happy with the end product. For me that showed that being flexible is the best way to handle scope changes.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early April, 2026
Amazon
Staff
Late March, 2026
Meta
Senior
Late August, 2025
Meta
Staff
Hello Interview Premium
Your account is free and you can post anonymously if you choose.