How does type inference work in TypeScript? | Interview Question

Q: How does type inference work in TypeScript?

**Target Audience:** Beginners who wonder how much TypeScript they actually have to write by hand. **Difficulty:** Easy **TypeScript version:** Every inferred type below is proven by a compile-time check that TypeScript 5.4.5 (`--strict`) accepts; outputs are from a real run. > **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. Inferred types are not guessed from memory: each one is checked by the compiler with an `Equal` helper, and the **Verified** section quotes the real output. ## 1. Why This Even Matters — A Story First A new colleague joins and you introduce them as "Priya, she runs the payments team". Nobody needs to hand everyone a printed badge saying *Priya: Engineer: Payments*; people work out the role from what they have seen. TypeScript does the same with your values. Write `let count = 0` and it knows `count` is a number — you never wrote the word `nu

The problem

Question presented to candidate: "A lot of TypeScript code has hardly any type annotations, yet it is fully typed. How does type inference work, where does it come from, and when do you still need to write types yourself?"

What a strong answer should cover:

Inference from initializers, array elements (best common type as a union), object literals and return statements; the result is fixed, not dynamic
Contextual typing: callback parameters and functions assigned to a typed variable get their types from context
Literal widening: const keeps "dark", let and object properties widen to string; as const and annotations prevent it
Limits: parameters are not inferred from call sites (TS7006 under noImplicitAny), empty arrays evolve, mixed arrays do not get a supertype
Control flow analysis narrows a variable after assignments and checks, separate from its declared type
Where to annotate: parameters, public return types, empty collections, object literals that must match a shape

Code / implementation expected: Optional — a few declarations with the inferred type stated, ideally proven with a compile-time check.

inference
basics

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: Beginners who wonder how much TypeScript they actually have to write by hand. Difficulty: Easy TypeScript version: Every inferred type below is proven by a compile-time check that TypeScript 5.4.5 (--strict) accepts; outputs are from a real run.

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. Inferred types are not guessed from memory: each one is checked by the compiler with an Equal helper, and the Verified section quotes the real output.

1. Why This Even Matters — A Story First

A new colleague joins and you introduce them as "Priya, she runs the payments team". Nobody needs to hand everyone a printed badge saying Priya: Engineer: Payments; people work out the role from what they have seen. TypeScript does the same wit

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.

TypeScriptWhere inference happens, proven by compile-time checks

Practice

TypeScriptWhere inference stops or surprises you

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.