Tell me about a project that failed. What did you learn?

The interviewer is checking whether you can name a real failure and own your part in it. Sanitised failures don't yield real lessons; the strong answer has some discomfort in it.

STAR walkthrough — sample answer:

Situation: A previous team I was on attempted a cross-cutting initiative to consolidate three separate test infrastructures (one per squad) into a unified shared platform. I co-led the initiative with an engineering manager. The pitch was solid — shared maintenance, common patterns, less duplication. We got senior leadership sign-off and committed to a quarter for the rollout.

Task: Deliver the consolidated platform with all three squads migrated by end of quarter.

Action / what went wrong: We hit problems by week 3.

• The three squads' existing setups had subtle but important differences we'd underestimated — a "consolidation" that respected all three was substantially more complex than the design suggested.
• I'd assumed adoption would be near-automatic if we built the platform; in practice, each squad had legitimate concerns about migration risk that we hadn't engaged with deeply.
• Two senior engineers on different squads pushed back hard on the imposed timeline. We had no plan for that pushback.

By week 6 we were behind, two squads had effectively stalled, and I was working long hours trying to "push through." That should have been the signal that the plan was wrong, not that I needed to push harder.

End of quarter, only one squad had migrated — and they were the one that had been most aligned with our initial design. The other two stayed on their existing setups. The shared platform had been built but was used by one team. Net effect: more code, not less.

Result: I called it. Wrote an honest retro: what we'd assumed, what was wrong with those assumptions, what we'd actually delivered (limited value), and a recommendation that we either invest properly in adoption (a follow-up quarter) or sunset the initiative. Leadership chose the latter.

What I learned (the actually useful version):

Adoption isn't a delivery sub-task; it's the whole project. The design didn't fail; the engagement with the people who'd use it failed. On subsequent platform initiatives I've started with the adoption design — who agrees, what migration support looks like, what we'll do when (not if) someone pushes back — before writing the technical design.

"Push through" is rarely the right answer at the 6-week mark. If a 12-week project is underwater at 6 weeks with no sign of recovery, the plan is probably wrong. I've been faster to call that on subsequent work.

Honest retros are an asset. The retro from that failure has been referenced multiple times in subsequent platform conversations, including by people I didn't know read it. Owning a failure publicly built credibility I didn't expect.

Why this works: real failure with the candidate's own judgement implicated, specific lessons that map to subsequent behaviour, and the discomfort isn't sugar-coated. The strongest senior signal is being able to talk about a failure without flinching.