Tell me about a time you took responsibility for a problem that was not your fault.
answer
- the gap, and whose it was not
- why you picked it up
- what you owned, concretely
- the real owner kept in it
- outcome, plus who owns it now
basics
~10 sTests whether ownership means outcomes rather than blame allocation. Pick a problem you could have walked away from, say why you picked it up, what you personally did, and where ownership landed afterwards.
how to answer
5 beats- the gap, and why it was not yours to fixSet the boundary in a sentence or two so the listener understands you had standing to walk away. Keep this to roughly a fifth of the answer, and describe the gap without characterising whoever left it.
- the call you made to pick it upSay what tipped it — who was being hurt, what would not have happened otherwise — and what you traded to make room. A stated cost is what turns volunteering into judgment.
- what picking it up actually involvedThis is the bulk, around sixty percent. Give the concrete sequence in the first person, including the awkward parts: the permission you had to get, the code you had to learn, the conversations you had to open.
- how you kept the real owner in itShow that you worked with the people whose area it was rather than around them. One line of what you said to them is worth a paragraph of describing your intentions.
- the outcome and where ownership landedClose with the measurable result and a named owner who is not you. Result and handover together take about a quarter of the airtime.
your answer
4 story prompts- Pick a problem you had legitimate standing to ignore, and genuinely could have.
- Name what you dropped or delayed to make room for it.
- Check that your story ends with an owner who is not you.
- Avoid any version where the point is who really caused the mess.
draft and rehearse your own answer in a learn session
go deeper
This probes ownership and organisational maturity: whether you define your job by outcomes or by the boundary of your assignment. Interviewers listen for judgment about when to step in, restraint about blame, and evidence that you handed the problem back rather than becoming its permanent owner. Rescuing without a handover reads as a liability, not a strength.
The open-source checkout library I help maintain depends on payment adapters that live in other people's repositories. The adapter most of our users install had quietly gone unmaintained after its author changed jobs. It parsed expiry timestamps in local time, so once clocks shifted, valid callbacks were rejected and orders sat unconfirmed — and the bug reports were filed against us, because ours is the name on the install line. I could have closed those as out of scope, and two other maintainers argued that I should. I took it instead, and I wrote out my reasoning in the thread: from a shopper's seat this is one product, and storefronts running that adapter were down 1.9 points on completed orders. I spent four days inside a codebase I did not know, wrote the failing test first, and pushed the fix through the adapter's own release process rather than forking it, which meant finding the original author and asking for a review instead of taking the shortcut. Then I did the part I think mattered more. Two of the contributors I had been mentoring wanted more surface area, so with the author's agreement they went on as co-maintainers of that adapter. Ownership landed on people, not on me. Orders were confirming normally inside a week. What I owned was never the bug — it was the outcome for the people installing our package, and the fact that none of us had noticed the adapter was orphaned.
The judgment beat carries this: the reasoning was argued in public, against colleagues who disagreed, and grounded in user impact rather than in duty. The handover to two mentees is what keeps it from reading as heroics. Dropping the handover, or naming the absent author as the villain, would downlevel it sharply.
Zoom out from that same project. Twenty-two people held commit rights somewhere across the library and its adapter ecosystem, and every group could show a green build in its own repository — yet nobody was accountable for whether a storefront could take an upgrade without its checkout regressing. In the preceding cycles we had shipped three regressions to users that way; the worst cost one large installer 2.6 points of completed orders for nine days before anyone connected it to a release of ours. No single maintainer had caused that, and no single maintainer could be asked to fix it. I said in the governance thread that I would own the outcome for six months, and I was explicit about the end date so it did not become my identity. The work was mostly unglamorous: a shared upgrade-verification suite that any adapter could run, a pre-release window where installers test against a candidate build, and a rotation so that one named maintainer signs off on each release. I taught the rotation rather than staffed it — I ran the first two myself, then paired through four more with people I was mentoring. By the end, releases went out with a signature from someone other than me, and we had not shipped a conversion regression since the second rotation. My contribution was accepting that the gap was mine to close and then making sure the answer was not me.
This works because the speaker takes accountability for a structural gap with no owner, bounds it with a stated end date, and builds an arrangement that survives their exit. The named handover and the metric together prove it. Without the time bound, the same story reads as an indispensable person describing their own indispensability.
At your level this is usually small and local — a broken setup script or a flaky suite nobody claims. Show that you fixed it instead of filing a ticket about it, and that you told the owner what you changed and why.
Feature scope. The interesting part is that you weighed picking it up against your own commitments, said so to whoever depended on you, and returned the problem in better shape than you found it rather than silently absorbing it.
Team and production scope, and the signal is judgment: why this particular gap was worth your time, how you took it on without undercutting the group that owned it, and who holds it now that you are done.
Organisational scope. Show you took accountability for an outcome no single team owned, refused to make yourself the permanent answer, and left behind a named owner and a working arrangement instead of a dependency on you.
saying these in an interview costs you the question
- Using the story to expose whoever actually dropped it
- Heroics with no handback, so you own it forever and call that ownership
- Accepting blame you did not earn instead of fixing anything
- No outcome at all, just the fact that you volunteered
- Martyrdom framing, where the cost to you is the point of the story
- Steamrolling the team that owned it rather than bringing them along
- How did the person who owned it react?Describe it factually and generously. Interviewers use this probe to find out whether your ownership humiliated someone. The strong version shows you gave them the choice, the credit, or at minimum the heads-up before you touched their area — and that the working relationship survived the episode intact.
- Who owns it today?Have a real answer. Ownership that ends with you permanently is not a success story; it is a bus factor you created. Say who holds it now, how the handover happened, and what made it stick — a named person, an agreed rotation, a documented path. If it did land back on you, say so and say why.
- What did picking that up cost you?Name what slipped or what you dropped, and who you told about it. Claiming there was no cost implies you had slack you were not using. The credible version shows you made a trade deliberately and communicated it, rather than quietly running two jobs and expecting recognition for it.
- When do you decide not to step in?Give your actual filter in one or two sentences — impact on people who depend on you, whether stepping in weakens the owner, whether you are the only one who can. This probe separates ownership from compulsive rescuing, and interviewers are reassured by a candidate who can describe a problem they deliberately left alone.