Tell Me About a Project That Failed or Slipped

Everyone has shipped something that went sideways. The interviewer knows this, so a polished "I've never really failed" answer just tells them you lack self-awareness or you're not telling the truth. What they want is a real failure you can describe calmly, with a clear sense of what you'd do differently.

What they're really asking

Do you take ownership when things go wrong, or do you reach for excuses? Can you analyze a failure honestly and pull a concrete lesson out of it? They are also checking that you don't blame teammates, since that's how you'd talk about them too once you're hired.

How to structure your answer

STAR works here, but the weight shifts. Situation and Task stay short. Action covers what went wrong and what you did once you saw it slipping. Result is where you show growth: what was the actual outcome, and what changed in how you work because of it. Pick a real failure with stakes, but not one so catastrophic it makes you look reckless. A slipped deadline you handled well beats a vague disaster.

A sample answer

I owned the frontend for a checkout redesign that was supposed to ship in six weeks. We hit week five with the happy path working and assumed we were nearly done. Then QA started on edge cases: saved cards, expired sessions, partial refunds. The old checkout had years of these baked in and we'd treated them as afterthoughts. We slipped by three weeks.

The root cause was on me. I'd estimated based on the visible UI and never audited the existing logic for hidden states. Once I saw the gap, I stopped pretending the date was real. I went to the PM with a revised plan that listed every untested state and a confidence level for each, so they could decide what was launch-blocking versus a fast-follow.

We shipped the core flow three weeks late and the rest over the next sprint. After that I changed how I scope frontend work. Now I spend the first day of any rewrite cataloguing the states the old code handles, because the UI is the easy part and the edge cases are where the time goes. Nothing has surprised me like that since.

What to avoid

• Blaming the deadline, the backend team, or "shifting requirements" without owning your slice.
• Choosing a fake failure ("I cared too much and worked too hard"). It's transparent.
• Stopping at the failure with no lesson or behavior change.
• Picking something so severe it makes you sound dangerous to hire. Keep it real but proportionate.