Tell me about a time when you had significant, unanticipated obstacles to overcome in achieving a key goal.
Asked at:
Amazon
Monzo
JPMorgan Chase
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests how you respond when reality breaks your plan: something important changes, your first approach stops working, or hidden constraints surface. Interviewers want to see whether you can stay effective under pressure by diagnosing the real problem, adapting thoughtfully, and still driving toward a meaningful outcome. At higher levels, they also look for whether you protected the broader team or business rather than solving only your own narrow piece.
“Describe a time when a project you were driving ran into a major surprise. What did you do?”
“Tell me about a goal that became much harder than expected partway through. How did you adapt?”
“Have you ever had an important plan go off the rails because of something you didn't anticipate? Walk me through it.”
“What's a time you faced a serious setback on a key piece of work and still had to deliver?”
“Give me an example of an unexpected challenge that threatened an important outcome for you or your team.”
Key Insights
- You do not need a story where you heroically saved a doomed project. A strong answer often comes from showing that you recognized the obstacle early, re-scoped intelligently, and made tradeoffs that preserved the most important outcome.
- Do not treat the obstacle as bad luck that happened to you. Interviewers want to hear how you investigated what changed, generated options, and chose a response rather than simply working harder.
- You should make the goal and the obstacle both feel consequential. If the goal was minor, or the obstacle was just routine debugging, the story will sound like normal execution rather than resilience under meaningful uncertainty.
What interviewers probe atlevel
Top Priority
You are not expected to solve everything alone, but you should show that you stayed engaged and helped move the situation forward.
Good examples
🟢I pulled together the evidence, documented the failure clearly, and kept following up until we had a path to finish the feature instead of assuming someone else would carry it.
🟢Even after getting help, I stayed owner of the task by testing the proposed fix, updating the plan, and confirming the final behavior before we closed it.
Bad examples
🔴I reported the blocker to my lead and then switched to another task until someone got back to me.
🔴Once the issue became bigger than my task, I left it to the senior engineers because it was really their area.
Weak answers hand off the problem mentally; strong ones show sustained responsibility even when help is needed.
Pick a story where the problem truly disrupted your plan, not just a normal task bump, and make clear why the goal mattered in your scope.
Good examples
🟢I was responsible for adding a feature used in a customer demo, and two days before handoff we discovered the upstream data my work depended on was incomplete in production-like environments.
🟢I owned a small but visible onboarding change, and after implementation we found that a dependency behaved differently under real user traffic, which meant my original approach could not ship safely.
Bad examples
🔴We had a bug right before release, so I stayed late and fixed it. It was stressful, but that's part of engineering.
🔴Partway through the task I realized the codebase was more complicated than I expected, so I spent extra time reading it and got through it.
Weak answers describe ordinary engineering friction; strong answers establish that a real surprise threatened an outcome that actually mattered.
Valuable
It is fine if you didn't fully save the original plan; what matters is whether you prioritized the most important outcome sensibly.
Good examples
🟢When the full feature became too risky, I aligned with my lead on a smaller version that still supported the upcoming demo and left lower-value polish for later.
🟢I recognized the original approach would jeopardize reliability, so I proposed a simpler release that met the core user need without introducing a risky dependency.
Bad examples
🔴I tried to preserve every original requirement even though the obstacle made that unrealistic.
🔴We cut some things to finish on time, but I didn't really think much about which parts mattered most.
Weak answers either cling to the old plan or cut blindly; strong ones make thoughtful tradeoffs tied to the real goal.
Show that the experience changed how you work, not just that you survived it once.
Good examples
🟢I added a small pre-check to my future tasks so I could validate the dependency early, and I used that approach again on later work.
🟢I documented the gotcha in our team notes and started testing in a more production-like setup before calling a feature done.
Bad examples
🔴After that, I just tried to be more careful in general.
🔴The main lesson was to ask for help sooner, so now I do that when I get stuck.
Weak lessons are generic slogans; strong ones become specific behavior changes or reusable safeguards.
Example answers atlevel
Great answers
In my first year, I was assigned to add a small account settings feature that needed to be ready for a customer demo. I finished the implementation in our development environment, but when I tested it in a more realistic setup, I found that a service I depended on returned incomplete data, so the feature couldn't work the way I designed it. Instead of just saying I was blocked, I isolated the failing case, compared it with a working path, and brought my mentor a couple of specific options. We agreed to ship a narrower version that used data we could trust, and I updated the tests and demo notes so nobody was surprised later. The demo went ahead successfully, and after that I started validating external dependencies earlier whenever I picked up similar work.
On a small onboarding task I was responsible for, I built a modal that needed to work well for keyboard and screen-reader users. During testing I discovered the third-party modal we relied on didn’t expose the right accessibility hooks, so screen readers wouldn’t announce the content—something none of our usual tests caught. I reproduced the problem, wrote a minimal wrapper to manage focus and add the correct ARIA attributes, and worked with our designer to simplify the markup so it would be reliably announced. I also added an automated accessibility check to our test suite and created a short how-to for the team on evaluating UI libraries for accessibility. The onboarding shipped on schedule, people using assistive tech could complete it, and I started running those accessibility checks whenever I touched UI components.
Poor answers
I had a project where there were a lot of issues that came up unexpectedly. The codebase was more complicated than I thought, and I ended up spending extra time figuring it out and fixing bugs. I worked pretty independently and just kept trying different things until it was done. In the end it shipped, so I felt good about how I handled the pressure.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early May, 2026
Monzo
Senior
The interviewers asked the question and didn't have much follow up once I answered it. They were interested in the situation and re-confirmed the obstical.
Late April, 2026
Amazon
Staff
Late March, 2026
JPMorgan Chase
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.