Give an example of a situation where you had to overcome a significant setback or obstacle to achieve a goal
Asked at:
Spotify
Meta
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.
“Tell me about a time a project was at risk and you had to find a way through it.”
“Describe a situation where your original plan stopped working. What did you do next?”
“What's a meaningful obstacle you've faced at work, and how did you get past it?”
“Have you ever had a project go off track in a serious way? Walk me through how you responded.”
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
Even with limited authority, you should still show that you drove next steps rather than waiting to be rescued.
Good examples
🟢Once I realized I was blocked, I wrote down the unknowns, asked focused questions, and proposed a smaller deliverable I could finish safely.
🟢I escalated early with a concrete summary of the issue, investigated a few likely causes myself, and came back with options instead of just saying I was stuck.
Bad examples
🔴The requirements kept changing, so there wasn't much I could do except wait for my lead to clarify everything.
🔴The task was harder than expected because the code was messy, and once my teammate explained it, I was able to continue.
Strong answers show initiative within the candidate's level of authority; weak answers frame the candidate as mainly acted upon by events.
Pick a setback that was genuinely hard within your scope, not a minor inconvenience and not a story where you were mostly a bystander.
Good examples
🟢I owned a small feature, found out a key assumption in my implementation was wrong late in the cycle, and had to rework it without missing the release.
🟢I was responsible for a bug fix that turned out to affect multiple flows, and I had to narrow the problem, adjust the plan, and still deliver a safe solution.
Bad examples
🔴I was blocked because my local environment kept breaking, so I asked a teammate to fix it and then I finished my ticket.
🔴We had a big launch issue on another team, and it was stressful for everyone, so I helped test a few things.
Strong answers choose an obstacle that is material relative to junior scope and show personal responsibility for overcoming it; weak answers are either trivial or mostly someone else's problem.
Valuable
End with what happened, what you learned, and how you applied that learning afterward.
Good examples
🟢We shipped the smaller but correct version on time, and afterward I started validating assumptions earlier on similar tasks.
🟢The bug was resolved without regressions, and I used that experience to ask sharper questions and break work down better on later tickets.
Bad examples
🔴In the end it worked out, and the main thing I learned is to keep trying when things get hard.
🔴We finished the work eventually, and after that I felt more confident handling challenges.
Strong answers make the outcome and learning concrete; weak ones give generic success and generic lessons.
Persistence is good, but interviewers want to hear that you kept making progress, not that you kept repeating the same move.
Good examples
🟢When my first attempt failed, I asked for a quick sanity check, changed my plan, and kept moving instead of getting stuck alone.
🟢I stayed with the problem through a few dead ends, but each time I used what I learned to narrow the next attempt.
Bad examples
🔴I spent the whole weekend trying to force the original solution to work because I didn't want to give up on it.
🔴I kept debugging the same area for days since I was pretty sure the issue had to be there.
Strong persistence is adaptive and resource-aware; weak persistence is just prolonged struggle.
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 March, 2026
Mid-level
Mid January, 2026
Spotify
Senior
Early October, 2025
Meta
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.