Common TypeScript Interview Questions

This topic collects the TypeScript questions that show up most often in front-end and full-stack interviews. It covers the fundamentals — type annotations, interfaces, generics, the compiler, and tsconfig — mixed with short code-tracing exercises so you can practice reasoning about what the compiler will accept or reject. Read each question, try to answer it yourself before reading the explanation, and pay close attention to the code snippets: interviewers frequently ask you to predict a compiler error or the inferred type of a variable rather than just define a term.

TypeScript is a strongly typed superset of JavaScript developed by Microsoft that compiles down to plain JavaScript. Every valid JavaScript program is also valid TypeScript (with rare edge cases), and TypeScript adds optional static types, interfaces, generics, and modern syntax support on top. The TypeScript compiler (tsc) performs type checking at compile time and then erases all type annotations, producing ordinary JavaScript that runs unchanged in any JS engine.

'any' disables type checking entirely — you can call any method or access any property on an 'any'-typed value without the compiler complaining, which defeats the purpose of TypeScript. 'unknown' is the type-safe counterpart: a value of type 'unknown' can hold anything, but you cannot perform any operation on it until you narrow its type with a type guard (typeof, instanceof, or a custom check). 'unknown' forces you to prove the type before using it, so it should be preferred over 'any' whenever the type genuinely cannot be known in advance.

This produces a compile-time error: 'Object literal may only specify known properties, and z does not exist in type Point.' This is TypeScript's 'excess property check', which only applies to object literals assigned directly to a typed variable. If the object were first assigned to a separate variable (const temp = { x: 1, y: 2, z: 3 }; const p: Point = temp;) it would compile, because excess property checks do not apply through an intermediate variable — only structural compatibility is checked in that case.

Generics let you write reusable functions, classes, and interfaces that work over a variety of types while preserving type information, instead of resorting to 'any'. For example, function identity<T>(arg: T): T { return arg; } returns exactly the type it was given: identity<string>('hi') is typed as string, and identity(42) infers T as number automatically. Generics are the backbone of type-safe collections, utility types, and API client code where the shape of data varies by call site.

Both can describe the shape of an object, and in many cases they are interchangeable. Key differences: interfaces support declaration merging (declaring the same interface twice merges the members), while type aliases do not; interfaces can only describe object/function shapes (extended with 'extends'), while type aliases can also name unions, intersections, tuples, and primitives (type ID = string | number;); interfaces are generally preferred for public object APIs because of merging and clearer extension syntax, while type aliases are preferred for unions and complex compositions.

'strict': true is a shorthand that turns on a family of stricter checks at once, including strictNullChecks (null and undefined are not assignable to other types unless explicitly included), noImplicitAny (variables/parameters without an inferable type raise an error instead of silently becoming 'any'), strictFunctionTypes, strictPropertyInitialization (class properties must be initialized or explicitly typed as possibly undefined), alwaysStrict, and a few others. Enabling strict mode is considered best practice for any serious TypeScript codebase because it catches an entire class of null-reference and implicit-any bugs at compile time.

Type inference is TypeScript's ability to determine a variable's type from its initializer without an explicit annotation. For 'let items = [1, "two", 3];' TypeScript infers the array type as (string | number)[] — a union array type — because the literal contains both number and string elements. If the array had used 'const' with a tuple-like structure and 'as const', TypeScript would instead infer a readonly tuple of literal types.

A type guard is an expression that narrows a variable's type within a conditional branch, using constructs like typeof, instanceof, 'in', or a custom user-defined type predicate (function isFish(a: Fish | Bird): a is Fish). Discriminated unions combine a shared literal 'tag' property (e.g. kind: 'circle' | 'square') across each member of a union with a switch or if statement on that tag; TypeScript automatically narrows the type inside each branch based on the discriminant's value, enabling exhaustive, type-safe handling of each variant.

'readonly' on an interface or class property prevents reassignment after initialization (a compile-time-only restriction — it does not freeze the object at runtime). 'as const' goes further: applied to a literal, it tells TypeScript to infer the narrowest possible literal types and make array/object properties readonly, e.g. const colors = ['red', 'green'] as const; infers readonly ['red', 'green'] instead of string[]. This is commonly used to derive precise union types from arrays of string literals via typeof colors[number].

TypeScript infers the generic parameter T as 'string' from the call argument 'hello', so the return type of wrap is inferred as { value: string }, and 'result' has the type { value: string }. This demonstrates contextual generic inference: you never have to write wrap<string>('hello') explicitly because the compiler infers T from the argument's type.

'void' is used for functions that do not return a meaningful value (they may still implicitly return undefined). 'never' represents values that never occur at all — it is the type of a function that always throws an exception or contains an infinite loop, and it is also the type of an unreachable branch, such as the default case of an exhaustively-checked switch. Assigning anything to a 'never'-typed variable outside of 'never' itself is a compile error, which makes 'never' useful for exhaustiveness checks.

When importing a plain JavaScript package without bundled or DefinitelyTyped (@types/package-name) declarations, TypeScript raises 'Could not find a declaration file'. You can resolve this by installing the community types (npm install --save-dev @types/package-name), writing your own .d.ts declaration file, or adding a fallback 'declare module "package-name";' ambient declaration, which types the import as 'any' and silences the error while still compiling.