How to Talk About Failed Projects in an Interview

Every designer who has been doing this work for more than a couple of years has shipped something that didn't work — a flow that confused people, a feature nobody used, a redesign that measurably made things worse. This is not a rare or shameful outlier; it's close to a statistical certainty for anyone who has actually been making decisions rather than just executing someone else's. Claiming otherwise in an interview doesn't read as a strong track record. It reads as either dishonest, or not self-aware enough to recognize a failure when it happened, and both readings are worse for a candidate than admitting the truth.

It helps to understand what the question is actually probing for, because it's rarely genuine curiosity about the failure itself. An interviewer asking about a failed project is testing three things at once: whether a candidate has the self-awareness to identify their own mistakes accurately, whether they can talk about their own judgment honestly instead of only in flattering terms, and — most importantly — whether something durable came out of the experience. A candidate who nails the polish of their portfolio but flinches at this question is telling the interviewer something real about how they'll behave the next time a project of theirs goes sideways on the job.

Two common mistakes show up here constantly. The first is dodging: offering a story that's technically a failure but is actually a disguised humble-brag, something like 'I was too ambitious and the timeline was unrealistic,' with no real ownership in it. Interviewers see through this immediately, and it costs more credibility than it saves. The second mistake is the opposite — oversharing a genuinely bad outcome with no structure, spiraling into self-criticism or blame without ever landing on what it actually taught the person. Both versions waste a question that, handled well, is one of the more persuasive moments available in the entire interview.

The structure that actually works is straightforward: what the goal was, what specifically went wrong, and — the part almost everyone skips — what changed in how the candidate works because of it. Each piece does different work. The goal establishes the stakes and shows the thinking wasn't careless from the start. The specific failure shows the candidate can look at their own decisions plainly, without spin. The change is the part that turns a bad outcome into evidence of something an interviewer can actually use — a sense of how this person operates differently now.

Getting the first part right matters more than it seems. Stating the original goal clearly — what the project was meant to accomplish, for whom, under what constraints — establishes that the failure wasn't the result of sloppy thinking from the outset. A designer who says 'we were trying to reduce drop-off at a specific step, and here's why we thought this approach would do it' sounds fundamentally different from one who jumps straight to 'it didn't work,' even if the underlying story is the same. Context earns the failure some credibility before the failure itself is even described.

The middle section — what specifically went wrong — is where vagueness does the most damage. 'It just didn't resonate with users' explains nothing and sounds like an excuse dressed up as analysis. 'We shipped based on a stakeholder's assumption about how people would use a feature, without testing it first, and usage was a fraction of what we projected' is concrete, ownable, and specific enough to be believable. The goal here isn't self-flagellation, and it isn't quietly redirecting blame onto a manager or a client either — it's a plain, accurate account of the actual mechanism of the failure, stated without defensiveness.

The closing piece is what interviewers are actually listening for, and it's the part that separates a forgettable answer from a genuinely persuasive one. A failure with no lasting change attached is just a bad outcome — it happened, it was unfortunate, and nothing about the story suggests it won't happen again under similar pressure. A failure that produced a permanent, specific adjustment to how someone works is real evidence of growth. A designer who says 'since then, I run a lightweight test before committing engineering time to any assumption about user behavior, no matter how confident stakeholders are' has turned the story into proof of a durable change in judgment, not just an anecdote.

A reasonable edge case worth addressing directly: what about failures that were genuinely catastrophic, or politically sensitive enough that discussing them honestly could create real professional risk. The right move there isn't to invent a safer fake failure — that undermines the whole point — but to choose, from among several real options, one that's substantial enough to be credible without dragging in details that aren't the candidate's to share, like specific confidential business impact or naming who else was responsible. And for the rare person who genuinely can't identify a real failure after real reflection, that itself is worth sitting with before the interview, because it usually means the bar for what counts as a mistake has been set too high to be useful.

In practice, a strong version of this answer has a clear arc: a real goal with real stakes, a specific and ownable account of what broke and why, and a concrete practice or habit that exists today because of it. It doesn't need a redemptive ending where everything worked out — plenty of good failure stories simply end with a better process going forward, with no dramatic comeback attached. The absence of a triumphant conclusion doesn't weaken the story. It's often what makes it sound true.

Framed this way, a well-chosen failure story frequently lands better in an interview than another success story would have. Success stories are common, and increasingly they're rehearsed to the point of sounding interchangeable across candidates. A specific, well-told failure is much harder to fake convincingly, because faking one requires inventing a plausible mistake and a plausible lesson at the same time, under the pressure of a live conversation — and interviewers who've heard hundreds of these answers are unusually good at spotting the seams in an invented one.

There's a broader cost to avoiding this question that goes beyond the single answer. A candidate who visibly dodges or minimizes a request to talk about failure raises a flag that colors how the interviewer hears everything else in the conversation, including the genuinely strong parts. If someone won't be straight about a mistake in an interview, where the stakes are relatively low, an interviewer reasonably wonders how straight they'll be about a mistake on the job, where the stakes are considerably higher.

Preparing this story deserves the same deliberate attention most candidates already give their portfolio walkthrough, rather than being treated as an improvised afterthought for whenever the question happens to come up. It isn't really a story about one bad project. It's the clearest evidence a candidate can offer, in a single answer, of how they actually respond when their own work doesn't hold up — which, for anyone doing this work long enough, is a question that eventually stops being hypothetical.