What is the definite assignment assertion (!)? | Interview Question

Q: What is the definite assignment assertion (!)?

**Target Audience:** Developers who meet `field!: Type` in Angular, ORM or class-heavy code and want to know what it promises and what it costs. **Difficulty:** Medium **TypeScript version:** Every compiler message and output below was produced with TypeScript 5.4.5 (`--strict`, target ES2022). > **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. All output shown was produced by actually running the code; the **Verified** section quotes it in full. ## 1. Why This Even Matters — A Story First A hotel receptionist will not hand you a room key until the bill is settled. One evening a regular guest says: "My company pays — the invoice arrives tomorrow." The receptionist cannot see the invoice, but marks the bill as "settled — guest guarantees it" and hands over the key. That mark is the definite assignment assertion. TypeScript is the receptionist: it refuses to let y

The problem

Question presented to candidate: "What does the ! mean in name!: string on a class field, or in let total!: number? Why does TypeScript make you write it, and what are the risks compared with initialising the value properly?"

What a strong answer should cover:

The definite assignment assertion: ! after a property or variable name says "this is assigned before use", silencing TS2564 (property has no initializer) and TS2454 (used before being assigned)
Why the error exists: strictPropertyInitialization (part of --strict) only follows the constructor body, not helper methods, frameworks or callbacks; both features arrived in TypeScript 2.7
It is unchecked: if the value is never assigned, the program reads undefined with a type that says string
The difference from the non-null assertion operator (expr!), which applies to an expression rather than a declaration
Emit detail: with ES2022+ class fields, field!: T is still emitted as a field, which can overwrite a value set by a base-class constructor; declare field: T emits nothing
Alternatives: initialisers, constructor parameter properties, honest optional types (field?: T), or restructuring so the compiler can see the assignment

Code / implementation expected: Optional — a class with a field initialised in a helper method, and the safer alternatives.

definite-assignment

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 meet field!: Type in Angular, ORM or class-heavy code and want to know what it promises and what it costs. Difficulty: Medium TypeScript version: Every compiler message and output below was produced with TypeScript 5.4.5 (--strict, target ES2022).

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. All output shown was produced by actually running the code; the Verified section quotes it in full.

1. Why This Even Matters — A Story First

A hotel receptionist will not hand you a room key until the bill is settled. One evening a regular guest says: "My company pays — the invoice arrives tomorrow." The receptionist cannot see the invoice, but marks the bill as "settled — guest guarantees it" and hands over the key.

The solution is hidden so you can try first

9 min read · 10 sections

Run the code

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

TypeScriptFields, locals, the other ! and safer alternatives

Practice

TypeScript! versus declare under ES2022 class field emit

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.