As a tech lead, how would you decide where a non-null assertion (`!`) is acceptable in a TypeScript codebase and where it must be replaced by a real check?

## Start from what an assertion actually trades A non-null assertion costs nothing at run time and buys nothing at run time. What it does is convert a compiler error today into an invariant that no tool will ever check again. That framing turns the question from a style debate into a risk-allocation decision: an assertion is acceptable when the invariant is cheap for a human to re-verify whenever the surrounding code changes, and unacceptable when it is not. ## The three buckets **Boundary data.** Anything that entered the process from outside — a parsed response body, a config file, an environment variable, a query result, an element looked up in a document — has an unknown shape at compile time. The declared types are frequently optimistic already, so an assertion here compounds a guess with a promise. The policy is *parse, don't assert*: validate once at the edge with a schema validator or a hand-written guard, produce a type that reflects what was actually verified, and let everything downstream be assertion-free by construction. This is where nearly all incidents traced to `!` originate. **Locally established invariants.** `map.set(key, [])` on one line and `map.get(key)!.push(item)` on the next is a claim a reviewer can confirm without leaving the screen. Same for indexing a literal you just wrote, or a fixture built in the same test setup. I accept these. The cost of eliminating them — restructuring code so the compiler can follow the reasoning — is often higher than the risk, and the risk is bounded because the proof and the claim live together. My test is distance: if the assertion and the statement that makes it true cannot be read in one view, it is not this bucket. **Lifecycle fields.** Fields filled by a framework hook, a dependency-injection container, or a test setup function are the intended home of the definite-assignment assertion. I accept them when the guarantee is real and documented, and push first for the alternatives that remove the question: constructor injection, or a static factory that performs async setup and returns a fully built instance. The important constraint is *ownership* — the assertion belongs in the class that owns the lifecycle, never scattered across callers who merely hope initialization happened. ## Designing the assertion away The strongest version of this answer is structural. Most assertions exist because a type is describing a shape looser than the code's real contract. A function that returns `{ root: HTMLElement }` after doing the lookup and check itself removes the assertion at every call site. A discriminated union that separates the initialized state from the uninitialized one removes an entire class of definite-assignment fields. Every assertion is a small piece of evidence about where the model is imprecise, which makes a census of them a useful design signal, not just a compliance list. ## The governance layer Default-deny with a documented escape works better than either extreme. The `@typescript-eslint/no-non-null-assertion` rule flags the operator; the team norm is that a suppression comment must state the invariant in words. Review then asks exactly one question per assertion: *what makes this true, and can I see it from here?* A hard ban tends to backfire in a specific and predictable way: people write `as SomeType` instead. That is strictly worse — the cast silences shape errors as well as nullability, it survives unrelated type changes without complaint, and it is harder to grep for meaningfully because legitimate casts are common. Optimising the metric `count of !` while ignoring where the escapes migrate is a classic false win. ## What I would actually measure - Location mix rather than raw count: what fraction of assertions sit in boundary code versus local code, and is that fraction moving? - Incidents traced back to an assertion, which is the only outcome measure that matters. - Whether new boundary code arrives with a validator, since that is the intervention that removes the whole category rather than policing it. ## The interview point A principal-level answer resists both "ban it" and "it is fine, it is erased". It classifies by where the knowledge lives, names the migration risk of a naive ban, and proposes making the types honest so that most assertions have no reason to be written in the first place.