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.
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.
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
At junior level, interviewers mainly want to see that you can notice important signals and avoid blindly executing once the goal stops making sense.
Good examples
🟢Halfway through the feature, I noticed the test users were using a manual workaround that solved the original pain point faster than our new flow, so I raised that our success metric might be off.
🟢As I implemented the second half, I saw that most of the bug reports were actually caused by confusing setup steps rather than the missing feature we were building, and I brought that pattern to my lead with examples.
Bad examples
🔴We were mostly done and my tech lead said we should stop because product changed direction, so we stopped and picked up the next task.
🔴I felt the project wasn't worth it anymore because it was taking too long, so I suggested we drop it and work on something simpler.
Weak answers treat the goal change as something handed to them or as a feeling; strong answers show the candidate noticed concrete evidence that the team was optimizing for the wrong thing.
Valuable
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
Hello Interview Premium
Your account is free and you can post anonymously if you choose.