Cruxly › Behavioral › Competencies
Failure
you were wrong, it cost something, and you say so
Open the interactive lessonWhat is scored: can you identify your own mistake accurately, own the part that was yours, and change your behaviour as a result?
This is the competency candidates prepare least and interviewers weight most, because it is the hardest to fake.
What the interviewer is looking for
- A real failure with real consequences. Not a near-miss you caught, not a risk that did not materialise. Something went wrong and it cost time, money, trust or an outage.
- Your own contribution, stated first. Before any context about what else went wrong.
- An accurate diagnosis. Not "I should have communicated better", which is the universal non-answer. What was the misjudgement?
- A behaviour change, and evidence it stuck. The sentence is "since then I...".
- Proportionate emotion. Neither defensive nor excessively self-flagellating. Both are uncomfortable to sit with, and the second reads as instability rather than humility.
The size matters. A failure too small reads as evasion; interviewers will probe for a bigger one and you will be improvising. Pick something that genuinely cost.
Weak and strong, same prompt
Prompt: tell me about a significant failure.
Weak.
"We shipped a feature that had a bug in it and some users saw incorrect data for a few hours. We rolled it back and added more tests. The lesson was that we needed better QA processes, which we implemented afterwards."
No agency — things happened, nobody decided anything. No diagnosis, just "more tests". And the lesson is organisational, which quietly moves the failure off the candidate. An interviewer will probe this and the candidate will have nothing.
Strong.
"I argued to delay a database migration by a quarter, and I was wrong, and it cost us about two months of engineering time. We were on a version going end-of-life in nine months. I looked at the migration and saw a lot of risk — schema changes on our largest table, a query planner that behaved differently, and a team already committed to a launch. I made the case to push it to the next quarter and I won that argument. What I got wrong was treating the risk as fixed. It was not — it was growing. In that quarter we added two services on the old version and 40% more data to the table that was already the hard part. When we came back to it the migration was meaningfully harder than the one I had declined to do, and we spent roughly two months instead of the three weeks it would have taken. The specific misjudgement was that I compared 'do it now' against 'do it later' as if later were the same work. For anything on a deprecation clock, later is always more work, and I did not put a number on how much. Since then, when I argue to defer something, I write down what the cost of doing it later will be and what would have to be true for deferring to be right. I did that on a Kafka upgrade last year and it flipped my own recommendation — I had assumed deferring was cheap and it was not."
Real cost, own decision, precise diagnosis, and a behaviour change with evidence it was applied again. The last paragraph is what makes it a senior answer.
Question bank
- Tell me about a significant failure.
- Describe a time you made a bad decision.
- Tell me about a time you were wrong about something technical.
- What is the biggest mistake you have made professionally?
- Tell me about a project that did not go well.
- Describe a time you missed a deadline.
- Tell me about feedback that was hard to hear.
- Tell me about a time you had to tell someone bad news.
The last two are adjacent and often unprepared. Have a story where you received difficult feedback and acted on it.
Where these answers go wrong
The disguised success. "We were too ambitious and only delivered 80% of a huge project." Recognised immediately, and it costs you the credibility you were trying to protect.
Diffuse blame. "The requirements were unclear, the timeline was unrealistic, and QA was under-resourced." Even if all true, you have told the interviewer nothing about yourself.
"I should have communicated more." The universal non-answer. Occasionally it is the real diagnosis, and then you must be specific: to whom, when, what you would have said, and what would have changed. Usually it is a way of not naming the actual misjudgement.
No consequence. A mistake that cost nothing is not a failure, and interviewers will keep probing until they find one that did.
Too much contrition. Long, uncomfortable self-criticism makes the interviewer's job unpleasant and reads as poor calibration. State it plainly, own it, move to the lesson. You are demonstrating that you can hold your own mistake steadily, not that you feel badly about it.
How to say it in the interview
"The worst call I have made was arguing to delay a migration by a quarter. I was wrong about the risk, and the delay cost us more than the risk would have."
Checklist
- The failure had a real, stated cost
- You stated your own contribution before any context
- The diagnosis is specific, not 'I should have communicated better'
- You changed a behaviour and can give an instance where you applied it
- It is not a disguised success
- Your tone is steady: neither defensive nor excessively contrite
- You also have a story about receiving hard feedback and acting on it