TypeScript Developer interview questions

A conditional type selects one type or another according to an assignability check written as T extends U ? X : Y.

• Distribution occurs when the checked side is a naked type parameter and that parameter receives a union.
• TypeScript evaluates each union member separately and unions the resulting branches.
• Wrapping both sides of the check in single-element tuples, such as [T] extends [U], suppresses distribution.

I would define a distributive filter such as type StringMembers<T> = T extends string ? T : never.

• Each member of a union is tested independently because T is a naked type parameter.
• Matching members survive unchanged while nonmatching members become never.
• Since never disappears from a union, StringMembers<string | number | 'ready'> resolves to string.

A conditional type can remain unresolved while its checked type parameter is still unknown.

• The compiler cannot safely choose either branch until the generic is instantiated with a concrete type.
• Code inside the generic implementation may therefore need an assertion even when callers receive a precise conditional return type.
• Overload signatures can sometimes express the public relationship more cleanly while keeping the implementation broad.

Nested conditional types form an ordered decision tree in which each false branch performs the next check.

• The order matters when conditions overlap because the first matching branch wins.
• Extracting named helper types keeps a long chain readable and exposes reusable concepts.
• If the cases represent runtime states, a discriminated union is often clearer than encoding every decision only at the type level.

In conditional types, never commonly represents a rejected case and acts as a filter for union members.

• A union containing never simplifies by removing it, so accepted members remain.
• A conditional applied directly to never may itself resolve to never because distributive evaluation has no members to process.
• Tuple wrapping is useful when never must be detected as a value of the type computation rather than distributed away.

I would disable distribution by comparing tuple-wrapped types, for example [T] extends [Allowed] ? Yes : No.

• The tuple makes the checked side something other than a naked type parameter.
• TypeScript then tests the complete union against Allowed in one assignability operation.
• This distinction matters for all-or-nothing validation such as requiring every event payload to satisfy a shared contract.

A recursive conditional type can exceed TypeScript's instantiation depth or make editor checks noticeably slower.

• Every recursive step creates more type instantiations, and unions can multiply that work through distribution.
• A depth parameter represented by a tuple counter can provide an explicit stopping condition.
• I keep recursive utilities narrow and measure compiler diagnostics before adopting them in widely imported libraries.

I would first require T to extend readonly unknown[] and then test whether number extends T['length'].

• General arrays have length typed as number, so the check succeeds for them.
• Tuples expose a finite union of numeric length literals, so number does not extend that length type.
• Supporting readonly arrays prevents the utility from rejecting tuples inferred through as const.

A mapped type creates properties by iterating over a union of PropertyKey values, commonly keyof another type.

• The iterator variable represents one key at a time and can index the source type to preserve each property's value type.
• Mapping over keyof T retains the relationship between each source key and T[K].
• Modifiers and key remapping let the transformation change optionality, mutability, or property names.

Mapped types use readonly and ? modifiers, with + to add them and - to remove them.

• The plus sign is implicit, so readonly [K in keyof T] and +readonly [K in keyof T] are equivalent.
• Writing -readonly or -? produces mutable or required versions of the mapped properties.
• These transformations affect compile-time assignability and do not freeze objects or fill missing values at runtime.

The as clause computes a new key for each source key while the mapped type still reads values from the original key.

• Template literal types can rename keys, such as converting name into getName.
• Producing never from the as clause removes that property from the result.
• Non-string keys often need a constraint such as K extends string before applying string transformations.

I would remap each key to itself when T[K] matches the target type and to never otherwise.

• A shape such as { [K in keyof T as T[K] extends V ? K : never]: T[K] } performs both filtering and reconstruction.
• Optional properties may include undefined, so the match policy must state whether to use T[K] or NonNullable<T[K]>.
• The test is based on assignability, which can include literal subtypes and unions depending on distribution.

Mapping over keyof T transforms an existing shape, while mapping over an arbitrary string union constructs a shape from an independent key set.

• With keyof T, T[K] is valid and preserves each original property's value type.
• With independent keys, the value type must come from another rule because those keys need not exist on T.
• Record<K, V> is the standard utility for the second pattern when every selected key shares one value type.

A homomorphic mapped type iterates over keyof T and lets TypeScript preserve structural details from the source properties.

• It naturally carries optional and readonly modifiers unless the mapping explicitly changes them.
• The value expression T[K] maintains the exact association between every key and its value type.
• Replacing the key set or remapping keys can stop some of that preservation because the result is no longer a direct copy transformation.

I would recursively map object properties to readonly while treating functions and primitive values as terminal cases.

• Arrays and tuples need deliberate handling so tuple positions are preserved instead of collapsing into a broad array type.
• Built-ins such as Date, Map, and Set require an explicit policy because recursively mapping their methods does not make their internal state immutable.
• The type only prevents mutations accepted by the compiler and does not perform runtime freezing.

Partial<T> is appropriate when every property of T is independently optional, such as a simple patch object.

• It does not express dependencies between fields or require at least one field to be present.
• Applying it to a domain entity can admit invalid intermediate objects that no runtime operation supports.
• For constrained updates I define a dedicated input type or combine Pick with a union of allowed update shapes.

Pick defines an allowlist of properties, while Omit starts with the full type and removes a denylist.

• Pick is safer for narrow public contracts because newly added source properties do not appear automatically.
• Omit is convenient when the result should track almost the entire source type, but source additions can silently widen the exposed shape.
• For security-sensitive DTOs I prefer an explicit Pick or a dedicated interface over excluding known secrets.

Record<K, V> requires a value of type V for every key in the finite key union K.

• Record<'idle' | 'ready', Handler> reports a missing handler for either named state.
• A string index signature describes values for arbitrary string keys and cannot normally require a particular finite set by itself.
• With noUncheckedIndexedAccess, reading an open dictionary can include undefined, while a complete finite Record has known keys.

Required<T> removes the optional modifier from every top-level property of T.

• It does not recursively require nested optional fields unless a separate deep utility is used.
• It does not validate runtime input or create values for fields that are missing.
• Under strict null checks, a required property may still allow undefined if undefined is explicitly part of its declared value type.

I would intersect the original type with Required<Pick<T, K>>, often simplifying the displayed result through a mapped identity type.

• Pick isolates the selected keys and Required removes their optional modifiers.
• The intersection preserves all unselected properties with their original value types and modifiers.
• A reusable helper should constrain K to keyof T so invalid property names fail at the call site.