Tell me about a time you built something that was not what the requester actually wanted.

Partway through a long database migration, the operations lead asked me to stop the operational dashboards timing out while we were running against two clusters at once. I read that as a straightforward performance problem and spent about three weeks routing dashboard queries onto a replica and reworking the four slowest panels. The demo landed flat. Timeouts had never been the real pain. What hurt was that two dashboards showed different totals during the cutover window and the operations team could not tell which one to trust, so they had stopped using both. Nobody had said that out loud, and I had never asked what the timeouts were actually costing anyone. I took it in the room rather than defending the ticket text. The replica work stayed, because it was genuinely useful, but I added a staleness stamp on every panel and a read-your-writes path for the two panels feeding reconciliation. That was nine extra days I had not planned. The measured outcome came out fine — saturation on the reporting pool went from 88 percent to 52 percent and the disputed-total escalations stopped entirely for the rest of the programme. But the durable outcome was the habit. Before I build now I write one paragraph back to the requester saying what breaks if we do nothing and how we will know it is fixed, and I do not start until they reply to it. It has caught two similar misreads since.

I was accountable for the connection-pressure workstream ahead of a large cluster cutover. The direction I was handed was to get connection counts down before the migration weekend, and I took it at face value. Two engineers and I spent roughly five weeks building a pooling proxy tier in front of the database. Then we instrumented what we already had, properly, and the picture inverted. Seventy-one percent of pool checkouts came from one service that opened a connection per item inside a fan-out loop. A proxy would have masked that, carried it across into the new cluster, and handed it to someone else a quarter later as a mystery. I said so in the migration review, in those words: five engineer-weeks spent on the wrong layer because I had accepted a proposed solution as if it were a problem statement. I made sure the framing was about my acceptance, not about the two people who built what I asked for. We shelved the proxy and batched the fan-out instead, and checkouts per request went from fourteen to three inside nine days. Cutover weekend peaked at 46 percent saturation rather than pinning, and the proxy branch was retired unmerged. The part that stuck was the intake change. No remaining workstream started without a one-page problem statement naming the symptom, the measurement expected to move, and who confirms it moved, signed by the requester and by me. One of the last four got cancelled once its statement was written, which I count as the best result of the set.