In TypeScript, what are `Required<{ a?: number }>` and `Required<{ b: number | undefined }>`, and why do the two results differ?

## The definition, and what it actually does ```typescript type Required<T> = { [P in keyof T]-?: T[P] }; ``` The `-?` says "remove the optional marker". What is easy to miss is that removing optionality also removes `undefined` from the resulting property type — but only for a property that *was* optional. That conditional behaviour is exactly what produces the two different answers. ## Case one: the property was optional ```typescript type A = { a?: number }; type RA = Required<A>; // { a: number } ``` Under `strictNullChecks`, `a?: number` means the property may be absent, and reading it gives `number | undefined`. `Required` removes the marker and, because it removed one, removes `undefined` too. The result is a property that must be present and holds a number. This is the case people expect, and it is why `Required<T>` is the natural output type of a "defaults have been applied" step. ## Case two: the property was already required ```typescript type B = { b: number | undefined }; type RB = Required<B>; // { b: number | undefined } ``` Here `b` is a required property. The object must have the key, and the value may be `number` or `undefined`. There is no optional marker to remove, so `-?` is a no-op and the declared type is copied through unchanged. `Required<B>` and `B` are the same type. ## The distinction being tested TypeScript models two separate things that everyday speech runs together: 1. **Presence** — must the key be on the object? Controlled by `?`. 2. **Value** — can the value be `undefined`? Controlled by the property's type. ```typescript type X = { a?: number; b: number | undefined }; const ok1: X = { b: undefined }; // a may be absent const ok2: X = { a: 1, b: undefined }; // b must be present, may be undefined const bad: X = { a: 1 }; // error: b is missing entirely ``` The `b: undefined` distinction matters in practice: `"b" in obj` is true for `ok2` and a `for...in` loop or `Object.keys` will list it, which is why a spread of such an object copies the key over a real value. So "required" and "never undefined" are genuinely different guarantees, and `Required<T>` only delivers the first one — plus the second as a side effect where it had an optional marker to remove. ## Getting the guarantee you actually wanted If you need "present and definitely not undefined" across a type whose properties were declared with an explicit `| undefined`, `Required<T>` is not the tool. You have to transform the property *types*, which means either fixing the declarations (drop the gratuitous `| undefined`) or writing a mapped type whose body strips undefined from each property type — `NonNullable` is the built-in that does the stripping for a single type. In most codebases the right answer is the first one. A property declared `b: number | undefined` rather than `b?: number` is usually a modelling slip; the two are close in meaning but not the same, and the explicit-union form is the one that forces every caller to write the key out. Under `exactOptionalPropertyTypes` the difference between the two declarations becomes sharper still, because an optional property then no longer silently accepts an explicit `undefined`. ## How this shows up in interviews Usually as a two-line snippet with "what is the resulting type?" — a check on whether you know that `Required<T>` is a modifier operation, not a value-level cleanup. A candidate who says "it makes everything non-optional and non-undefined" is half right and will be caught by the second case.