Give an example of a situation where you had to overcome a significant setback or obstacle to achieve a goal
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see how you behave when progress stops being straightforward. They want evidence that you can stay effective under pressure: understand the real problem, adapt your approach, and keep driving toward the goal instead of stalling or blaming circumstances. At higher levels, they also want to see whether you handled the setback in a way that protected the team, clarified tradeoffs, and improved outcomes beyond your own task.
Key Insights
- You do not need a dramatic disaster story. A strong answer usually has a meaningful obstacle, but the real signal is whether you responded with judgment, persistence, and adaptation rather than just working harder.
- Do not treat the setback as something that merely happened to you. Show how you diagnosed what was blocking progress, what options you considered, and why you changed course.
- You should close the loop. Many candidates describe the obstacle and the scramble, but forget to explain whether the goal was actually achieved, what changed because of their actions, and what they learned for next time.
What interviewers probe atlevel
Top Priority
Show that you did more than push harder—you learned what was actually wrong and changed your approach.
Good examples
🟢I paused to narrow the problem, compared a couple of possible causes, and adjusted the implementation based on what I found.
🟢Once I saw the original plan was too risky, I broke the work into smaller steps and validated each one before continuing.
Bad examples
🔴I kept trying different code changes until one of them worked, and then we moved on.
🔴The task was taking too long, so I just spent more time on it and eventually got through it.
Strong answers show deliberate learning and course correction; weak answers rely on persistence without diagnosis.
Valuable
Example answers atlevel
Great answers
In my first few months, I owned a small internal tool update that was supposed to automate part of a support workflow. A week before we planned to release it, I found that my approach handled the happy path but broke on several real customer cases because I had misunderstood how the old process was being used. I paused implementation, pulled a few examples from logs, and asked a more experienced engineer to review my assumptions with me. Based on that, I reduced the first version to the highest-value cases and added checks so the unsupported ones would fall back safely instead of failing. We released on time, support could use it immediately, and I learned to validate edge cases much earlier instead of assuming the simplest flow is the common one.
I was tasked with shipping a small UI feature for our Spanish-speaking customers, and we rushed the translated text to meet a marketing deadline. Within a day of launch we started getting messages from users and support reps that the wording was confusing and some dates and numbers displayed in an unfamiliar format, which caused sign-ups to drop in that region. Instead of defending the release, I reached out to our bilingual support agent and a contractor translator, gathered concrete examples of confusing phrases, and shipped a corrected set of strings plus locale-aware formatting within a few days. I also added a simple pre-release checklist that requires at least one native speaker to approve copy for each locale and wrote a tiny automated check to catch missing translations. After the fixes, the signup rate returned to normal and support volume dropped; I learned to prioritize cultural accuracy and involve real users early rather than assuming a literal translation is sufficient.
Poor answers
One obstacle I had was a feature that took longer than expected because the codebase was pretty confusing. I spent a lot of time reading through it and eventually a teammate pointed me to the right files, so after that I finished the work. It was a good experience because it taught me that some tasks are just harder than they look. In the end the feature went out, so I was happy with how I handled it.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid June, 2026
rq3t3qwty
Early May, 2026
Early April, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.