Tell me about a time when you or your team were more than half way to meeting a goal when you realized it may not be the right goal.
Asked at:
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question is probing whether you can recognize sunk-cost traps and re-evaluate a goal when new evidence suggests the team is solving the wrong problem. Interviewers want to see judgment under ambiguity: how you detected the mismatch, how willing you were to challenge momentum, and whether you redirected execution responsibly rather than simply abandoning work. At higher levels, it also tests whether you can protect team time and align work to actual user or business outcomes instead of local progress metrics.
“Describe a time when you were well into a project and realized the team was solving the wrong problem.”
“Have you ever had to redirect work midstream because the original objective no longer made sense? What happened?”
“Tell me about a situation where a project was on track, but you concluded the target itself needed to change.”
“What's an example of being far along on something and deciding not to keep pushing because it wasn't the right outcome anymore?”
Key Insights
- You should make clear how you realized the goal was wrong, not just that you eventually changed direction. The strongest answers show active sense-making: noticing signals, testing assumptions, and separating progress against plan from progress against the real need.
- Don't frame the pivot as heroic intuition alone. Strong answers usually show a disciplined re-evaluation process and a thoughtful transition plan that preserves useful work, minimizes thrash, and keeps others aligned.
- You need to address the emotional and organizational side of the moment. A lot of teams keep going because they are attached to prior effort, committed publicly, or afraid to create churn; naming how you handled that pressure is often what makes the answer senior.
What interviewers probe atlevel
Top Priority
Even as a junior engineer, you should show that once you saw a problem, you helped move the team toward a better path instead of just stepping back.
Good examples
🟢After raising the concern, I helped compare what code could still be reused and updated the task list so we could salvage the validation work instead of losing the whole sprint.
🟢I suggested a smaller change that addressed the actual issue and volunteered to switch my remaining work to that plan so the team could still deliver something useful.
Bad examples
🔴I told my lead I didn't think it made sense anymore, and after that I just waited for new direction.
🔴Once we agreed the goal was wrong, we scrapped everything and started over on a different feature.
Weak answers stop at flagging the issue or create unnecessary waste; strong answers show follow-through and care for making the pivot practical.
Valuable
Staff candidates should show they can align multiple parties through a difficult reset, especially when people have invested heavily in the old plan.
Good examples
🟢I tailored the conversation by audience: engineers needed clarity on what changed technically, while product and leadership needed the business reasoning and transition risk.
🟢I treated the shift as a trust exercise, giving teams context, acknowledging prior assumptions were reasonable, and making the new decision path transparent.
Bad examples
🔴I shared the analysis broadly and expected each team lead to cascade the message however they thought best.
🔴I emphasized that we couldn't let emotions about sunk cost get in the way of doing what was rational.
Weak answers undervalue the human side of redirecting work; strong answers show intentional, audience-aware communication that reduces defensiveness and confusion.
At staff level, tradeoff quality matters a lot because your course corrections can create second-order effects across teams.
Good examples
🟢I assessed where a pivot would break dependencies, staged the change in a way that isolated the highest-risk teams first, and used interim metrics to decide whether to continue redirecting.
🟢I explicitly weighed customer commitments, engineering rework, and organizational credibility before recommending a partial redirect rather than an all-or-nothing switch.
Bad examples
🔴I knew the goal was wrong, so I prioritized speed of change over everything else and let downstream teams adapt later.
🔴I kept all teams on the original plan until we had total certainty, because I didn't want to create churn.
Weak answers ignore second-order consequences or wait unrealistically for certainty; strong answers make bounded, risk-aware adjustments.
For junior candidates, humility matters: show what you missed, what you learned, and how you would spot the issue earlier next time.
Good examples
🟢Part of the reason I didn't notice earlier was that I was focused on finishing my tasks instead of checking whether the feature solved the original complaint, and since then I've started asking that question earlier.
🟢I wasn't the decision-maker, but I did contribute to the momentum by assuming the plan had already been validated, and now I surface contradictory evidence sooner.
Bad examples
🔴The issue was mainly that the requirements weren't clear, but once I noticed the problem I handled it well.
🔴I caught that the goal was wrong because I was paying closer attention than most of the team.
Weak answers protect the ego and place the problem elsewhere; strong answers show honest self-awareness without over-owning everything.
Example answers atlevel
Great answers
On a small internal feature, I was helping add a bulk-edit screen for support agents, and we were probably two-thirds through the work when I noticed something odd during testing. The agents we talked to were still using a spreadsheet first because the real pain was cleaning up bad input data before they ever got to editing. I brought that back to my lead with a few concrete examples and suggested we check whether a simpler validation step would help more than finishing the full screen. We did a quick review with one support lead, confirmed that was the bigger problem, and changed the remaining work to add input checks and a smaller edit option. Some of the backend work was still useful, so we kept that and dropped only the parts tied to the bigger UI. The result was that support used it right away, and I learned not to treat a feature request as the same thing as the underlying problem.
At my last job I was implementing a CSV export so our small product team could hand auditors raw transaction logs; we were probably over halfway done when a compliance rep asked for a quick demo of the fields we'd expose. When I walked through the draft output I realized it would include customer identifiers that weren’t necessary for the auditors’ questions and would increase our risk. I paused the work, raised the issue with my manager and compliance, and we agreed to change the scope to deliver aggregate summaries and a tightly restricted view for any required raw data instead of a full export. I reused the parsing and filtering code I’d already written, added an access check, and ended up delivering something that satisfied the auditors faster while protecting customer data. The experience taught me to check regulatory needs early and balance shipping with minimizing sensitive-data exposure.
Poor answers
I was working on a reporting page and halfway through I felt like it wasn't that important anymore because it had already taken a while. I mentioned that to my lead, and later product decided to move us to something else. We stopped the work and started a different task the next sprint. I think that was a good example because I was flexible and didn't get too attached to what I was building.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late October, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.