Admission blocked a deploy for a rule an editor check could have caught days earlier — what do you change?
answer
- the rule was right; the timing was not
- placement defect, not policy defect
- add a home, do not move one
- render earlier so review sees what admission sees
- count denials decidable from source alone
basics
~20 sAdd an earlier home for the same standard rather than weakening or moving the late one. The problem is feedback latency, not the rule: the developer paid three days for a verdict the editor could have given in a second. Keep the late check as the backstop.
solid answer
~50 sTreat this as a placement defect, not a rule defect. The rule was right and the deploy was correctly blocked — what failed is that the cheapest point that could have decided it was not running it. So: add the same standard as an editor or pre-commit check and as a pull-request check, phrased against the input those points can see, and keep the admission check exactly as it is, because it is the only point that sees the object after templating and injection. Make the denial message name the standard and point to the local check, so the next developer can reproduce the verdict on their laptop. Where the violation is only visible after rendering, render in CI and evaluate the rendered output at pull-request time so review sees what admission will see. Then measure it: what fraction of last month's denials were decidable from source alone? That number is the case for the work.
go deeper
Recognise that a blocked deploy can be a correct decision delivered at the wrong time, and that the fix is usually an extra check earlier rather than a weaker rule.
Explain why the early and late checks read different documents, and why adding one does not let you remove the other.
Show the full move: add the earliest home that can decide the rule, keep the backstop, render earlier to converge the inputs, fix the denial message, and bring the latency numbers that justify the work.
Own the trade in public. Argue for engineering time spent on feedback latency using the share of late denials that were avoidable, and hold the line against relaxing a correct rule to buy peace with a delivery deadline.
## Read the situation correctly first A developer's deploy failed at the last gate. The rule was correct, the object genuinely violated the standard, and the block did its job. The complaint is still legitimate, and it is not "the rule is too strict" — it is **"why am I hearing this now?"** Three days ago the same verdict was derivable from the file they had open. The defect is in placement, not in policy. This distinction matters because the two obvious reactions are both wrong. Weakening the rule so it stops blocking trades a correctness problem you do not have for one you did not have. Moving the rule earlier and deleting it from admission trades completeness for speed and leaves the standard unenforced for everything the early point cannot see. ## What you actually change **Add the earliest home whose input can decide the rule.** If the condition is present in the source file, an editor or pre-commit check can decide it, and it answers in under a second to the person who wrote the line. A pull-request check catches the same thing for anyone who did not run local tooling, and it lands on a change that is still being worked on. **Keep the late check unchanged.** The early points read source text; admission reads the object after templating, substitution and whatever the pipeline injected. Those are different documents, so the early check cannot certify the late one. You also cannot know, at admission, which objects passed a local hook and which did not — trusting local tooling to have run is not something the late point is in a position to do. **Close the visibility gap where you can.** A large share of "only admission could see it" cases are really "nothing rendered it earlier". If the pipeline renders the final object anyway, render it at pull-request time and evaluate the rendered output there. That moves the verdict from deploy day to review time without giving up any of the input admission has. **Fix the message, not just the placement.** A denial that says a constraint name and nothing else costs the developer another hour. The message should name the standard in the same words the early check uses, say which field violated it, and say how to get the same answer locally. This is what converts a block from an obstacle into feedback. ## Then measure it, because that is what makes it a case The argument for spending engineering time on early checks is empirical, and it is easy to produce. Take last month's denials at the late gate and split them: which were **decidable from source alone**, and which genuinely required the rendered object? The first bucket is pure waste — every one of those is a developer who waited days for an answer that was available immediately. The second bucket is the late gate earning its keep. Track the median time from the commit that introduced the violation to the denial; that is your feedback-latency number, and it is the one to drive down. If the first bucket is large, you have a concrete backlog: those are precisely the rules that need an earlier home. ## The trap to avoid The seductive wrong move is to conclude that because the early check now exists, the late one is redundant and can be narrowed to "the cases the hook misses". You cannot enumerate those cases at admission — the late point does not know what the early point saw, and the whole reason it exists is that its input is different. The early check reduces how often the late check fires. It never reduces what the late check must be prepared to catch. The second trap is blaming the developer for not running the hook. If a check only fires when someone remembers to run it, its coverage is a matter of habit; the fix is to also run it at a point the change cannot avoid, not to write a reminder in a wiki. ## The shape of a good answer Say, in order: the block was correct; the cost was latency; add the earliest home whose input can decide it; keep the late one because it reads a different document; render earlier where you can so the two documents converge; fix the denial message; and bring a number showing how much of the late gate's traffic was avoidable. That sequence shows you are optimising the developer's experience without giving up the guarantee.
- The team asks you to drop the admission check now that the pre-commit hook covers it. Your answer?No. The hook reads source text; admission reads the object after templating, substitution and pipeline injection, so they decide different instances of the same standard. Admission also cannot tell which objects came from a machine that ran the hook. The early check reduces how often the late one fires; it does not reduce what the late one must catch.
- What signal tells you a rule is placed too late?Two numbers. First, the share of denials at the late gate that were decidable from source alone — high means the verdict was available much earlier. Second, the median time from the commit that introduced the violation to the denial. If that is measured in days for rules whose input never changed after commit, the placement is wrong regardless of how anyone feels about it.
- How would you handle a violation that genuinely only appears after rendering?Move the rendering, not the rule. If the pipeline can produce the rendered object at pull-request time, evaluate it there — same input as admission, days earlier. Where rendering depends on facts only available at deploy time, the late check is the right home and the honest fix is a denial message good enough to resolve in one attempt.
saying these in an interview costs you the question
- Weakens the rule so it stops blocking
- Moves the rule earlier and deletes the late check
- Blames the developer for not running the local hook
- Assumes a local check makes the late check redundant
- Treats a correct late block as a policy failure