Give me an example of a time when you were not able to meet a commitment.

In my first few months at work, I committed to finishing a small internal dashboard update by the end of the sprint because another engineer needed the data view for testing. A couple of days in, I realized I had underestimated how messy the underlying data was, and I spent too long trying to fix it alone because I wanted to prove I could handle it. Once I saw I was slipping, I told my lead in our daily check-in, showed what I had tried, and asked for help validating the approach. We decided to cut one lower-priority filter so I could deliver the main view on time for testing, and I finished the rest a few days later. What I learned was to surface risk earlier and test my assumptions before committing on unfamiliar code, and since then I've been much more consistent about giving updates before something becomes a surprise.

At my last startup I committed to deliver an updated onboarding flow before a scheduled marketing campaign because the PM wanted users to see the new content. A few days in I realized I’d badly underestimated the time needed for cross-browser fixes and accessibility checks—things I hadn’t factored into my estimate as a junior developer. I told the PM immediately, showed a quick list of what would remain unfinished, and suggested shipping a simplified version that preserved the new visuals but deferred some interactive validation, while I worked with QA and a senior engineer to finish the accessibility items. The team agreed to use the simplified flow for the campaign, and I completed the remaining work the following week. I learned to always include testing and accessibility in my timelines and to flag cross-team dependencies as soon as possible.