Tell me about a time you had to pivot mid-project.
Asked at:
Meta
Salesforce
Capital One
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you operate when reality changes after work is already underway. They want to see whether you can recognize that a plan is no longer the right one, re-evaluate based on new information, and redirect effort without becoming rigid or chaotic. At higher levels, they are also looking for whether you managed tradeoffs, aligned others, and limited wasted work during the pivot.
“Describe a project where new information forced you to change direction after work had already started.”
“Tell me about a time your original plan stopped making sense midway through a project. What did you do?”
“Have you ever had to redirect a piece of work after realizing the initial approach wasn't the right one?”
“Walk me through a situation where a project changed course halfway through.”
“What's an example of a time you had to adjust strategy or scope in the middle of execution?”
Key Insights
- You do not get credit just for having a project change direction; you get credit for how you noticed the need to change, how you reasoned through the options, and how you drove the adjustment.
- A strong pivot story is not 'requirements changed and we complied.' You should show judgment: what new information mattered, what you kept versus discarded, and why the revised path was better.
- Don't frame the pivot as random turbulence that happened to you. Show that you stayed grounded, helped others navigate uncertainty, and turned the change into a managed decision rather than a scramble.
What interviewers probe atlevel
Top Priority
Even as a junior engineer, you should show that you understood what work could be reused, what had to change, and how to avoid unnecessary rework.
Good examples
🟢When we changed the approach, I identified the parts of my earlier work that were still useful, like tests and data mapping, so we didn't lose everything we had built.
🟢I adjusted the implementation to support the revised scope and cut a few nonessential pieces so we could still deliver something solid on time.
Bad examples
🔴Once we changed direction, I threw out the earlier work and started over because that felt cleaner.
🔴I kept implementing pieces from the original plan even though they no longer fit, since I had already spent time on them.
Weak answers either waste prior work or cling to sunk cost; strong answers show practical judgment about reuse, cuts, and sequencing.
At junior level, interviewers mainly want to see that you noticed meaningful new information and didn't cling to the original task blindly.
Good examples
🟢After wiring up the first version, I noticed the data we needed wasn't reliably available in production, so I brought that up with my mentor and confirmed the original plan wouldn't work as intended.
🟢We had started building a feature for one workflow, but early user testing showed people were using a different path entirely, so I shared the evidence and helped revisit the plan.
Bad examples
🔴We changed direction because the tech lead said to, so I just switched to the new task right away without really understanding why.
🔴Partway through, I felt the first approach was annoying to implement, so I pushed for a different one even though we hadn't confirmed there was a real issue.
Weak answers treat the pivot as either blind compliance or personal preference; strong answers show the candidate recognized credible evidence that the original plan no longer fit reality.
Valuable
Your bar is not executive communication; it's showing that you kept the right people informed and asked questions early instead of going quiet in the confusion.
Good examples
🟢After the direction changed, I restated my understanding to my mentor and the product owner so I could confirm what success looked like before continuing.
🟢I shared what parts of my work were affected, asked about the new priority order, and kept my lead posted as I adjusted the implementation.
Bad examples
🔴I assumed everyone understood the change once the ticket was updated, so I just started coding the new version.
🔴I was unsure about the revised plan, but I didn't want to slow anyone down by asking follow-up questions.
Weak answers let ambiguity persist silently; strong answers show proactive clarification and lightweight communication.
Example answers atlevel
Great answers
In my last internship, I was building a dashboard component for a customer support tool, and the original plan assumed we could query historical data directly from one service. After I got the first version working, I noticed the data was incomplete for a lot of real cases, so I brought examples to my mentor and we confirmed the approach wouldn't be reliable. We shifted to a simpler version that used a smaller data set we knew was accurate and postponed one of the filters that depended on the missing history. I reused most of the UI work and updated the tests instead of starting over. We still shipped the dashboard for the main use case that sprint, and later the team used my notes when they expanded it once the data pipeline was fixed.
At a small edtech startup I was asked to add a real-time chat so students could ask tutors questions during lessons. About halfway through a two-week sprint, our compliance lead flagged that we couldn't permanently store messages for users under 18 and needed parental consent, which made my original storage design unusable. I suggested and built a pivot: the chat UI stayed the same, but messages for minors became ephemeral on the server, I added a simple consent modal, and I switched the backend to tag sessions instead of keeping full transcripts. I also wrote a short QA checklist and walked the product manager through the trade-offs so everyone understood the safety implications. We shipped the feature on time with the new restrictions in place, and the team appreciated having clear documentation for future policy updates.
Poor answers
I had a project where we changed direction halfway through because the team decided the original idea was too complicated. I just stopped what I was doing and started building the new version right away so we wouldn't lose time. I didn't think it made sense to spend too much time discussing it since the lead had already made the call. We ended up finishing the new version, so I think I handled the pivot pretty well.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late May, 2026
Mid-level
Late May, 2026
Lockheed Martin
Staff
Mid May, 2026
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.