Staying Productive When Project Requirements Were Unclear or Kept Changing

Tell me about a project where the requirements were unclear at the start or kept changing while you worked on it. How did you adapt, and how did you keep yourself and the work productive? ```hint Show the mechanism, not the frustration Focus on the specific things you did to reduce the uncertainty and to keep shipping despite it, and on how you dealt with the people asking for changes. ``` ### Clarifying Questions - Should the story focus on requirements that were missing from the start, or on requirements that shifted after work had begun? - Is a story where I was one contributor on a larger team acceptable, or should I have been the main engineer on the work? ### What a Strong Answer Covers - A concrete project and the specific way its requirements were unclear or unstable, including the cause - Actions that reduced ambiguity: identifying the decision owner, writing down assumptions, confirming them early - Engineering choices that kept work useful despite change, such as small slices, isolating the parts most likely to change, flags or configuration - How you communicated the cost of changes and agreed priorities rather than silently absorbing churn - The outcome, what you would do differently, and what you now do by default ### Follow-up Questions - At what point would you stop building and insist on a decision before continuing? - How did you handle work that had to be thrown away when a requirement changed? - How did you keep stakeholders aware of how changes affected the timeline? - Tell me about a time you guessed a requirement wrong. What happened?