TypeScript Interview Questions to Ask Before You Hire

12 TypeScript interview questions — with what to listen for

1. 1

   Explain structural typing and how it differs from nominal typing. Where does structural typing surprise people?

   What a strong answer covers

   Compatibility by shape, not declaration; surprises: unrelated types interchangeable when shapes match, empty-object types accepting nearly everything, excess-property checks applying only to fresh literals. Branded/nominal-simulation types for IDs as the escape hatch shows applied depth.

2. 2

   Where is TypeScript's type system deliberately unsound, and what does that mean for how much you trust compiled code?

   What a strong answer covers

   any as an infection vector, type assertions overriding the checker, bivariant method parameters, unchecked array indexing without noUncheckedIndexedAccess, and runtime data crossing boundaries unvalidated. The conclusion matters: types are compile-time claims, so validate at I/O boundaries with runtime schemas.

3. 3

   unknown versus any: what does each permit, and what is your policy for a team codebase?

   What a strong answer covers

   any disables checking and spreads; unknown forces narrowing before use. Policy: unknown at untrusted boundaries, any banned or lint-restricted with justification comments, and noImplicitAny as table stakes. This tiny question reliably separates disciplined TypeScript users from JS-with-annotations users.

4. 4

   Walk me through type narrowing — the mechanisms the compiler understands, and a custom type guard you have written.

   What a strong answer covers

   typeof, instanceof, in, truthiness, discriminated-union tag checks, and control-flow analysis; user-defined guards with is predicates and their honesty burden (the compiler trusts you). A discriminated-union-with-exhaustive-switch example plus never-based exhaustiveness checking is the gold-standard answer.

5. 5

   Design the types for a function that takes a config object and returns a differently-shaped result depending on options. What tools do you reach for and when do you stop?

   What a strong answer covers

   Overloads versus generics with conditional types, mapped types, and inference-friendly design — plus the judgment to stop: when the type gymnastics cost more than a small API redesign that makes the types simple. The 'stop' half is the senior half.

6. 6

   What do generics constraints (extends), keyof, and mapped types let you express? Show me with a utility you have actually built.

   What a strong answer covers

   Real utilities: typed pick/omit variants, form-state types derived from models, event maps keying handler payloads. Fluency with keyof, indexed access, and template-literal types applied to a genuine problem beats reciting the utility-type catalog.

7. 7

   How do discriminated unions change how you model application state, compared to optional-field bags?

   What a strong answer covers

   Making illegal states unrepresentable: loading/success/error unions where data exists only on success, versus boolean-and-optional soup allowing contradictions. Exhaustive switch handling as the payoff. This is the single most transferable TS design skill — weight it heavily.

8. 8

   A third-party library ships bad or missing types. Walk me through your options in order of preference.

   What a strong answer covers

   Check DefinitelyTyped, augment via declaration merging, local .d.ts declarations, wrap the library behind your own typed interface, and targeted assertions as the last resort with comments. Module-augmentation mechanics distinguish people who have actually done it.

9. 9

   What does strict mode actually turn on, and which flags beyond strict do you add to a new project?

   What a strong answer covers

   strictNullChecks as the big one, noImplicitAny, strictFunctionTypes and friends; additions like noUncheckedIndexedAccess and exactOptionalPropertyTypes with their ergonomics costs known. Reasoned flag opinions demonstrate they have configured real projects, not inherited configs.

10. 10

    Plan the migration of a 100k-line JavaScript codebase to TypeScript — sequencing, tooling, and how you keep the team shipping meanwhile.

    What a strong answer covers

    allowJs incremental adoption, boundary-first typing (APIs, shared utilities), checkJs with JSDoc as an on-ramp where useful, codemod tooling, strictness ratcheted module by module rather than a permanent loose mode, and any-count as a tracked metric. Team process — reviews, conventions — belongs in the answer.

11. 11

    How does TypeScript interact with your runtime validation — where do zod-style schemas fit, and what is the single-source-of-truth pattern?

    What a strong answer covers

    Static types vanish at runtime, so external data needs schema validation with types inferred from schemas (z.infer) to avoid drift; validation placed at API edges, environment parsing, and queue consumers. Candidates who type API responses with assertions alone have not been burned yet — this finds them.

12. 12

    Your build and editor have become slow in a large TypeScript monorepo. What levers exist?

    What a strong answer covers

    Project references with incremental builds, isolatedModules enabling transpile-only fast paths (esbuild/SWC) with typechecking parallelized in CI, interface extraction to shrink type surface, and diagnosing expensive types (tracing). Knowing typecheck and transpile are separable is the operational insight.

Frequently asked questions