Implement the built-in NonNullable<T> utility type from scratch

WHAT THIS TESTS: This tests your grasp of TypeScript's type-level programming, specifically distributive conditional types and how they interact with union types. The interviewer wants to see if you know that conditional types distribute over naked type parameters, which is the standard mechanism for filtering unions. It also checks whether you distinguish between compile-time type transformations and runtime value operations.

A GOOD ANSWER COVERS: First, write the one-line implementation: type MyNonNullable<T> = T extends null | undefined ? never : T. Second, explain that because T is a naked type parameter in the extends clause, the conditional type distributes over each member of a union. Third, note that null and undefined each extend null | undefined, so they resolve to never, while other types resolve to themselves. Fourth, mention that never disappears from unions automatically, leaving only the non-nullish types. Fifth, optionally contrast this with a non-distributive version using square brackets like [T] extends [null | undefined] to show you understand how to disable distribution when needed.

COMMON WRONG ANSWERS: A mapped type like type X = { [K in T]: K } is incorrect because mapped types iterate over keys, not union members directly, and do not filter nullability. Using value-level JavaScript checks like typeof or instanceof is a red flag because the question asks for a type utility, not a runtime function. Proposing Object.assign or spread operators shows confusion between values and types. Some candidates write T extends null ? never : T extends undefined ? never : T which works but reveals less understanding of union types in the extends clause. Forgetting that naked type parameters distribute and being unable to explain why the type works is also a weakness.

LIKELY FOLLOW-UPS: The interviewer might ask how to implement Exclude or Extract using the same pattern. They may ask what happens if you wrap T in a tuple like [T] extends [null | undefined], which prevents distribution and makes the utility behave differently on unions. They might ask how this differs from the definite assignment assertion operator or from strictNullChecks. Another follow-up is implementing a deep NonNullable that recursively removes null and undefined from nested properties.

ONE CONCRETE EXAMPLE: Given type User = { name: string } | null | undefined, applying MyNonNullable<User> produces { name: string }. If you had type Status = "active" | "inactive" | null, the result is "active" | "inactive". The never type absorbs away in the resulting union, which is why you do not need explicit subtraction syntax.