Your zero-criticals gate blocked a one-line change over a pre-existing finding. What do you change?
answer
- the gate blamed proximity, not causation
- unblock the person first, separately
- change the scope, never the number
- grandfather with an owner and a date
- concede the specific, hold the general
basics
~20 sRescope the rule from the absolute state to what the change introduced: fail on findings absent from a recorded baseline, and move the pre-existing critical into owned, dated backlog work. Do not simply raise the threshold until the pain stops.
solid answer
~50 sThe gate is punishing proximity rather than causation. The developer edited a file, the scanner reported everything in scope, and an absolute rule fired on a finding they did not introduce and cannot responsibly fix inside a one-line change. Left alone this produces exactly one outcome: overrides, a downgrade to advisory, or a pipeline that people learn to route around. As the lead, unblock the person today through whatever exception path exists, then fix the rule shape rather than the number. Split it into two lanes: findings not in the recorded baseline block; the grandfathered backlog is reported and warned on. Then take the pre-existing critical as your own work item with an owner and a date, so grandfathering does not become permanent. Raising the line from critical to something laxer would be changing the number to make the symptom go away, and it silently weakens the gate for every future change too.
go deeper
Recognise that a gate can fire on a problem the current change did not cause, and that the right first move is to ask what the rule is actually scoped to rather than to look for a way around it.
Explain why an absolute repository-wide condition attaches blame to whoever pushed next, and how scoping the same severity line to newly introduced findings fixes that without weakening it.
Show the sequencing: unblock the person through the documented path, then rescope the rule, then place the leftover finding with a named owner and a date. Be able to name what enforcement you gave up.
Own the negotiation. Concede the specific wrong firing to keep the general rule, and hold the line that a newly introduced critical still blocks — while accepting that the unenforced backlog is now your programme to fund and close.
## Read the failure precisely The rule was *no findings at critical, anywhere in this repository*. It is an absolute statement about repository state, evaluated at a moment attached to a person's change. The change and the finding have nothing to do with each other; the developer is simply the next person to have pushed. The gate is enforcing **proximity, not causation**, and that mismatch is the whole problem. It matters because of who is standing in front of it. The blocked engineer has no context on the finding, no authority to change the component it lives in, and a one-line change they were asked to ship. Every option in front of them is bad: bundle an unrelated security fix into an unrelated change, hunt for a way around the gate, or escalate and wait. A gate that routinely presents only bad options is a gate that will be removed, and it will be removed by people who are behaving reasonably. ## The two wrong fixes **Raise the line.** Moving from critical to a laxer level makes today's failure disappear and quietly weakens the gate for every future change, including the ones that would have introduced a genuine critical tomorrow. It also teaches the organisation that pressure moves the number, which is the precedent you least want to set. **Leave it and tell them to fix the finding.** Defensible in a slide, indefensible in practice. You are asking an engineer to take ownership of a component they do not own, under time pressure, with no review context. The fix will be rushed or the gate will be bypassed. ## The right fix: change the shape, not the number Keep *critical* as the line and change what the line is applied to. 1. **Unblock now.** Use the documented exception path so the one-line change ships. Do this first and separately from the policy work; leaving someone stuck while you redesign a rule is how the gate loses its remaining goodwill. 2. **Rescope to introduced findings.** Record the currently-known findings as a baseline and change the rule to fail only on findings absent from it. The blocked change now passes because it introduced nothing, and a change that genuinely adds a critical still fails. 3. **Keep the backlog visible, not enforcing.** The pre-existing critical stays in the report and in the total. It is warned on, counted, and shown — it just does not stop unrelated work. 4. **Give the backlog an owner and a date.** This is the step that distinguishes a rescoped gate from an abandoned one. Grandfathering with no remediation plan is a permanent amnesty wearing a temporary name. 5. **Write down what happens next time.** The blocked engineer should have been able to read one page telling them what fired, why, who owns it, and what to do. If that page did not exist, its absence is part of the incident. ## The conversation with the team Expect the affected team to argue that the gate is why they cannot ship. Concede the specific point — this firing was wrong, and here is the change — while holding the general one: a change that introduces a new critical will still be blocked, and that is not up for negotiation. Conceding the specific is what buys you the general. Defending the wrong firing because backing down looks weak is how a security lead spends credibility they will need later. ## What you have deliberately given up Be honest about the tradeoff in an interview, because a good interviewer will push on it. Rescoping to introduced findings means you are **not** enforcing the existing backlog through the pipeline. If that backlog is never worked, you have traded a gate that everyone hates for a gate that changes nothing. The mitigation is not technical: it is an owner, a schedule, a visible count, and the willingness to escalate when the count stops moving. The pipeline is a good place to stop regressions and a poor place to force the repayment of debt, because the pipeline can only punish whoever happens to be pushing. ## The signal an interviewer is listening for They want to hear that you separate *unblocking a person* from *fixing a policy*, that your instinct is to change the rule's scope rather than its number, that you can name what you gave up when you did that, and that you took ownership of the leftover backlog rather than quietly redefining it as acceptable.
- The affected team asks you to lower the threshold from critical to high instead. What do you say?That it fixes today's symptom and weakens every future evaluation, including the changes that would have introduced a real critical. The problem is not the level; it is that the rule was applied to the whole repository rather than to what the change added. Offer the rescope instead, and be specific that a newly introduced critical will still block.
- How do you keep grandfathering from becoming permanent amnesty?Attach an owner and an expiry to each grandfathered entry, review the set on a fixed cadence, and track its size as a reported metric so a flat or growing number is visible to whoever funds the work. If an entry passes its date, that is an escalation with a name attached, not a silent renewal.
- How would you have found this before a developer did?Run the rule in a reporting mode against recent changes before it blocks anything, and count how many would have failed and on what. A rule that would have failed a large share of changes on findings they did not introduce is telling you it is scoped wrong, and that is far cheaper to learn from a report than from a blocked engineer at 5pm.
saying these in an interview costs you the question
- Lowers the severity level to make the failure disappear
- Tells the blocked developer to fix an unrelated component
- Defends the firing because backing down looks weak
- Grandfathers the backlog with no owner and no date
- Treats unblocking the person and redesigning the rule as one task