Tell me about a project where the requirements were not clear or kept changing. How did you adapt and maintain productivity?
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you operate when the path is not well-defined and certainty is unavailable. They want to see whether you can create momentum without thrashing: clarify what matters, make reasonable assumptions, communicate tradeoffs, and keep delivering despite changing inputs. At higher levels, they are also testing whether you can create clarity for others rather than merely cope with ambiguity yourself.
Key Insights
- You should not frame ambiguity as something that simply happened to you. Strong answers show that you actively reduced uncertainty by asking better questions, testing assumptions, or narrowing the decision space.
- Candidates often forget to explain how they maintained forward progress while requirements were changing. Don't just say you were flexible; show how you protected productivity through milestones, interim decisions, or scoped deliverables.
- If requirements changed for a good reason, say that. Mature answers distinguish between 'bad process' and legitimate learning, and they show that you can adapt without becoming cynical or blaming others.
What interviewers probe atlevel
Top Priority
Strong junior answers show that you kept others informed instead of silently making assumptions or quietly struggling.
Good examples
🟢I summarized what I thought had changed and what I planned to do next, which helped my lead quickly correct anything I misunderstood.
🟢When I made an assumption to keep moving, I wrote it down and shared it so reviewers knew what I was optimizing for.
Bad examples
🔴I didn't want to create noise, so I only brought up requirement changes once I had already updated the implementation.
🔴I assumed people knew the requirements were shifting because everyone was in the same meetings, so I didn't restate my assumptions.
Weak answers rely on implicit understanding; strong answers make evolving assumptions visible early.
Valuable
Example answers atlevel
Great answers
In my first year, I worked on a small internal dashboard feature where the request started as 'show account health,' but the exact metrics kept changing as users saw early mockups. I wrote down the pieces that were still unclear, checked with my mentor which metrics were actually required for the first version, and focused on building the data loading and page structure first because those parts were unlikely to change. For the changing parts, I shared my assumptions in the ticket and in code review so people could correct them early. That helped us avoid redoing the entire feature every time feedback came in. We shipped a smaller first version on time, and after that I got more comfortable breaking vague work into what is stable versus what still needs answers.
At a small agency I worked on a two-week project to build a signup and donation flow for a nonprofit, but the stakeholders kept changing which fields and payment options they wanted as they debated priorities. To stay productive I built a simple clickable prototype first and walked the team through it so we could agree on the actual user steps before I wrote backend code. I also asked the client to pick a "must-have" list for the launch and a separate "nice-to-have" list, and I estimated how much time each change would add so they understood the tradeoffs. I kept a short change log and did brief daily check-ins so no surprises accumulated. By freezing the core flow and adding smaller requests to a follow-up sprint, I delivered a working flow on time and kept the client engaged and informed. I learned that quick prototypes and clear impact estimates are the best way to handle unclear, shifting requirements when time is tight.
Poor answers
I had a project where the requirements changed a lot because the product team kept updating what they wanted on a reporting page. I handled it by staying flexible and just updating my code each time they gave new direction. I usually waited until the latest requirement was confirmed before doing too much, which helped me avoid going too far in the wrong direction. In the end the page worked and everyone was happy with the final result.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late June, 2026
Asked in Amazon
Early May, 2026
Early April, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.