Interview Questions

A discriminated union is a union of object types sharing one literal-typed field — the "tag" or "discriminant", such as kind: "circle" | "square". Switching on that field lets TypeScript narrow which variant is present inside each case, and assigning the switch’s fallthrough to a variable typed never in the default case makes the compiler error if a new variant is ever added and left unhandled — exhaustiveness checking for free.

What they are really testing: Whether the never-in-default idiom has actually been used, the line between people who have read about discriminated unions and people who ship them.

It restricts what T is allowed to be — without a constraint, T could be anything, and the function body could only use operations valid on every possible type, which is essentially none. <T extends { id: number }> says T can be any type as long as it has an id: number, letting the function safely read .id while still accepting whatever object shape qualifies, and keeping the specific input type on the way out.

What they are really testing: Whether constraints are understood as narrowing what is allowed in, not narrowing what comes out — a common confusion.

Partial<T> makes every property of T optional, useful for a patch or update payload. Pick<T, K> builds a new type with only the listed keys K from T. Omit<T, K> is the inverse — every key of T except the listed ones. All three are built from TypeScript’s mapped types underneath.

What they are really testing: The three most-used utility types in real codebases — near-certain to come up when discussing an update endpoint’s type.

At a boundary where the value genuinely is not known yet — parsing JSON, a catch block’s error, a third-party webhook payload. Unlike a specific type, which lets the caller act immediately whether or not that is correct, or any, which lets them act immediately and unsafely, unknown forces a runtime check, a validation library, or a type guard before the value can be used at all.

What they are really testing: Whether unknown is understood as a forcing function for validation, not simply "any but safer".

Assigning an object literal directly to a typed variable triggers a check that flags any property not present on the target type — const u: User = { name: "Ada", extra: 1 } errors even though structurally a User with an extra field would normally be assignable. It does not apply once the value passes through a variable first: const obj = { name: "Ada", extra: 1 }; const u: User = obj compiles, because structural typing allows extra properties on an already-typed value.

What they are really testing: One of the most-asked gotcha questions — whether they know structural typing is looser than the literal-assignment check makes it appear.

It produces a union of an object type’s property-name literal types — keyof User for { name: string; age: number } is "name" | "age". It is the basis for type-safe property accessors, such as a generic get<T, K extends keyof T>(obj: T, key: K): T[K].

What they are really testing: Whether keyof is connected to a concrete, type-safe use case rather than recited as a definition.

It is a different operator from the runtime typeof — used where a type is expected, it takes the compile-time type of a value or variable. It is how a type is derived from an existing object without duplicating the shape by hand, common for config objects and constants.

What they are really testing: Whether they know TypeScript overloads the keyword typeof for two purposes depending on position — usually a real realisation moment for anyone still thinking purely in JavaScript.

A type built by iterating over the keys of another type and transforming each property — { [K in keyof T]: T[K] } is the identity mapped type; adding modifiers builds real ones, for example type Nullable<T> = { [K in keyof T]: T[K] | null } makes every property nullable. Partial, Required and Readonly are all mapped types defined exactly this way in the standard library.

What they are really testing: Whether a small custom one can be written, not only the built-ins named.

A type-level if/else: T extends U ? X : Y — if T is assignable to U, the type is X, otherwise Y. type IsString<T> = T extends string ? true : false is the minimal example; a distributive conditional type applies the check to each member of a union T separately, which is how Exclude and Extract are implemented.

What they are really testing: Basic syntax plus the distributive behaviour over unions, the part most people miss.

It introduces a new type variable to capture part of the type being matched — type ReturnOf<T> = T extends (...args: any[]) => infer R ? R : never pulls out a function’s return type. It is how TypeScript’s own ReturnType and Parameters utility types are implemented.

What they are really testing: Whether one has actually been written or at least read — a real dividing line between using TypeScript and writing its type system.

It tries each declared overload signature in order, top to bottom, and uses the first one the call’s arguments are assignable to — not the best match by any other measure. This is why overload order matters: put the more specific signatures first, or a looser earlier one shadows them.

What they are really testing: Whether overload resolution is known to be order-dependent rather than best-fit — a real source of confusing bugs when overloads are added carelessly.

if ("swim" in animal) narrows animal to the union members whose type actually declares a swim property, useful when the union is not already discriminated by a clean tag field. It is the fallback narrowing technique for shapes not designed with a discriminant in mind.

What they are really testing: Whether an alternative exists to the tag-based discriminated union pattern, for shapes not under one’s control.

{ [key: string]: number } says an object can have any string key, all mapped to a number — used for dictionaries whose keys are not known ahead of time. The risk: TypeScript lets obj[anyRandomKey] be read as a number even for a key that was never set, returning undefined at runtime with no type-level warning unless noUncheckedIndexedAccess is enabled.

What they are really testing: Whether noUncheckedIndexedAccess is known — one of the strict-adjacent flags most projects should turn on but rarely do.

Readonly<T> is a mapped type making every property of an object type T readonly. ReadonlyArray<T> (or its shorthand readonly T[]) is the array-specific version, and it removes access to mutating methods like push and splice from the type entirely, not just individual elements. Both are compile-time only; neither freezes anything at runtime.

What they are really testing: Whether readonly arrays are known to block mutator methods at the type level — a stronger guarantee than making each element readonly.

A declaration file holds only type information, no implementation, describing the shape of JavaScript TypeScript cannot see into on its own — most often a library’s public API. Publishing a TypeScript package emits a .d.ts alongside the .js so consumers get types without the source; consuming a plain-JS library, its .d.ts (often from @types/) is what gives autocomplete and checking against it.

What they are really testing: Foundational for the "publish a typed npm package" portfolio project in Module 16.

Record<K, V> builds an object type with keys K all mapped to value type V — a typed dictionary. Required<T> makes every optional property mandatory, the inverse of Partial. Also worth knowing: Exclude/Extract to filter a union, ReturnType for a function’s return type, Parameters for its parameter tuple.

What they are really testing: Breadth beyond the three most common ones — whether the standard-library toolbox is genuinely familiar.

interface Box<T = string> — if the caller does not specify T, it defaults to string. Useful for a generic that is usually used one way, such as a form field or an API response wrapper, but should stay generic for the less common cases, without forcing every caller to specify the type parameter explicitly.

What they are really testing: A smaller, easily-missed feature — whether it is reached for instead of duplicating a generic and a non-generic version of the same type.

const config = { mode: "dark" } satisfies Config checks the value against Config without widening or replacing its inferred type — unlike const config: Config = {...}, which forces every property to exactly the type Config declares. With satisfies, config.mode keeps the literal type "dark" instead of widening to string, so both the validation and the precise inferred type are kept.

What they are really testing: A relatively recent feature (TypeScript 4.9+) — whether they have kept up with the language and understand the widening problem it solves.

An interface is purely a type with zero runtime code, and a class can implement several. An abstract class can hold shared implementation — fields, concrete methods — alongside abstract members that subclasses must fill in, but a class can only extend one. Reach for abstract classes when subclasses genuinely share behaviour, not only a shape; reach for interfaces for the shape alone, or when unrelated classes need to satisfy the same contract.

What they are really testing: Whether abstract classes are known to carry real runtime code and single inheritance, unlike interfaces.

private/protected are compile-time only — the emitted JavaScript has a completely ordinary property, reachable at runtime through bracket notation or a type assertion; they exist purely to catch mistakes during development. #field is a real ECMAScript private field enforced by the JavaScript engine itself, genuinely inaccessible from outside the class at runtime, in any language.

What they are really testing: Whether TypeScript's access modifiers are known to offer zero runtime protection — relevant if a candidate has ever assumed otherwise.

A type built like a template string but at the type level, combining literal types — type Event = "click" | "hover"; type Handler = `on${Capitalize<Event>}` produces the union "onClick" | "onHover". Used for things like CSS-in-JS property names or event handler prop names derived from a smaller set of event names.

What they are really testing: A newer feature (TypeScript 4.1+) — depth of type-system fluency past the basics.

Both filter a union T against U. Exclude<T, U> keeps the union members NOT assignable to U — removal. Extract<T, U> keeps only the members that ARE assignable to U — selection. They are mirror images, both implemented as distributive conditional types.

What they are really testing: Whether the two are actually remembered correctly — commonly swapped even by people who use them regularly.

In the default case of a switch over a union, assign the by-then-narrowed-to-nothing remaining value to a variable typed never: default: { const check: never = state; throw new Error("unhandled") }. If a new union member is added later and its case forgotten, that member is no longer narrowed away by the time it reaches default, so it is no longer assignable to never, and the compiler errors right there instead of the gap reaching runtime.

What they are really testing: The concrete mechanism, not just "never means it cannot happen" — whether they would actually use it in a pull request.

Typing an object that must have exactly one entry per member of a union or enum — Record<Status, string> for type Status = "idle" | "loading" | "error" forces a label to be provided for every status, and the compiler errors if one is missing or a mistyped key is added. It turns "did I handle every case" into a type error instead of a runtime gap.

What they are really testing: Whether Record is understood as a completeness tool, not only a loose dictionary type.

import type { Config } from "./config" imports only the type, guaranteed to be erased completely at compile time — it can never accidentally pull in runtime code or create a circular runtime dependency. It matters for bundlers and transpilers that process files one at a time, since they cannot always tell from a plain import whether a name is a type or a value; a type-only import removes the ambiguity.

What they are really testing: Whether an isolatedModules error has actually been hit and fixed in a real build, versus never having used a bundler that needed it.