Describe a challenging situation where a project or initiative under your leadership wasn't going as planned and how you persevered to overcome the situation.
Asked at:
Meta
other
CrowdStrike
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question is assessing how you behave when leadership gets tested by adversity rather than by steady-state execution. Interviewers want to see whether you can recognize that something is off, take meaningful ownership, adapt your plan, and keep moving without becoming reactive or defeatist. At higher levels, they are also judging whether the challenge and your response match the scope expected for your role.
“Tell me about a time a project you were driving hit serious obstacles. What did you do?”
“Describe a situation where an initiative under your leadership started going off track. How did you respond?”
“Have you ever had to recover a project that was struggling? Walk me through what happened.”
“What's an example of a time you had to keep a team or project moving despite setbacks?”
“Can you share a time when your original plan was not working and you had to lead through the recovery?”
Key Insights
- You do not get much credit for saying the project was hard; you get credit for showing how you diagnosed why it was off track, changed course, and stayed effective through multiple setbacks.
- Pick a story where the difficulty was real and consequential. If the problem was minor or resolved by a single clarification, you will miss the chance to show perseverance, judgment, and leadership under pressure.
- Do not make perseverance sound like stubbornness. Strong answers show you kept pushing toward the goal while being willing to change tactics, sequence work differently, reset expectations, or narrow scope.
What interviewers probe atlevel
Top Priority
For junior roles, the bar is not huge scope; it is whether you made a meaningful contribution to recovering a real problem within your area.
Good examples
🟢I owned a clearly defined piece of the delayed feature, adapted my approach, and helped the team hit the revised test window.
🟢Even though I was not leading the whole project, I took responsibility for resolving a meaningful issue in my area and made it easier for others to continue.
Bad examples
🔴I owned one bug in a delayed release and stayed late to finish it, which helped the whole project recover.
🔴My task was blocked for a day, but I kept checking in until someone answered and then I finished my part.
Weak answers overstate tiny contributions; strong answers are appropriately scoped and credible about impact.
For junior candidates, perseverance means staying engaged, asking for help appropriately, and changing your approach based on what you learn.
Good examples
🟢After my first approach failed, I documented what I had tried, asked for targeted help, and came back with a simpler implementation that we could ship safely.
🟢When the work started slipping, I broke my task into smaller checkpoints, communicated progress more often, and adjusted the design to reduce risk.
Bad examples
🔴I kept trying the same fix a few more times because I was sure it would eventually work.
🔴Once the timeline slipped, I mostly waited for my lead to tell me the next steps and then followed that plan.
Weak answers confuse effort with progress; strong answers show the candidate actively changed tactics and owned their part of recovery.
Valuable
You do not need executive-level communication at junior level, but you should show that you raised risks early and kept the right people informed.
Good examples
🟢As soon as I realized my estimate was off, I told my lead what I had learned, the likely impact, and the two options I saw.
🟢I gave short updates as I worked through the issue so the team could adjust testing and avoid surprises.
Bad examples
🔴I did not mention the delay until our regular check-in because I wanted to solve it first.
🔴I posted a quick status message saying things were blocked, but I did not explain what I needed or what might change.
Weak answers hide risk or communicate incompletely; strong answers are timely, concrete, and useful to others.
Interviewers want to hear that you stayed constructive, learned something, and did not turn the story into a blame narrative.
Good examples
🟢I was definitely stressed, but I focused on what I could control and learned to raise uncertainty earlier next time.
🟢Even though part of the problem was outside my control, I came away with a better way to break down risky work and ask for feedback sooner.
Bad examples
🔴The main challenge was that other people were not responsive, but I stayed positive and eventually it got sorted out.
🔴It was frustrating because the requirements kept changing, so there was not much I could do except keep working.
Weak answers externalize the problem and offer no real learning; strong answers stay constructive and extract a usable lesson.
Example answers atlevel
Great answers
In my first year, I was responsible for building part of an internal reporting feature, and about halfway through I realized my approach was too slow and was going to miss our test deadline. Instead of just trying to power through, I compared the slow cases, talked with a more experienced teammate, and figured out that I had chosen a needlessly complex way to process the data. I told my lead the deadline was at risk, explained the simpler option, and reworked my part of the feature around that approach. I also started giving short daily updates so QA knew when to expect a stable build. We hit the revised test window, and the feature shipped a few days later than originally planned but without the quality issues we were starting to see. The big thing I learned was to surface risk earlier and simplify sooner when a first design is not paying off.
At a small edtech nonprofit I was leading a short project to add keyboard navigation and screen-reader support to a key course page, and halfway through volunteer testers reported that some of the updates actually made interactive widgets unusable. With only a few paid engineers, I reprioritized to fix the blockers first instead of finishing every planned enhancement: I arranged focused pair-programming sessions with a senior engineer for the tricky widgets and broke the remaining work into small, testable tasks volunteers could do. To make volunteer contributions reliable, I filmed a two-minute walkthrough and wrote a one-page checklist showing how to test accessibility behaviors. Within two weeks the major regressions were resolved, the highest-impact accessibility items were deployed, and students who use assistive tech could actually use the course—teaching me the value of small increments, clear instructions, and leveraging others’ strengths rather than trying to do everything myself.
Poor answers
I had a project where things were not going as planned because there were a lot of last-minute bugs. I stayed focused and kept fixing issues as they came in until everything was working. I did not want to raise concern too early because I thought I could solve it on my own, and eventually I got through the list. In the end the feature went out, so I think it showed I can persevere when things get challenging.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid March, 2026
other
Senior
Early January, 2026
CrowdStrike
Senior
Early December, 2025
Meta
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.