Tell me about a time you fixed something nobody had asked you to fix.

Two things are being weighed at once

The obvious read is initiative: will you notice a problem and deal with it without a ticket. The less obvious read, and the one that decides the score for anything above entry level, is judgement about which problem. An engineer who fixes everything they notice is not an asset, because their committed work slips, their team cannot predict them, and half of what they build becomes an unowned tool that stops working in six months. So the answer needs both halves visible: you saw something, and you decided it was worth the trade.

The strongest version of this story has a specific property. The problem was one other people were already paying for, in time or in noise, and could describe if asked. That is what separates initiative from taste. Rewriting a module because you found the style unpleasant is a preference; fixing the thing that makes four people wait twenty minutes every afternoon is a cost you removed from other people's days, and they will vouch for it.

Sizing it before you start

Interviewers listen for whether the decision to begin was made deliberately. Three questions do almost all of it, and they can be answered in a sentence each inside the story.

Who is feeling this, and how often? A number here need not be precise, only derived from something real. "Six people on the team, most days, twenty minutes" is a defensible estimate. "It was really annoying" is not a case.

How long is this, honestly, and against what? The credible answer names a bound and says what it was measured against: two days, out of a sprint where the committed work was a week's worth. Work that has no bound is where unasked initiative turns into a manager discovering in week three that their assigned feature has not moved.

Who did you tell? This is the part candidates omit, believing that asking first makes the story less impressive. It has the opposite effect. Telling your lead you intend to spend two days on it, before starting, is what makes the following weeks a decision rather than a secret, and it is also how the work survives — a fix nobody knew about has nobody to maintain it.

A pattern to adapt rather than repeat

This is deliberately a small, early-career example, because the question does not require a large one. The moves are what to copy.

"On my first team we tested a claims portal, and the end-to-end suite in CI failed roughly one run in three for reasons that had nothing to do with the change. Everyone had learned to just press re-run. Nobody owned the suite.

I started keeping a note of every red build for two weeks — which test, which stage, and whether the same commit passed on a re-run. It came out at about thirty spurious failures in a fortnight, and two thirds of them were four tests that all waited on the same animated modal. So the size of the problem was maybe half an hour a day across the team, and the size of the fix looked like a couple of days rather than a rewrite.

I took the tally to my lead in our one-to-one and asked for two days in the following sprint rather than doing it quietly, partly because I wanted the time and partly because I was not sure the four tests were worth keeping at all. She agreed, and also told me the second cluster — anything touching the payment sandbox — was known to be unfixable from our side, which saved me a day of chasing it.

I replaced the waits on those four with an explicit condition on the element rather than a fixed delay, and I deleted one test that duplicated a unit test. Then the part that mattered more than the fix: I added a weekly summary of re-run counts to the team channel, because otherwise nobody would notice the next time it drifted. Failure rate over the following month came down to about one run in twelve, which is not zero, and the remaining ones were the sandbox cluster I had been told to leave.

What I did not touch was the local test setup, which was genuinely worse and would have been a fortnight. I flagged it in the retro instead, and it got picked up as real work by someone with more context than me two months later."

Note how little of that is the technical fix. The tally that made the problem visible, the conversation before starting, the deliberate non-fix, and the weekly report that keeps it from regressing are the ownership signals. The fix itself is two paragraphs of Selenium waits and nobody is grading it.

The version of this answer that backfires

A story about unasked work becomes a negative when it reveals that you preferred your own agenda to the team's. The tells are recognisable: nobody knew until it was finished, it took several times longer than the story admits, it replaced something that worked with something only you understood, and it was abandoned as soon as you got interested in something else. If your best example has any of those properties, tell it anyway but name the cost — "I spent about a week of time nobody had allocated and I should have said so on day one" — because volunteering that reads as growth, whereas letting the interviewer discover it in follow-up reads as blindness to the cost.

The other quiet failure is the answer where the fix has no afterlife. If it broke again, or if the dashboard you built is dead, that is worth saying: the reason it did not stick, once you can state it, is more interesting than a fix that stuck by luck.

Unasked work is scored on the decision, not the deed: a problem other people were paying for, a bound you set in advance, someone you told before you started, and something else you noticed and left alone.