TypeScript Interview Questions and How to Answer Them

If you have shipped TypeScript for a year and still feel unready for the interview, the gap is usually not syntax. This section covers what interviewers are really probing, which is whether you understand the type system as a system rather than as annotations you add until the red squiggles stop.

Three themes carry most interviews. The first is what the compiler knows and when: inference, narrowing, and the fact that every type disappears before your code runs. The second is composition: generics, unions, and the utility types built on keyof and mapped types. The third is judgment, which is where senior candidates separate themselves. Knowing that any exists is table stakes; being able to say where you would accept it and where you would reach for unknown and a runtime check is the answer they remember.

Framework questions ride along with all of this. React roles ask about typing props, hooks, and event handlers. Node roles ask about typing request handlers and third-party modules that ship no types of their own.

These recur across companies and levels, and each one has a follow-up waiting behind it.

• What is the difference between interface and type? Interfaces merge across declarations and read naturally for object shapes. Type aliases express unions, tuples, mapped and conditional types. Follow-up: which would you use for a public library surface, and why.
• How do any, unknown, and never differ? any turns checking off, unknown accepts anything but makes you narrow before you touch it, and never is the type with no values. Follow-up: how never gives you an exhaustive switch.
• What is structural typing? Compatibility is decided by shape, not by which interface a value was declared against. Follow-up: how to get nominal behavior back with a branded type.
• How does narrowing work? typeof, instanceof, in, truthiness, discriminated unions on a literal tag, and user-defined predicates of the form x is Foo. Follow-up: why a predicate you wrote badly is a silent lie to the compiler.
• Explain generics with constraints. A parameter bounded by extends lets a function stay general while still accessing known members. Follow-up: write Pick or Omit from scratch.
• What does strict actually enable? Name strictNullChecks and noImplicitAny at minimum, and be ready to describe migrating a codebase into strict mode file by file.

Newer material shows up at senior level: the satisfies operator for checking a value against a type without widening its inferred type, and as const for literal types. More role-specific banks are collected in the question library.

The common format is a small JavaScript module handed to you untyped, with a request to type it properly in twenty or thirty minutes. The module usually hides two traps: a function whose return type depends on its argument, and an API response the code trusts without checking.

A frontend engineer interviewing for a senior role at a logistics company was given a fetch wrapper and a render function. She typed the wrapper generically, then said plainly that the generic was a promise the compiler could not keep, because nothing validated the response at runtime, and she added a narrow guard before the parsed data crossed into typed code. That sentence about erasure was what moved the interview forward, not the annotations.

Talk while you type. Say why you reach for a union instead of an enum, why you are not exporting a type, why one any is staying with a comment on it. Silent correct code scores below noisy correct code in almost every rubric, and the habit is worth rehearsing on the mock interview page before the real round.

Reading type-system explanations builds recognition, not recall. The interview asks for a definition in your own words in about thirty seconds, and that is a different skill. Pick six questions from the list above and answer each one aloud, timed, without notes.

Run the same set again a day later, because the ones you lose are the ones you learn. A mock interviewer that asks the follow-up rather than accepting the first answer is what makes this work; setup is on the tutorial page.

For the live interview itself, an assistant that listens to the interviewer and suggests structure can help when a question arrives from a corner of the language you use rarely. It works on desktop meeting clients and in a browser tab, and it does not join the call as a participant. It is out of scope on a proctored assessment platform, on a recorded screen share, or on a company-managed laptop, so the questions you can answer cold are the ones that count.