With one sprint of capacity, do you fix the likely-but-bounded threat or the remote-but-catastrophic one?

## The question behind the question An interviewer asking this is not looking for a winner. They are checking whether you understand that a likelihood-impact rating is an input to a decision and not the decision itself, and whether you know that the two shapes call for different *kinds* of response rather than different positions in one queue. ## Separate the rating from the fix decision Nothing in either axis mentions cost, and cost is decisive at sprint granularity. Bounding a date range on the enrolment endpoint is a contained change with a test; nobody should be arguing about its rank against anything, because the correct comparison is against its own trivial cost and a hard calendar deadline. Meanwhile the crane relay's fix is not a task — signed or authenticated telemetry, network segmentation and a fail-safe on implausible readings is a design programme. Putting it on the same list as a parameter check invites the worst outcome available: the sprint spends its capacity on a fraction of the big job, ships nothing usable, and the small certain problem is still there when enrolment opens. So the answer is that both move, in different lanes: - **Sprint fix**: the enrolment bound, plus any cheap partial measure available on the crane path — rate limiting, a plausibility ceiling on readings, alerting on telemetry from an unexpected source. - **Scheduled design work**: the telemetry authentication and segmentation, with a named owner and a date. - **Explicit acceptance**: whatever exposure remains between now and that date, written down with the assumption it rests on. ## Challenge the low likelihood hardest where impact is catastrophic A remote-but-catastrophic rating is only as good as the assumption underneath it, and here the entire rating rests on one clause: the relay is reachable only from the operational network. That clause is invalidated by a vendor maintenance link, an engineering laptop that also reaches corporate email, a flat VLAN nobody has re-checked since commissioning, a contractor with physical access, or a future integration that quietly bridges the two networks for a reporting dashboard. Rare, high-consequence estimates are the least reliable ones in any model, because there is no experience to calibrate them against and the failure modes are correlated in ways nobody enumerated. So the deliverable is not just a rating, it is a **written assumption with a test**: state that the rating depends on network isolation, and put a periodic check of that isolation next to it. There is also a floor rule worth stating in an interview: where the credible worst case is physical harm to people, likelihood does not license a shrug. Those threats get escalated out of the engineering queue regardless of how the arithmetic lands, because the organisation's tolerance for that outcome is not an engineering parameter. ## Why not just combine the two ratings A single combined score sorts the queue, which is exactly the problem: it makes two threats that need completely different responses look like neighbours on one list. Collapsing them loses the information a decision-maker needs — whether the risk is a steady drip you can bound with a code change, or a rare event that would end a business line. Present the rating, but present it with the shape and the response type attached. One list is fine for a director who wants one list; it just needs three lanes in it. ## Who decides, and what acceptance means An engineer or a lead can decide to defer a bounded availability threat. Nobody in the engineering organisation should be quietly accepting a life-safety or company-ending risk on their own authority — the point of surfacing the shape is to route the decision to the person whose job it is to carry it. A legitimate acceptance has four parts: a named accountable person, an expiry or review date, a compensating measure in the meantime, and the written assumption that justified the low likelihood so it can be re-tested. An acceptance without those is not a decision, it is the threat quietly leaving the model. ## What a weak answer looks like Multiplying the two ratings and fixing the larger product; or the opposite reflex, always dramatising the catastrophic one and letting the certain, cheap, deadline-bound fix slip. Both replace judgment with a rule, and both are visibly wrong the moment the enrolment window opens or someone plugs a laptop into the wrong switch.