A behavioural question in the leadership round for a senior SRE role at an Indian UPI payments app. The interviewer wants a real story with numbers, a clear decision process under pressure, and honest reflection, not a hero narrative.
The interviewer asks“Tell me about a time during an incident when the fastest fix on the table was also risky. How did you decide what to do, and what happened?”
I use four questions to weigh speed against risk: is it reversible, what is the blast radius if it's wrong, is there a mitigation that stops the impact without fixing the cause, and what is the smallest change that achieves it. Under pressure I add a two-person rule for anything that writes to production. My story: on a festival evening, a status-poller bug pushed our ledger database to 96 percent CPU and payment success fell from 98.7 to 93 percent. The fastest-looking fix was an index built live on a 400 GB table, and the other was a hotfix. Instead I throttled the poller with an existing flag in two minutes, recovered success to 98.4 percent in nine, and shipped the real fix and the index the next morning. The lesson I turned into process: every high-volume background job now has a concurrency flag before it goes live.
A free account unlocks the rest of it, and saves your progress across every track.