TypeScript interview questions

The fundamentals

• Structural typing. TypeScript compares shapes, not names - two unrelated types with the same members are assignable. This surprises people from nominal languages.
• `interface` versus `type`. Declaration merging, and the practical answer that it rarely matters and teams should just be consistent.
• `any` versus `unknown`. `unknown` forces you to narrow before use; `any` disables checking. Preferring `unknown` at boundaries is the answer they want.
• `never` - where it appears, and why exhaustiveness checks use it.
• Narrowing - `typeof`, `in`, instanceof, discriminated unions, and writing a type guard.

Generics

• Write a generic function that preserves the input type - `identity`, or a `pick` helper.
• Constraints with `extends`, and why `<T extends object>` is often needed.
• When are generics overkill? A real answer here signals judgement rather than enthusiasm.
• Generic components or hooks if the role is React-heavy.

Utility and mapped types

• `Partial`, `Required`, `Pick`, `Omit`, `Record` - and being able to implement `Partial` yourself with a mapped type.
• `Readonly`, and what it does and does not guarantee at runtime.
• Conditional types at a basic level, and what `infer` is for.
• Why template literal types exist and a practical use.

The practical half

Expect a question about typing data that arrives from an API - the correct instinct is that the compiler cannot verify runtime data, so you either validate at the boundary or accept that your types are a claim rather than a guarantee. That answer separates people who have shipped TypeScript from people who have configured it. Related ground is in JavaScript interview questions and React interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and honesty about what you have not done reads better than bluffing.
• Mid-level: the same ground, plus a codebase you have typed. Expect follow-ups asking why you made a particular choice rather than whether you know the syntax.
• Senior: migrating a JavaScript codebase incrementally, and where you chose to stop. At this level the language questions get shorter and the judgement questions get longer.

Whatever the level, the reliable way to prepare is to say your answers out loud rather than reading them. Most of what candidates lose in a TypeScript interview is lost in the gap between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common TypeScript interview questions?

Structural typing, `interface` versus `type`, `any` versus `unknown`, narrowing and type guards, generics with constraints, and the built-in utility types such as `Pick` and `Omit`. Implementing `Partial` with a mapped type is a common exercise.

What is the difference between any and unknown?

`any` switches off type checking for that value, so anything is permitted. `unknown` accepts any value but forces you to narrow before using it. Preferring `unknown` at untyped boundaries such as API responses is the answer interviewers look for.

How do you type data coming from an API?

Declare the expected shape, but recognise the compiler cannot verify runtime data - types are a claim, not a guarantee. The robust approach is validating at the boundary with a schema check and deriving the type from that validator.

Is it acceptable to use any in an interview answer?

Yes, with reasoning. Saying that `any` is occasionally pragmatic at an untyped boundary but should be contained rather than allowed to spread reads as experience; claiming you never use it reads as rehearsed.