TypeScript · Advanced interview

A conditional type chooses between two types based on an assignability test: T extends U ? X : Y. infer introduces a type variable captured from the matched position, letting you extract a piece of a type — for example, pulling the resolved value out of a Promise or the return type of a function. Together they're how utilities like ReturnType and Awaited are built.

type Unwrap<T> = T extends Promise<infer U> ? U : T;

When the checked type of a conditional is a naked type parameter and you pass a union, the conditional distributes over each member and unions the results. So T extends any ? T[] : never applied to A | B gives A[] | B[], not (A | B)[]. You can switch distribution off by wrapping the parameter in a tuple ([T] extends [U]), which is a common trick when you don't want it.

Both use recursion with conditional/mapped types. Awaited recursively unwraps nested promises with infer until the type is no longer a thenable. DeepReadonly maps each property, recursing into object types and leaving primitives alone, adding readonly at each level. The key skills are recursion, infer, and a base case to stop.

type DeepReadonly<T> = T extends object
  ? { readonly [K in keyof T]: DeepReadonly<T[K]> }
  : T;

Template-literal types build string literal types from other types, e.g. `on${Capitalize<Event>}`. Combined with unions they expand combinatorially, and with key remapping in mapped types they can derive property names. They're used for typed event names, route params, CSS-in-JS keys, and turning string patterns into precise types.

type EventName<T extends string> = `on${Capitalize<T>}`; // "click" -> "onClick"

The as clause in a mapped type lets you rename or filter keys while mapping. You can prefix keys, build getter names with template literals, or drop keys by mapping them to never. It's how you transform one object type's shape into another — for example, generating a set of getX methods from a properties type.

type Getters<T> = { [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K] };

A type can reference itself to model nested structures — JSON, trees, deep utility types. TypeScript supports recursion but enforces a recursion-depth limit to keep checking finite, and tail-recursive conditional types are optimized to allow deeper chains (useful for things like parsing tuples). Push too far and you hit 'type instantiation is excessively deep' errors, which usually means simplifying the type.

Covariance means a type relationship is preserved — an array of Dog is assignable where an array of Animal is expected. Contravariance reverses it — a function accepting Animal is assignable where one accepting Dog is expected, because it can handle more. Function parameters are contravariant under strictFunctionTypes; return types are covariant. Getting this right is what makes higher-order function types safe.

Several places trade soundness for pragmatism: any disables checking; type assertions bypass it; method parameters are bivariant (not strictly contravariant) for ergonomics; array access doesn't account for out-of-bounds (returns the element type, not T | undefined, unless noUncheckedIndexedAccess); and structural typing lets unrelated same-shaped types interchange. These choices make TypeScript practical for real JavaScript at the cost of catching every error.

Branding fakes nominal typing in a structural system by intersecting a type with a unique marker so two otherwise-identical types (e.g. UserId and OrderId, both strings) aren't interchangeable. You construct them through a validating function and the brand prevents mixing them up. It's valuable for ids, validated/sanitized strings, and units, where structural equality would be a bug.

type UserId = string & { readonly __brand: "UserId" };

Declaration merging lets multiple declarations with the same name combine — two interfaces with the same name merge their members, which is why interfaces are 'open'. Module augmentation uses declare module to add to an existing module's or global's types — for example, extending Express's Request with a user property, or adding a property to the global Window. It's how you safely type third-party extension points.

Large unions, deep recursion, heavy conditional/mapped type computation, and big inferred types blow up checker work and editor responsiveness. Fixes: annotate return types on exported functions so the checker doesn't re-infer them everywhere, break giant types up, avoid unnecessary generic depth, use project references / incremental builds, and profile with extendedDiagnostics or --generateTrace. Simpler types are usually both faster and more maintainable.

When the type is harder to read than the code it guards, produces inscrutable errors, or slows the build, the cleverness is costing more than it saves. Library boundaries can justify advanced types because they protect many callers; application code usually shouldn't. The judgment call is whether the extra safety is worth the maintenance and error-message cost — often a simpler type plus a runtime check is better.