How do you do exhaustiveness checking? | Interview Question

Q: How do you do exhaustiveness checking?

**Target Audience:** Developers who `switch` over unions and want the compiler to flag every place that must change when a new variant is added. **Difficulty:** Medium **TypeScript version:** Every error message below was produced by TypeScript 5.4.5 with `--strict`; the `satisfies` version fact is cited from the 4.9 release notes. > **How to read this doc:** Every idea is explained in plain language first, then tagged with `📌 Interview term:` so you also learn the exact words an interviewer expects. Type claims are checked by `tsc` (an `Equal ` line or a `// @ts-expect-error` line), and the **Verified** section quotes the real output in full. ## 1. Why This Even Matters — A Story First A pilot runs a checklist before take-off. The point of a checklist is not the items you remember; it is the item you would have forgotten. Now imagine the airline adds a new item to the checklist, and the printed copies in half the cockpits are never updated. Those pilots will happily finish "th

The problem

Question presented to candidate: "A teammate adds a new status to a union type, and three switch statements across the codebase silently stop handling it. How would you make the compiler catch that the next time?"

What a strong answer should cover:

Exhaustiveness checking: once every member of a union is handled, the narrowed type in the remaining branch is never, and code that requires never stops compiling when a member is left over
The assertNever(x: never): never helper in default, which also throws at run time for data that escaped the type system
x satisfies never (4.9+) as a helper-free compile-time check, and a declared return type with no default (TS2366) as a weaker check
Record<Union, T> lookup tables, which force every key to be present
The error messages name the forgotten member, which makes the fix obvious; the check works on literal unions and discriminated unions alike
Trade-offs: run-time safety for external data, and why a default that returns a fallback value defeats the check

Code / implementation expected: Yes — a switch over a union with an assertNever default, and the error you get after adding a member.

never
exhaustive

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Developers who switch over unions and want the compiler to flag every place that must change when a new variant is added. Difficulty: Medium TypeScript version: Every error message below was produced by TypeScript 5.4.5 with --strict; the satisfies version fact is cited from the 4.9 release notes.

How to read this doc: Every idea is explained in plain language first, then tagged with 📌 Interview term: so you also learn the exact words an interviewer expects. Type claims are checked by tsc (an Equal line or a // @ts-expect-error line), and the Verified section quotes the real output in full.

1. Why This Even Matters — A Story First

A pilot runs a checklist before take-off. The point of a checklist is not the items you remember; it is the item you would have forgotten. Now imagine the airline adds a new item to the checklist, and

The solution is hidden so you can try first

9 min read · 11 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

TypeScriptassertNever and satisfies never on a string union

Practice

TypeScriptObject unions, Record lookup tables and the return-type check

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.