Describe a common use for Partial<T> and explain Required<T>

WHAT THIS TESTS: The interviewer wants to see if you can map real API patterns to TypeScript's type system. Specifically, they care whether you understand the difference between optionality and existence, and if you know when to relax or tighten constraints on an object type. This is foundational for designing safe update functions, form handlers, and configuration validators.

A GOOD ANSWER COVERS: First, define Partial as a mapped type that makes every property in T optional, which is exactly what you need for a PATCH request or a settings update where the caller sends only the fields that changed. Second, give a concrete code shape like a function updateTodo that takes a Todo and a Partial<Todo> and spreads the original object with the partial update. Third, explain Required as the inverse mapped type that strips optionality so every property becomes mandatory, useful when you have an object with optional fields but need to guarantee every key is populated before passing it downstream. Fourth, mention that these are built in since TypeScript 2.1 and 2.8 respectively and work via mapped type syntax under the hood.

COMMON WRONG ANSWERS: Saying Partial makes properties nullable or allows them to be set to null is incorrect; it only adds the question mark to each key and does not introduce null into the underlying type. Confusing Partial with Pick or Omit is another mistake, because those utilities select or remove specific keys rather than toggling optionality across the whole type. Describing Required as adding new properties instead of removing optionality from existing ones also signals a shallow understanding of mapped types.

LIKELY FOLLOW-UPS: The interviewer may ask how Partial differs from making every property optional by hand, which opens a discussion on maintainability and DRY types. They might ask you to implement Partial or Required manually using mapped types, for example type MyPartial<T> = { [P in keyof T]?: T[P] }. Another follow up is how these utilities interact with nested objects, since Partial only affects the top level and deeper objects may need recursive mapped types.

ONE CONCRETE EXAMPLE: Imagine a Todo app with an interface Todo that has title string, description string, and completed boolean. A PATCH endpoint receives only the fields the user edited, so you type the request body as Partial<Todo>. On the other hand, when your app loads a Todo from the database and normalizes it for the UI layer, you might use Required<Todo> to ensure that even fields that could be optional in a draft are guaranteed to exist in the rendered view.