Chapter 3: Conditional Types, Mapped Types & Utility Types

Introduction

Welcome to Chapter 3 of your TypeScript interview preparation guide! This chapter dives deep into the advanced type manipulation capabilities of TypeScript: Conditional Types, Mapped Types, and Utility Types. These powerful features are crucial for building robust, scalable, and highly maintainable applications, especially in large codebases or when designing flexible libraries.

Mastering these concepts demonstrates not just an understanding of TypeScript syntax, but also the ability to reason about complex type relationships, design flexible APIs, and leverage the type system to prevent common runtime errors. This chapter is designed for mid-level to architect-level candidates, focusing on practical application, real-world scenarios, and the nuanced understanding expected in senior technical roles. We’ll explore fundamental questions, intricate puzzles, and architectural considerations that go beyond basic type definitions.

Core Interview Questions

1. Understanding Conditional Types

Q: Explain what Conditional Types are in TypeScript (version 5.x) and provide a practical example using the infer keyword.

A: Conditional Types in TypeScript (introduced in TypeScript 2.8) allow you to express non-uniform type transformations based on a condition. They take the form T extends U ? X : Y, where if type T is assignable to type U, then the result type is X; otherwise, it’s Y. They are incredibly powerful for creating flexible and reusable type utilities.

The infer keyword, used within the extends clause of a conditional type, allows you to “infer” a type that is part of the type being checked and use it in the true branch of the conditional type. This is particularly useful for extracting parts of a type, such as the return type of a function or the element type of an array.

Practical Example with infer: Extracting the element type of an array.

type ElementType<T> = T extends (infer U)[] ? U : T;

// Examples:
type StringArrayElement = ElementType<string[]>; // Result: string
type NumberArrayElement = ElementType<number[]>; // Result: number
type NonArrayType = ElementType<boolean>;      // Result: boolean (T is not an array, so T is returned)
type AnyArrayElement = ElementType<any[]>;     // Result: any

In this example, ElementType<T> checks if T extends (infer U)[]. If it does, infer U captures the type of the array’s elements, and U becomes the resulting type. Otherwise, T itself is returned.

Key Points:

Syntax: T extends U ? X : Y.
Similar to ternary operators in JavaScript, but for types.
infer keyword allows extracting parts of a type within the condition.
Crucial for advanced type manipulation and creating generic type utilities.

Common Mistakes:

Forgetting that infer can only be used in the extends clause of a conditional type.
Misunderstanding the assignability rule (T extends U doesn’t mean T is U, but rather T can be assigned to U).
Overcomplicating simple type transformations with conditional types when a simpler utility type might suffice.

Follow-up:

How would you use conditional types to extract the parameters of a function type?
What are distributive conditional types, and when do they occur?

2. Exploring Mapped Types

Q: Describe Mapped Types in TypeScript (version 5.x). Provide an example demonstrating how to transform an object’s properties, including key remapping using the as clause.

A: Mapped Types in TypeScript (introduced in TypeScript 2.1) are a powerful way to create new object types based on existing ones. They iterate over the properties of a given type and apply a transformation to each property. This allows for creating variations of existing types, such as making all properties optional, readonly, or changing their types.

The basic syntax is [P in K], where P represents each property name from the union type K.

Key Remapping with as clause (TypeScript 3.8+): The as clause allows you to change the names of the properties during the mapping process. This is incredibly useful for creating types with transformed keys, such as prefixing/suffixing keys, changing case, or filtering properties based on their names.

Example: Let’s create a type that makes all properties of an object readonly and prefixes their keys with get.

type User = {
  id: string;
  name: string;
  age: number;
};

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

type UserGetters = Getters<User>;
/*
// UserGetters would resolve to:
type UserGetters = {
    readonly getId: () => string;
    readonly getName: () => string;
    readonly getAge: () => number;
}
*/

In this example:

[P in keyof T] iterates over each property P in T.
as get${Capitalize<string & P>}renames the key: it prefixesgetand capitalizes the original property name using theCapitalizeutility type and Template Literal Types (TypeScript 4.1+).string & Pis used to ensurePis treated as a string literal forCapitalize`.
readonly makes the new getter properties immutable.
(): T[P] transforms the property value into a function that returns the original property’s type.

Key Points:

Iterates over properties of an existing type.
Transforms property keys, values, or both.
as clause enables powerful key remapping, often combined with Template Literal Types.
Used to create types like Partial, Readonly, Pick, Omit, etc.

Common Mistakes:

Forgetting keyof T when iterating over an object type.
Incorrectly using as for key remapping, especially with complex string literal manipulations.
Not understanding the difference between [P in keyof T] and [P in K] where K is a string literal union.

Follow-up:

How would you create a mapped type that filters out properties of a specific type (e.g., all functions)?
Discuss the performance implications of overly complex mapped types in large projects.

3. Understanding Standard Utility Types

Q: TypeScript (version 5.x) provides several built-in Utility Types. Choose three commonly used ones and explain their purpose with code examples. Discuss when satisfies (TypeScript 4.9+) might be preferred over explicit type assertion for type checking.

A: TypeScript’s built-in Utility Types are a set of generic type aliases that facilitate common type transformations. They are essentially pre-defined Conditional and Mapped Types.

Partial<T>:

Purpose: Constructs a type with all properties of T set to optional. This is useful when you want to create an object that might have only a subset of properties from a complete type, often for update operations or default configurations.

Example:

interface UserProfile {
  id: string;
  name: string;
  email: string;
  avatarUrl?: string;
}

type PartialProfile = Partial<UserProfile>;
/*
// PartialProfile resolves to:
type PartialProfile = {
    id?: string;
    name?: string;
    email?: string;
    avatarUrl?: string;
}
*/
const userUpdate: PartialProfile = { name: "Jane Doe" }; // Valid

Pick<T, K>:

Purpose: Constructs a type by picking a set of properties K (a union of string literals) from type T. This is useful for creating a new type that contains only specific properties from an existing one.

Example:

interface Product {
  id: string;
  name: string;
  price: number;
  description: string;
}

type ProductSummary = Pick<Product, 'id' | 'name' | 'price'>;
/*
// ProductSummary resolves to:
type ProductSummary = {
    id: string;
    name: string;
    price: number;
}
*/
const summary: ProductSummary = { id: "p123", name: "Laptop", price: 1200 };

Exclude<UnionType, ExcludedMembers>:

Purpose: Constructs a type by excluding from UnionType all union members that are assignable to ExcludedMembers. This is particularly useful for refining union types.

Example:

type AllColors = 'red' | 'green' | 'blue' | 'yellow' | 'purple';
type PrimaryColors = Exclude<AllColors, 'yellow' | 'purple'>; // Result: 'red' | 'green' | 'blue'

type Mixed = string | number | boolean;
type OnlyStringsAndNumbers = Exclude<Mixed, boolean>; // Result: string | number

satisfies operator (TypeScript 4.9+): The satisfies operator provides a way to validate that an expression conforms to a type without changing its inferred type. This is often preferred over explicit type assertion (as Type) because type assertion forces the type, potentially hiding errors if the assertion is incorrect. satisfies checks for compatibility while preserving the original, more specific inferred type of the expression.

When satisfies is preferred over as Type: Consider a configuration object where you want to ensure it adheres to a specific interface, but also want to preserve the literal types of its properties for better inference downstream (e.g., for string literal unions or const assertions).

type ThemeColor = "primary" | "secondary" | "accent";
type ThemeConfig = { [K in ThemeColor]: string };

const myTheme = {
  primary: "#FF0000",
  secondary: "#00FF00",
  accent: "#0000FF",
  // typo: "#AAAAAA" // This would now error if 'typo' is not a ThemeColor
} satisfies ThemeConfig;

// Without 'satisfies', 'myTheme.primary' would just be 'string'.
// With 'satisfies', 'myTheme.primary' is inferred as the literal "#FF0000".
// This allows for more precise type checking in functions using myTheme.
function applyColor(color: typeof myTheme.primary) { /* ... */ }
applyColor("#FF0000"); // Valid
// applyColor("#000000"); // Error: Argument of type '"#000000"' is not assignable to parameter of type '"#FF0000"'.

If we used const myTheme: ThemeConfig = { ... }, myTheme.primary would simply be string, losing the literal information. If we used const myTheme = { ... } as ThemeConfig, it would also lose the literal information and could potentially hide errors if myTheme didn’t actually satisfy ThemeConfig (e.g., if a required property was missing). satisfies gives us the best of both worlds: type validation and precise inference.

Key Points:

Utility Types simplify common type manipulations.
Partial, Pick, Omit, Readonly, Required, Exclude, Extract, NonNullable, ReturnType, Parameters, Awaited are frequently used.
satisfies (TS 4.9+) validates type compatibility without widening the inferred type, preserving literal types and offering safer type checking than as Type.

Common Mistakes:

Using any or unknown when a specific utility type could provide a safer, more precise type.
Misunderstanding the difference between Exclude (for unions) and Omit (for object properties).
Forgetting that satisfies is a relatively new operator and might not be supported in older TypeScript versions (though 4.9+ is standard by 2026).

Follow-up:

When would you use Omit<T, K> versus Pick<T, K>?
Explain Awaited<T> and its relevance for asynchronous operations.

4. Advanced: Deep Partial and Recursive Mapped Types

Q: Design a DeepPartial<T> utility type that makes all properties of an object T and its nested objects optional. Explain the recursive logic involved in your solution.

A: A DeepPartial<T> type is a common requirement in scenarios like updating deeply nested configuration objects or state management. It makes every property at every level of an object structure optional.

The core idea is to apply the Partial utility type recursively. We need a conditional type to differentiate between primitive types (which should just be returned as is) and object types (which need to be recursively processed).

type DeepPartial<T> = T extends object
  ? {
      [P in keyof T]?: DeepPartial<T[P]>;
    }
  : T;

// Example Usage:
interface Address {
  street: string;
  city: string;
  zipCode: string;
}

interface UserConfig {
  id: string;
  name: string;
  settings: {
    theme: 'dark' | 'light';
    notifications: boolean;
  };
  address: Address;
}

type PartialUserConfig = DeepPartial<UserConfig>;
/*
// PartialUserConfig resolves to:
type PartialUserConfig = {
    id?: string;
    name?: string;
    settings?: {
        theme?: "dark" | "light";
        notifications?: boolean;
    };
    address?: {
        street?: string;
        city?: string;
        zipCode?: string;
    };
}
*/

const configUpdate: PartialUserConfig = {
  settings: {
    theme: 'dark',
  },
  address: {
      city: 'New York'
  }
}; // Valid

Recursive Logic Explanation:

T extends object: This is the conditional check.
- If T is an object type (including arrays, functions, etc., but primarily concerned with plain objects here), the true branch is taken.
- If T is a primitive type (string, number, boolean, null, undefined, symbol, bigint), the false branch (: T) is taken, and the type is returned as is, effectively stopping the recursion for that branch.
{ [P in keyof T]?: DeepPartial<T[P]> }: This is the true branch, a Mapped Type:
- [P in keyof T]: It iterates over all property keys P of the object type T.
- ?: It makes each property P optional.
- DeepPartial<T[P]>: This is the recursive step. For each property P, its value type T[P] is passed back into DeepPartial. This ensures that if T[P] is itself an object, its properties will also be made optional, and so on, down to the primitive types.

This pattern effectively traverses the entire object graph, making every property optional at every level.

Key Points:

Combines conditional types (to handle primitives vs. objects) with recursive mapped types.
Crucial for flexible update operations, configuration merging, and state management.
The extends object check is key to stopping the recursion for primitive types.

Common Mistakes:

Forgetting the base case (: T) for primitive types, leading to infinite recursion (though TypeScript often catches this with a depth limit).
Not correctly handling arrays (a simple extends object treats arrays as objects, which might be desired, but sometimes a specific T extends (infer U)[] ? DeepPartial<U>[] : ... is needed).
Overlooking potential issues with null or undefined properties if not explicitly handled (e.g., DeepPartial<T | null>).

Follow-up:

How would you modify DeepPartial to also make array elements DeepPartial?
Discuss how DeepRequired<T> would be implemented.

5. Type Puzzles: Distributive Conditional Types and `infer`

Q: Explain what a Distributive Conditional Type is. Then, given a union type A | B | C, design a type FilterString<T> that, when applied to T, filters out all string members from the union. Illustrate with an example.

A: Distributive Conditional Types: A conditional type T extends U ? X : Y is called a “distributive conditional type” when T is a bare type parameter and it is instantiated with a union type. In such cases, the conditional type distributes over the union. This means the conditional type is applied to each member of the union individually, and the results are then reunited into a new union type.

For example, if T is A | B | C, then T extends U ? X : Y becomes (A extends U ? X : Y) | (B extends U ? X : Y) | (C extends U ? X : Y).

FilterString<T> Implementation: To filter out all string members from a union type T, we can use a distributive conditional type. We’ll check if each member of the union T is assignable to string. If it is, we’ll return never (which effectively removes it from the union); otherwise, we’ll return the member itself.

type FilterString<T> = T extends string ? never : T;

// Example Usage:
type MixedUnion = string | number | boolean | null | undefined;

type FilteredUnion = FilterString<MixedUnion>;
/*
// FilteredUnion resolves to:
type FilteredUnion = number | boolean | null | undefined;
*/

type AnotherMixed = 'hello' | 123 | true | 'world';
type FilteredAnother = FilterString<AnotherMixed>;
/*
// FilteredAnother resolves to:
type FilteredAnother = 123 | true;
*/

Explanation: When FilterString<MixedUnion> is evaluated, because MixedUnion is a union (string | number | boolean | null | undefined) and T in FilterString<T> is a bare type parameter, the conditional type distributes:

string extends string ? never : string => never
number extends string ? never : number => number
boolean extends string ? never : boolean => boolean
null extends string ? never : null => null
undefined extends string ? never : undefined => undefined

Key Points:

Distributive conditional types apply to each member of a union individually.
This behavior is automatic when the checked type T is a bare type parameter.
never is used to effectively remove types from a union.
This mechanism is fundamental to many utility types like Exclude and Extract.

Common Mistakes:

Trying to prevent distribution when it’s desired, or vice-versa, without understanding the bare type parameter rule. Wrapping T in square brackets ([T] extends [U] ? X : Y) prevents distribution.
Confusing never with void or undefined; never signifies a type that can never occur.

Follow-up:

How would you create a ExtractString<T> type that only keeps string members from a union?
When might you want to prevent a conditional type from distributing?

6. Architectural: `tsconfig.json` and Type Decisions

Q: As a TypeScript architect, how do decisions in tsconfig.json (specifically strict, noImplicitAny, strictNullChecks, noUncheckedIndexedAccess (TS 4.1+), and exactOptionalPropertyTypes (TS 4.4+)) influence the design and complexity of advanced type patterns like conditional and mapped types in a large codebase?

A: tsconfig.json compiler options profoundly impact how TypeScript interprets and enforces types, directly affecting the design and complexity of advanced type patterns. For an architect, understanding these interactions is critical for maintaining code quality, reducing runtime errors, and managing developer experience.

strict: true (or individual strict flags): This umbrella flag enables many strict checks. When strict is enabled, the compiler enforces a much higher degree of type safety.
- Impact on Advanced Types: Forces more explicit handling of undefined and null, making types like NonNullable<T> or custom types that explicitly remove null | undefined more relevant. It also ensures that advanced types correctly capture all possible states, preventing implicit any that could mask type errors in complex transformations. It encourages writing more precise conditional and mapped types.
noImplicitAny: true: Prevents TypeScript from inferring any for variables and function parameters that lack an explicit type annotation.
- Impact: This is foundational. Without it, complex type inference in conditional/mapped types could silently fall back to any, undermining the entire purpose of advanced typing. It forces developers to explicitly define types, which in turn makes the inputs and outputs of type transformations more predictable and robust.
strictNullChecks: true: Ensures that null and undefined are not assignable to types that don’t explicitly include them.
- Impact: This is perhaps one of the most significant flags for advanced types. It necessitates careful consideration of null and undefined at every level of type design.
  - Conditional Types: You’ll frequently use NonNullable<T> or write custom conditional types to strip null | undefined from unions.
  - Mapped Types: When making properties optional (?), you must remember that T | undefined is the resulting type. If a property can truly be null, you need T | null | undefined. This impacts how DeepPartial or other recursive types are designed to handle potential null values.
  - Architects must guide teams to design types that explicitly model the presence or absence of values.
noUncheckedIndexedAccess: true (TypeScript 4.1+): When enabled, accessing an element at an arbitrary index on an array or object will result in an undefined union. E.g., arr[i] will be T | undefined instead of T.
- Impact: This dramatically increases type safety for array and object access.
  - Conditional/Mapped Types: When designing types that work with array elements or dynamically accessed object properties (e.g., Record<string, T>), you must account for the | undefined in your type logic. This might involve more NonNullable or explicit if (value !== undefined) checks in runtime code, and corresponding type guards.
  - Advanced types that extract values from arrays or objects will need to explicitly handle the undefined possibility if they are intended for strict contexts.
exactOptionalPropertyTypes: true (TypeScript 4.4+): Requires that optional properties are explicitly undefined if they are not present, rather than allowing undefined to be assigned to non-optional properties. Specifically, it means an optional property p?: string is string | undefined, but p: string does not accept undefined.
- Impact: This flag tightens the definition of optional properties.
  - Mapped Types: When creating mapped types that make properties optional, like Partial<T>, the resulting type will strictly adhere to PropertyType | undefined. This prevents subtle bugs where undefined might be accidentally assigned to a non-optional property if the source type didn’t explicitly allow it.
  - It encourages cleaner API design by making the distinction between “missing property” and “property with an undefined value” more explicit in types. Architects would leverage this to enforce stricter data contracts.

Overall Architectural Influence: These tsconfig options collectively push developers towards more explicit, precise, and safer type definitions. For advanced type patterns, this means:

Increased Complexity (Initially): Designing robust conditional and mapped types becomes more challenging as you must account for null, undefined, and any explicitly.
Higher Quality, Fewer Runtime Errors (Long-term): The initial complexity pays off by catching a vast array of potential runtime issues at compile time.
Better DX (Developer Experience): Clearer types lead to better editor auto-completion and more reliable refactoring.
Necessity of Advanced Patterns: These strict flags often necessitate the use of advanced conditional and mapped types to correctly model complex data structures and transformations without resorting to any.
Guidance and Standards: Architects must establish clear guidelines for type design, including common utility types and patterns, to ensure consistency and maintainability across the codebase under strict tsconfig settings.

Key Points:

tsconfig.json flags are critical for defining the baseline type safety.
Strict flags (strict, noImplicitAny, strictNullChecks) force explicit type handling.
noUncheckedIndexedAccess and exactOptionalPropertyTypes add further precision for array/object access and optional properties.
These flags make advanced type patterns more complex to design but lead to significantly more robust and reliable code.

Common Mistakes:

Ignoring tsconfig.json implications when designing types.
Disabling strict flags to “make types work” rather than fixing the underlying type issues.
Not understanding how undefined and null are treated differently under strictNullChecks.

Follow-up:

How do moduleResolution and paths in tsconfig.json impact the maintainability of declaration files (.d.ts) in a monorepo with advanced types?
Discuss the role of isolatedModules and its implications for type exports in a build system.

7. Real-world Scenario: API Response Transformation

Q: You are consuming a third-party API that returns user data. Some fields are optional, and others might be null. Design a type CleanUser<T> that takes the raw API response type T and transforms it so that all null values are explicitly removed (i.e., Property | null becomes Property | undefined or just Property if it’s already optional). Additionally, make all properties readonly. Assume you are running TypeScript 5.x.

A: This is a common real-world problem where raw API data needs to be “cleaned” into a more predictable and type-safe internal model. We’ll combine conditional types, mapped types, and NonNullable to achieve this.

First, let’s define a hypothetical raw API response type:

interface RawApiResponse {
  id: string;
  name: string;
  email: string | null;
  phone?: string | null; // Optional and can be null
  address: {
    street: string;
    city: string | null;
  } | null; // Can be null itself
  tags: string[] | null;
}

// Our goal is to transform it into something like:
/*
type CleanedApiResponse = {
    readonly id: string;
    readonly name: string;
    readonly email: string; // null removed
    readonly phone?: string; // null removed, still optional
    readonly address: {
        readonly street: string;
        readonly city: string;
    }; // null removed
    readonly tags: string[]; // null removed
}
*/

Now, let’s design CleanUser<T>:

type NonNull<T> = T extends null | undefined ? never : T; // Utility to remove null/undefined from a single type

type CleanUser<T> = {
  readonly [P in keyof T]: T[P] extends object // Check if property is an object (including arrays)
    ? T[P] extends (infer U)[] // If it's an array
      ? NonNull<CleanUser<U>>[] // Recurse on array elements, ensure array itself is non-null
      : NonNull<CleanUser<T[P]>> // If it's an object, recurse
    : NonNull<T[P]>; // If it's a primitive, just make it non-null
};

// Example Usage:
type CleanedUser = CleanUser<RawApiResponse>;
/*
// CleanedUser resolves to:
type CleanedUser = {
    readonly id: string;
    readonly name: string;
    readonly email: string;
    readonly phone?: string | undefined; // phone is still optional, and its type is string | undefined
    readonly address: {
        readonly street: string;
        readonly city: string;
    };
    readonly tags: string[];
}
*/

Explanation:

NonNull<T> Utility: This simple conditional type is crucial. It filters out null and undefined from a union type. If T is string | null, NonNull<string | null> becomes string.
CleanUser<T> Mapped Type:
- readonly [P in keyof T]: Iterates over each property P in T and makes the resulting property readonly.
- T[P] extends object: This is the first conditional check for the property’s value type. We need to distinguish between objects (which need recursive cleaning) and primitives.
- T[P] extends (infer U)[]: If the property is an object, we then check if it’s specifically an array.
  - If it’s an array: NonNull<CleanUser<U>>[]. We recursively apply CleanUser to the array’s element type U and then wrap it in NonNull to ensure the array itself isn’t null, and finally append [].
  - If it’s a non-array object: NonNull<CleanUser<T[P]>>. We recursively apply CleanUser to the object type T[P] and then wrap it in NonNull to ensure the object itself isn’t null.
- : NonNull<T[P]>: If the property is a primitive type, we simply apply NonNull<T[P]> to remove any null or undefined from its union.

This robust type ensures that after transformation, your internal data model will not contain null values, making subsequent logic simpler and safer. Note that optional properties (phone?: string | null) will correctly become phone?: string | undefined because NonNull effectively removes null but preserves the optionality.

Key Points:

Combines readonly mapped types with recursive conditional types.
Uses a helper NonNull type (or NonNullable<T>) to remove null and undefined.
Handles nested objects and arrays recursively.
A practical example of transforming raw data into a clean internal model.

Common Mistakes:

Forgetting to handle arrays explicitly, leading to CleanUser<string[]> potentially becoming CleanUser<string>[] instead of string[] (if CleanUser was just T extends object ? ... : T).
Not considering the optionality (?) of properties and how NonNull interacts with undefined.
Overlooking the null possibility for the object or array itself, not just its properties.

Follow-up:

How would you modify CleanUser to also convert specific string fields (e.g., email) to a EmailString branded type?
Discuss the runtime implications of this type transformation. What code would you write to actually clean the data at runtime?

8. Tricky Type Puzzles: `const` Type Parameters (TypeScript 5.0+)

Q: Explain the utility of const type parameters (introduced in TypeScript 5.0). Then, design a function createEventLogger that takes a literal object of event handlers, ensuring the keys are strictly preserved as literal types and the values are functions. Use const type parameters to achieve maximum type inference for the event names.

A: const Type Parameters (TypeScript 5.0+): The const modifier for type parameters (e.g., <const T>) allows TypeScript to infer the narrowest possible type for object, array, and primitive literals passed to a generic function. Without const type parameters, TypeScript would often widen literal types (e.g., "click" would become string, [1, 2] would become number[]). With const, these literals are inferred as their const assertion equivalent, preserving literal types and tuple types. This significantly improves type inference for configuration objects, event maps, and other scenarios where precise literal types are important.

createEventLogger Function Design:

We want createEventLogger to infer the exact literal string keys of the handlers object.

type EventHandler = (payload: any) => void; // A simple handler type

function createEventLogger<const T extends Record<string, EventHandler>>(handlers: T) {
  return {
    logEvent<E extends keyof T>(eventName: E, payload: Parameters<T[E]>[0]) {
      const handler = handlers[eventName];
      if (handler) {
        handler(payload);
      } else {
        console.warn(`No handler found for event: ${String(eventName)}`);
      }
    },
    getEventNames(): (keyof T)[] {
      return Object.keys(handlers) as (keyof T)[];
    }
  };
}

// Example Usage:
const logger = createEventLogger({
  userLoggedIn: (user: { id: string; name: string }) => {
    console.log(`User ${user.name} logged in.`);
  },
  itemAddedToCart: (item: { itemId: string; quantity: number }) => {
    console.log(`Item ${item.itemId} added.`);
  },
  appError: (error: Error) => {
    console.error(`App error: ${error.message}`);
  },
});

// Without <const T>, 'eventName' here would be 'string'.
// With <const T>, 'eventName' is inferred as 'userLoggedIn' | 'itemAddedToCart' | 'appError'.
logger.logEvent('userLoggedIn', { id: 'u1', name: 'Alice' }); // Correct type for payload
logger.logEvent('itemAddedToCart', { itemId: 'i2', quantity: 1 }); // Correct type for payload
logger.logEvent('appError', new Error('Something went wrong!')); // Correct type for payload

// logger.logEvent('unknownEvent', {}); // Type error: Argument of type '"unknownEvent"' is not assignable to parameter of type '"userLoggedIn" | "itemAddedToCart" | "appError"'.

const eventNames = logger.getEventNames(); // eventNames is inferred as ('userLoggedIn' | 'itemAddedToCart' | 'appError')[]
console.log(eventNames); // ['userLoggedIn', 'itemAddedToCart', 'appError']

Explanation:

<const T extends Record<string, EventHandler>>:
- const modifier: This is the key. When createEventLogger is called with a literal object (like userLoggedIn: ..., itemAddedToCart: ...), TypeScript will infer T as the literal type of that object, rather than widening its keys to string. For example, T will be inferred as { userLoggedIn: (user: { id: string; name: string }) => void; itemAddedToCart: (item: { itemId: string; quantity: number }) => void; appError: (error: Error) => void; }.
- extends Record<string, EventHandler>: This constraint ensures that the handlers object keys are strings and their values are EventHandler functions.
logEvent<E extends keyof T>(eventName: E, payload: Parameters<T[E]>[0]):
- E extends keyof T: Because T now has literal string keys due to const, keyof T correctly resolves to a union of those literal strings ('userLoggedIn' | 'itemAddedToCart' | 'appError'). This provides strong type checking for eventName.
- payload: Parameters<T[E]>[0]: This is where advanced utility types come in.
  - T[E] gets the type of the handler function for the given eventName.
  - Parameters<T[E]> extracts the parameter types of that function as a tuple.
  - [0] then accesses the first (and in our case, only) parameter’s type, ensuring the payload matches the expected type for that specific event handler.

Key Points:

const type parameters (TS 5.0+) enable precise literal type inference for generic function arguments.
Prevents widening of literal types (strings, numbers, booleans, arrays, objects).
Significantly improves type safety and developer experience for configuration objects and event maps.
Often used in conjunction with keyof, Parameters, and ReturnType for highly type-safe generic functions.

Common Mistakes:

Forgetting the const modifier and wondering why literal types are widened.
Not providing a suitable extends constraint for the const type parameter, which can lead to less useful inference or errors.
Over-relying on any for payload when Parameters<T[E]>[0] can provide precise types.

Follow-up:

How does const type parameter relate to as const assertion? When would you use one over the other?
Can const type parameters be used with array literals? Provide an example.

9. Conditional Mapped Types for Property Filtering

Q: Create a FunctionProperties<T> utility type that extracts only the properties from an object T whose values are functions. Similarly, create a NonFunctionProperties<T> type.

A: This is a classic example of combining conditional types within a mapped type to filter properties based on their value type.

type FunctionProperties<T> = {
  [P in keyof T as T[P] extends Function ? P : never]: T[P];
};

type NonFunctionProperties<T> = {
  [P in keyof T as T[P] extends Function ? never : P]: T[P];
};

// Example Usage:
interface Service {
  id: string;
  name: string;
  isEnabled: boolean;
  start(): void;
  stop(): Promise<void>;
  config: { timeout: number };
}

type ServiceFunctions = FunctionProperties<Service>;
/*
// ServiceFunctions resolves to:
type ServiceFunctions = {
    start: () => void;
    stop: () => Promise<void>;
}
*/

type ServiceData = NonFunctionProperties<Service>;
/*
// ServiceData resolves to:
type ServiceData = {
    id: string;
    name: string;
    isEnabled: boolean;
    config: {
        timeout: number;
    };
}
*/

Explanation:

Both types use a mapped type with key remapping (as clause) and a conditional type to filter properties:

[P in keyof T as T[P] extends Function ? P : never]:
- P in keyof T: Iterates over all property keys P in T.
- as T[P] extends Function ? P : never: This is the core filtering logic.
  - T[P] extends Function: Checks if the type of the property T[P] is assignable to Function.
  - If true (it’s a function), the key P is kept.
  - If false (it’s not a function), the key is remapped to never. When a key is remapped to never, that property is effectively removed from the resulting object type.
NonFunctionProperties<T> uses the inverse logic: T[P] extends Function ? never : P. If it’s a function, remove it (never); otherwise, keep it (P).

Key Points:

Conditional types within the as clause of a mapped type are powerful for filtering properties.
Remapping a key to never removes that property from the resulting type.
Function in TypeScript is a broad type for any function; for stricter checks, you might need more specific function signatures.

Common Mistakes:

Forgetting the as clause and trying to use the conditional type directly on the property value, which won’t remove the key.
Misunderstanding that never as a key type effectively removes the property.

Follow-up:

How would you create a PropertiesOfType<T, TypeFilter> that extracts properties whose values match a given TypeFilter?
Discuss the limitations of checking extends Function for complex function types (e.g., overloaded functions).

10. Architectural Trade-offs: When to Avoid Over-Engineering Types

Q: While advanced TypeScript types are powerful, they can also increase complexity. As an architect, discuss when and why you might choose to avoid overly complex conditional or mapped types, preferring simpler solutions or even runtime validation, especially in a large team context.

A: This is a crucial question for an architect, balancing the benefits of type safety against the costs of complexity and maintainability. While advanced types are invaluable, over-engineering them can introduce significant technical debt.

Reasons to Avoid Overly Complex Advanced Types:

Readability and Maintainability for the Team:
- Cognitive Load: Extremely complex conditional or recursive mapped types can be very difficult for developers (especially junior or mid-level) to read, understand, and debug. The “type-level programming” can become a separate language that few are fluent in.
- Onboarding: New team members will have a steep learning curve trying to grasp intricate type definitions, slowing down onboarding and productivity.
- Debugging Type Errors: When complex types produce unexpected errors, tracing the issue through multiple layers of conditional and mapped types can be a frustrating and time-consuming process.
Compiler Performance:
- Build Times: Highly recursive or deeply nested conditional/mapped types can significantly increase TypeScript compilation times. In large codebases, this can impact developer feedback loops and CI/CD pipelines.
- IDE Performance: The language server (used by VS Code and other IDEs) might struggle to compute complex type relationships, leading to slower auto-completion, hover information, and refactoring performance.
Limited Expressiveness for Runtime Logic:
- Type Erasure: TypeScript types are erased at runtime. If a complex type is designed to enforce a specific runtime invariant, that invariant still needs to be validated with actual JavaScript code. Relying solely on complex types without corresponding runtime checks can lead to false confidence.
- Runtime Validation Needed Anyway: For external data (e.g., API responses, user input), runtime validation (e.g., with Zod, Yup, Joi) is almost always necessary, regardless of the TypeScript types. Sometimes, it’s simpler to define a basic type and rely on robust runtime validation rather than trying to model every edge case purely at the type level.
Fragility and Brittleness:
- Refactoring Challenges: Changing underlying data structures can easily break complex type definitions in unexpected ways, leading to cascading type errors that are hard to resolve.
- Evolving Requirements: As requirements change, modifying an overly specific or intricate type can be harder than adjusting simpler types or runtime logic.

When to Prefer Simpler Solutions or Runtime Validation:

When the type complexity doesn’t add significant runtime safety: If the type is primarily for documentation or minor compile-time checks that don’t prevent critical runtime errors, a simpler type (or even any in very rare, isolated cases with strong runtime validation) might be more pragmatic.
For external data boundaries: Always pair type definitions with robust runtime validation for data coming from untrusted sources (APIs, user input). Libraries like Zod or Yup are excellent for this, and they can often derive TypeScript types from their schemas, simplifying type definition.
When a simple union or interface is sufficient: Don’t use a mapped type to make properties optional if Partial<T> works. Don’t write a custom conditional type if Exclude<T, U> is available.
When the team’s familiarity with advanced TypeScript is low: Prioritize maintainability and team velocity. Introduce advanced concepts gradually and provide thorough documentation and training.
For highly dynamic or polymorphic data structures: Sometimes, the dynamism of data makes it prohibitively complex to model perfectly with static types. In such cases, simpler types combined with careful runtime checks and documentation might be the more practical approach.

As an architect, the goal is to leverage TypeScript’s power effectively, not to prove its theoretical limits. This means making pragmatic trade-offs that balance type safety, performance, maintainability, and team productivity.

Key Points:

Complexity impacts readability, maintainability, onboarding, and debugging.
Advanced types can increase compile times and IDE performance overhead.
Type erasure means runtime validation is often still necessary.
Fragility and brittleness can make refactoring difficult.
Prioritize simpler solutions, runtime validation (especially for external data), and team familiarity.

Common Mistakes:

Treating type-level programming as a challenge to solve, rather than a tool to use pragmatically.
Ignoring the human factor: how complex types affect team members.
Believing that compile-time type safety completely negates the need for runtime validation.

Follow-up:

How would you introduce and enforce advanced TypeScript patterns in a large team without overwhelming them?
Describe a scenario where you would explicitly choose to use any and how you would mitigate the risks.

MCQ Section

Instructions:

Choose the best answer for each question.

1. What is the primary purpose of the infer keyword in TypeScript conditional types? A. To define a new type parameter that can be used anywhere in the global scope. B. To create a type alias for a complex type expression. C. To extract a type from within the type being checked in the extends clause. D. To explicitly cast a type to another type at compile time.

Correct Answer: C Explanation: The infer keyword allows TypeScript to deduce a type from a position within the type being evaluated in the extends condition and then make that inferred type available for use in the “true” branch of the conditional type.

2. Given type MyType = string | number | boolean;, what would Exclude<MyType, string | boolean> resolve to? A. string | boolean B. number C. string D. never

Correct Answer: B Explanation: Exclude<UnionType, ExcludedMembers> constructs a type by excluding from UnionType all union members that are assignable to ExcludedMembers. Here, string and boolean are excluded from string | number | boolean, leaving only number.

3. Which of the following tsconfig.json options, if enabled, would most directly require you to handle undefined when accessing array elements by index (e.g., myArray[0])? A. noImplicitAny B. strictNullChecks C. noUncheckedIndexedAccess D. exactOptionalPropertyTypes

Correct Answer: C Explanation: noUncheckedIndexedAccess (TS 4.1+) explicitly makes indexed access return T | undefined for arrays and objects, forcing you to handle the undefined possibility. While strictNullChecks is related to null and undefined generally, noUncheckedIndexedAccess specifically targets indexed access.

4. Consider the following type: type Example<T> = T extends { a: infer U, b: infer U } ? U : never;. What would Example<{ a: string, b: number }> resolve to? A. string B. number C. string | number D. never

Correct Answer: D Explanation: When infer U is used multiple times for the same type variable in a single conditional type, if the inferred types are different (here, string and number), TypeScript will infer the intersection of those types. string & number resolves to never because a value cannot be both a string and a number simultaneously. Since the condition then becomes T extends { a: never, b: never }, which is false, the never branch is taken.

5. You have an interface interface Config { port: number; host: string; }. Which built-in utility type would you use to create a new type where both port and host are optional? A. Required<Config> B. Readonly<Config> C. Partial<Config> D. Pick<Config, 'port'>

Correct Answer: C Explanation: Partial<T> constructs a type with all properties of T set to optional. Required makes them all required, Readonly makes them immutable, and Pick selects specific properties.

6. What is the primary benefit of using the satisfies operator (TypeScript 4.9+) over a type assertion (as Type)? A. It performs runtime validation of the object’s structure. B. It allows for type widening to a more general type. C. It validates type compatibility while preserving the most specific inferred literal types of the expression. D. It explicitly casts an expression to a new type, overriding inference.

Correct Answer: C Explanation: satisfies checks if an expression is compatible with a type without changing the expression’s inferred type. This means if the expression has more specific literal types (e.g., a string literal "hello"), satisfies ensures compatibility with a broader type (e.g., string) but keeps the literal type for better inference. Type assertion (as Type) forces the type, potentially losing specific literal information and hiding errors.

7. Which of the following best describes a “Distributive Conditional Type”? A. A conditional type that only works with primitive types. B. A conditional type where the type parameter in the extends clause is a union type and the condition is applied to each member of the union individually. C. A conditional type that always returns never for non-union types. D. A conditional type that can infer multiple types from a single expression.

Correct Answer: B Explanation: When a conditional type’s checked type T is a bare type parameter and T is instantiated with a union type, the conditional type distributes over the union, applying the condition to each member separately.

8. You want to create a type PrefixedKeys<T> that takes an object type T and prefixes all its keys with 'my_'. Which feature of Mapped Types would you primarily use? A. Conditional types within the value type. B. The as clause for key remapping. C. The readonly modifier. D. The ? modifier for optional properties.

Correct Answer: B Explanation: The as clause in a mapped type is specifically designed for key remapping, allowing you to transform property names, often in conjunction with Template Literal Types.

9. What is the main advantage of using const type parameters (TypeScript 5.0+) in a generic function? A. To make all properties of the function’s return type readonly. B. To enforce that function arguments are always constant values (e.g., const declarations). C. To prevent type widening for literal types (objects, arrays, primitives) passed as arguments, preserving their narrowest possible type. D. To define a constant value that can be used within the type system.

Correct Answer: C Explanation: const type parameters instruct TypeScript to infer literal types as narrowly as possible for the generic argument, preventing widening (e.g., "foo" to string, [1,2] to number[]), which is crucial for precise type inference in configurations and event maps.

10. If you have a type type MyUnion = { type: 'A', value: string } | { type: 'B', value: number };, and you want to extract only the member where type is 'A', which built-in utility type is most analogous to this filtering operation? A. Exclude<MyUnion, { type: 'B' }> B. Pick<MyUnion, 'type'> C. Extract<MyUnion, { type: 'A' }> D. Omit<MyUnion, 'value'>

Correct Answer: C Explanation: Extract<UnionType, ExtractedMembers> constructs a type by extracting from UnionType all union members that are assignable to ExtractedMembers. Here, Extract<MyUnion, { type: 'A' }> would correctly select the union member { type: 'A', value: string }.

Mock Interview Scenario: Designing a Type-Safe Configuration System

Scenario Setup: You are interviewing for a Senior TypeScript Architect position. The interviewer presents a common problem: a large-scale application needs a highly flexible and type-safe configuration system. The configuration objects can be deeply nested, and different parts of the application require different subsets of the configuration. The goal is to design a type system that ensures:

All configuration properties are readonly by default.
Configuration can be merged, allowing for DeepPartial updates.
Specific sub-configurations can be easily extracted and typed.
The system should be extensible without breaking existing type safety.
You are using TypeScript 5.x.

Interviewer: “Welcome! Let’s discuss configuration management. Imagine we have a core AppConfig type. How would you design its type definition to be robust and flexible for a large application, considering readonly properties, deep updates, and sub-config extraction?”

Expected Flow of Conversation:

1. Initial AppConfig Definition & Readonly:

You: “I’d start by defining our base AppConfig interface. To ensure immutability and prevent accidental modifications, all properties should be readonly. This can be achieved by applying the Readonly utility type or by explicitly marking properties as readonly.”

interface DatabaseConfig {
  readonly host: string;
  readonly port: number;
  readonly user: string;
}

interface FeatureFlags {
  readonly enableNewDashboard: boolean;
  readonly enableBetaFeatures: boolean;
}

interface AppConfig {
  readonly appName: string;
  readonly version: string;
  readonly database: DatabaseConfig;
  readonly features: FeatureFlags;
  readonly logging: {
    readonly level: 'info' | 'warn' | 'error';
    readonly filePath: string;
  };
  readonly optionalSetting?: string;
}

Interviewer: “Good. Now, how do we handle updates? We need to be able to apply partial updates, possibly deeply nested.”

2. Deep Partial Updates:

You: “For deep partial updates, we need a DeepPartial<T> utility type. This type recursively makes all properties optional, allowing us to merge partial configuration objects without needing to provide the entire structure.”

type DeepPartial<T> = T extends object
  ? { [P in keyof T]?: DeepPartial<T[P]>; }
  : T;

type UpdatableAppConfig = DeepPartial<AppConfig>;

const defaultAppConfig: AppConfig = { /* ... full config ... */ };
const updateConfig: UpdatableAppConfig = {
  database: { port: 5433 },
  logging: { level: 'error' },
};
// At runtime, we'd merge these with a deep merge utility.
// E.g., const finalConfig = deepMerge(defaultAppConfig, updateConfig);

Interviewer: “Excellent. Now, different modules might only care about specific parts of the configuration. How can we extract and strongly type these sub-configurations?”

3. Sub-Configuration Extraction:

You: “We can use Pick<T, K> for top-level properties. For nested properties, we might need a custom DeepPick<T, K> or a combination of Pick and manual type construction, depending on the complexity.”
- Option A (Simple Pick): “If a module only needs top-level properties like appName and version, Pick is perfect.”
```
type CoreAppInfo = Pick<AppConfig, 'appName' | 'version'>;
// Example: const coreInfo: CoreAppInfo = { appName: 'My App', version: '1.0.0' };
```
- Option B (Nested Pick - Custom Utility): “For deeply nested sections, we’d define a DeepPick or similar. A simpler approach if the path is known is to directly reference it, but a utility could be built.”
```
// For example, a module only needs DatabaseConfig:
type DbModuleConfig = AppConfig['database']; // This directly gets the nested type

// Or, if we wanted to extract 'host' and 'user' from database:
type DbCredentials = Pick<AppConfig['database'], 'host' | 'user'>;
```
- “For more generic deep extraction, a DeepPick<T, Path> utility could be crafted, but its complexity needs to be weighed against direct indexing for specific cases.”
Interviewer: “Consider a scenario where we have a configuration property plugins: Record<string, PluginConfig>. Each PluginConfig might have a type property, and based on that type, the PluginConfig object has different properties. How would you model this using advanced types?”

4. Discriminated Unions for Dynamic Configuration:

You: “This sounds like a perfect use case for Discriminated Unions. We can define a base PluginConfig and then union specific configurations based on a literal type property.”

interface BasePluginConfig {
  readonly id: string;
  readonly enabled: boolean;
}

interface LoggerPluginConfig extends BasePluginConfig {
  readonly type: 'logger';
  readonly level: 'debug' | 'info' | 'warn';
  readonly destination: 'console' | 'file';
}

interface CachePluginConfig extends BasePluginConfig {
  readonly type: 'cache';
  readonly ttl: number; // Time-to-live in seconds
  readonly maxSize: number; // Max items
}

type PluginConfig = LoggerPluginConfig | CachePluginConfig;

interface AppConfigWithPlugins extends AppConfig {
  readonly plugins: Record<string, PluginConfig>;
}

// Example usage with type narrowing:
function processPlugin(plugin: PluginConfig) {
  if (plugin.type === 'logger') {
    console.log(`Logger plugin level: ${plugin.level}`); // 'plugin' is LoggerPluginConfig here
  } else if (plugin.type === 'cache') {
    console.log(`Cache plugin max size: ${plugin.maxSize}`); // 'plugin' is CachePluginConfig here
  }
}

// When defining an actual config:
const myAppConfig: AppConfigWithPlugins = {
  // ... other config ...
  plugins: {
    myLogger: {
      id: 'logger1',
      enabled: true,
      type: 'logger',
      level: 'info',
      destination: 'console',
    },
    myCache: {
      id: 'cache1',
      enabled: false,
      type: 'cache',
      ttl: 3600,
      maxSize: 1000,
    },
  },
};

Interviewer: “That’s a very robust solution. Finally, what architectural considerations would you keep in mind regarding these advanced types, especially in a large codebase with multiple teams?”

5. Architectural Trade-offs & Best Practices:

You: “For a large codebase, the primary goal is balancing type safety with maintainability and developer experience.
1. Centralized Type Definitions: Keep core configuration types (AppConfig, DatabaseConfig, PluginConfig) in a well-known, centralized location (e.g., a types/config directory or a shared library in a monorepo).
2. Documentation: Document complex utility types like DeepPartial thoroughly, explaining their purpose, usage, and any caveats.
3. Linter Rules: Enforce consistent type styling and discourage any through ESLint rules.
4. Code Reviews: Conduct thorough code reviews, focusing not just on runtime logic but also on the clarity and correctness of type definitions.
5. Performance Monitoring: Be mindful of compiler performance. If build times become an issue, investigate complex type definitions as a potential cause.
6. tsconfig.json Strictness: Maintain a high level of strictness in tsconfig.json (strict: true, noImplicitAny, strictNullChecks, noUncheckedIndexedAccess) to maximize type safety. This forces developers to confront type issues early.
7. Runtime Validation: For configuration loaded from external sources (e.g., environment variables, config files), always complement compile-time types with runtime validation (e.g., Zod, Joi). This is critical because types are erased at runtime.
8. Avoid Over-Engineering: While powerful, don’t create overly abstract or complex type utilities if a simpler, more direct type definition suffices. The goal is clarity and correctness, not type-level acrobatics.
9. Gradual Adoption: If introducing new advanced patterns, do so gradually with clear examples and training for the team.”

Red Flags to Avoid:

Suggesting any for configuration properties.
Not considering readonly for configuration.
Failing to address the deep nature of partial updates or extraction.
Ignoring the runtime aspect of configuration (loading, merging, validating).
Proposing overly complex type solutions for simple problems, or solutions that would negatively impact compiler performance or team readability.
Not mentioning tsconfig.json implications for strictness.

Practical Tips

Practice with Real-World Scenarios: Don’t just memorize definitions. Try to apply these types to actual problems you’ve faced or seen (e.g., transforming API responses, defining complex state, creating flexible utility functions).
Read the TypeScript Handbook: The official documentation on Conditional Types, Mapped Types, and Utility Types is excellent and always up-to-date. (As of 2026-01-14, this would refer to TS 5.x documentation).
Experiment in a Playground: Use the TypeScript Playground to instantly see how your type definitions resolve. This is invaluable for debugging complex type errors.
Study Built-in Utility Types: Understand how Partial, Required, Pick, Omit, Exclude, Extract, NonNullable, ReturnType, Parameters, Awaited, etc., are implemented (they often use Conditional and Mapped Types themselves). This provides templates for your own custom utilities.
Learn Type Narrowing: These advanced types often work hand-in-hand with runtime type narrowing (e.g., if (typeof x === 'string'), if ('prop' in obj)). Understand how TypeScript’s control flow analysis interacts with your custom types.
Understand never: Grasping never as the empty union type is critical for filtering members in conditional and mapped types.
Explore Libraries: Look at how popular libraries (e.g., React Query, Zustand, Zod) leverage advanced TypeScript types to provide their powerful and type-safe APIs.
Stay Updated: TypeScript evolves rapidly. Keep an eye on new features (like satisfies and const type parameters) in recent releases (TS 4.9+, 5.0+, etc.) as they are often topics in advanced interviews.

Summary

This chapter has equipped you with a deep understanding of TypeScript’s advanced type manipulation capabilities: Conditional Types, Mapped Types, and Utility Types. We’ve explored their fundamentals, practical applications with the infer keyword and as clause, and delved into complex scenarios like DeepPartial, discriminated unions, and the impact of tsconfig.json on type design. We also tackled a tricky puzzle involving const type parameters and discussed crucial architectural trade-offs.

Mastering these concepts is a hallmark of a proficient TypeScript developer, particularly at mid-to-architect levels. It demonstrates the ability to write not just functional code, but code that is robust, maintainable, and leverages the full power of TypeScript’s static analysis to prevent errors and enhance developer experience. Continue practicing, experimenting, and applying these patterns to real-world problems to solidify your expertise.

References:

TypeScript Handbook - Conditional Types
TypeScript Handbook - Mapped Types
TypeScript Handbook - Utility Types
TypeScript 4.9 Release Notes (satisfies operator)
TypeScript 5.0 Release Notes (const type parameters)
Effective TypeScript by Dan Vanderkam (A highly recommended book for advanced TypeScript practices)
Type-Level TypeScript by Gabriel Vergnaud (Resource for advanced type-level programming patterns)

This interview preparation guide is AI-assisted and reviewed. It references official documentation and recognized interview preparation resources.

Chapter 3: Conditional Types, Mapped Types & Utility Types

Table of Contents

Introduction

Core Interview Questions

1. Understanding Conditional Types

2. Exploring Mapped Types

3. Understanding Standard Utility Types

4. Advanced: Deep Partial and Recursive Mapped Types

5. Type Puzzles: Distributive Conditional Types and infer

6. Architectural: tsconfig.json and Type Decisions

7. Real-world Scenario: API Response Transformation

8. Tricky Type Puzzles: const Type Parameters (TypeScript 5.0+)

9. Conditional Mapped Types for Property Filtering

10. Architectural Trade-offs: When to Avoid Over-Engineering Types

MCQ Section

Instructions:

Mock Interview Scenario: Designing a Type-Safe Configuration System

Practical Tips

Summary

References:

5. Type Puzzles: Distributive Conditional Types and `infer`

6. Architectural: `tsconfig.json` and Type Decisions

8. Tricky Type Puzzles: `const` Type Parameters (TypeScript 5.0+)