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.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).