Tell me about a project where the requirements were not clear or kept changing. How did you adapt and maintain productivity?
Asked at:
DoorDash
Toast
Meta
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.
“Describe a time you had to deliver something even though the goals or requirements weren't fully defined.”
“Tell me about a project where the direction changed midway. What did you do to keep things on track?”
“Have you worked on something where people kept revising what success looked like? How did you handle that?”
“Walk me through a situation where you had to make progress without having all the answers up front.”
“What's an example of a project that had a lot of uncertainty or shifting priorities, and how did you keep it productive?”
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
You do not need perfect answers at junior level, but you should show judgment about when to ask, when to proceed, and how to avoid obvious rework.
Good examples
🟢I asked about the decisions that would change the implementation a lot, and for smaller details I made a reasonable assumption and called it out in my notes.
🟢I used a simple first pass to test whether my interpretation was right before spending time on edge cases that might change anyway.
Bad examples
🔴I didn't want to bother anyone with too many questions, so I made all the decisions myself and fixed issues later during review.
🔴I kept asking for exact requirements before starting because I wanted to be careful and avoid making the wrong assumptions.
Weak answers either over-index on guessing or over-index on waiting; strong answers show proportional judgment.
For junior candidates, productivity means you kept contributing useful work instead of repeatedly restarting or waiting on perfect clarity.
Good examples
🟢I worked on the parts that were unlikely to change while I waited on answers to the open questions.
🟢I broke the task into smaller pieces so requirement updates only affected part of my work instead of resetting everything.
Bad examples
🔴Each time the requirements changed, I paused until I knew the final version so I wouldn't waste time.
🔴I rewrote the work whenever we got new feedback because it was faster than trying to separate what had actually changed.
Weak answers accept rework and idle time as normal; strong answers show practical ways to keep progress going.
At junior level, interviewers mainly want to see that you didn't freeze when requirements were unclear and that you sought enough clarity to keep making useful progress.
Good examples
🟢The ticket was vague, so I wrote down my understanding, asked my mentor to confirm the top priority, and split the work into a small first version plus follow-up tasks.
🟢When the goal kept shifting, I focused on the stable part we knew we needed, documented the open questions, and used those to get quick answers instead of blocking completely.
Bad examples
🔴The requirements kept changing, so I mostly waited for my tech lead to tell me what to do next because I didn't want to build the wrong thing.
🔴I just built the first version based on my understanding and then redid it each time feedback came in since that's part of working on changing projects.
Weak answers treat ambiguity as a reason to stall or churn, while strong answers show the candidate creating enough structure to move safely.
Valuable
A good junior answer shows that you learned how to work better in ambiguous situations, not just that the project eventually finished.
Good examples
🟢I learned to separate must-know questions from nice-to-know details, which helped me start earlier without creating as much rework on later tasks.
🟢After that project, I started writing down assumptions before implementation because I saw how easy it was to lose track of what had actually been decided.
Bad examples
🔴The main lesson was that requirements usually change, so now I just expect that and stay flexible.
🔴I learned to ask more questions at the beginning, and after that project I felt more comfortable with unclear tasks.
Weak learning is generic and passive; strong learning is specific enough to have changed the candidate's behavior.
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.
Early April, 2026
Mid-level
Mid January, 2026
Microsoft
Senior
Early January, 2026
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.