How do you derive a PATCH payload type from UserProfile?

What's really being asked

This question evaluates whether you can use TypeScript's standard library to model HTTP PATCH semantics at the type level. The interviewer cares if you know that utility types like Partial are mapped types under the hood and whether you can connect language features to API contract design. It also checks if you understand the difference between partial updates and full resource replacement.

The full answer

First, state that the correct type is Partial of UserProfile. Second, explain that Partial constructs a mapped type which iterates over every key in UserProfile and makes each property optional while preserving the original value types. Third, mention that this matches RFC 5789 PATCH semantics where the client sends only the fields that need to change. Fourth, note that this approach avoids duplication and stays in sync if UserProfile later gains new fields. Fifth, optionally add that if certain fields should never be patched, such as an id or createdAt timestamp, you could combine Partial with Omit to exclude those keys before making the remainder optional.

The mistakes people make

A red flag is manually redeclaring every field as optional in a new interface because it duplicates the source of truth and breaks maintenance. Another red flag is suggesting Pick without explaining that Pick requires explicitly naming keys, which does not scale to arbitrary subsets. Some candidates propose Required or Readonly, which move in the wrong direction by making fields mandatory or immutable. Confusing PATCH with PUT is also a signal of weak API design intuition; PUT implies sending the entire resource, so Partial would be inappropriate there.

What usually comes next

The interviewer might ask how to prevent patching sensitive fields like id or emailVerified. They might also ask how to write a generic PatchPayload of T helper that works for any entity. Another follow-up is how to enforce that at least one field is present rather than allowing an empty object, which leads into discussions of Partial combined with Record and intersection types or custom mapped types with constraints.

A concrete example

Imagine UserProfile has id as string, name as string, age as number, and isAdmin as boolean. The derived type is Partial of UserProfile, so a valid payload can be an empty object, an object with only name, or an object with age and isAdmin together. If the business rule says id must never change, the safer type is Partial of Omit of UserProfile and id. This keeps the patch payload flexible for all other fields while locking the immutable key.