The built-in type toolbox and implementing them from scratch.
By Mehedi Hasan Sarkar · Updated Jul 18, 2026 · intermediate
Intuition
Think of TypeScript utility types like a box of office tools for paper forms. If you already have a form, you can use a tool to make every field optional, remove a few fields, or copy only the fields you need.
That matters because real code rarely starts from scratch. Most of the time, you want to reuse an existing type and make a slightly different version of it without rewriting everything by hand.
Utility types are built-in TypeScript types that transform other types. They help you avoid duplication, keep types consistent, and express common changes like “all optional” or “only these keys.”
They matter most when APIs evolve or when the same data shape is used in multiple contexts. For example, a user object may be fully required when read from the database, but only partially filled in a form, or narrowed down to a subset for a response.
These four are about reshaping object types by changing which properties are present.
Partial<T> makes every property optional.Required<T> makes every property required.Pick<T, K> keeps only the keys in K.Omit<T, K> removes the keys in K.They are useful when one base type has many variations. Instead of creating separate interfaces by hand, you derive the variants from one source of truth.
type User = { id: string; name: string; email?: string };
type Draft = Partial<User>;
type Complete = Required<User>;
type PublicUser = Pick<User, 'id' | 'name'>;
type NoEmail = Omit<User, 'email'>;Record<K, V> builds an object type whose keys are K and whose values are V. It is the fastest way to say “for every allowed key, store this kind of value.”
This is especially useful for lookup tables, maps of flags, or configuration objects. It prevents accidental missing keys when the key set is known ahead of time.
type Status = 'idle' | 'loading' | 'success';
type StatusMessage = Record<Status, string>;
const messages: StatusMessage = {
idle: 'Ready',
loading: 'Please wait',
success: 'Done',
};These utilities extract type information from functions. Parameters<F> gives you the tuple of argument types, and ReturnType<F> gives you the return type.
They matter when one function should stay in sync with another. Instead of repeating a signature by hand, you derive the types directly from the implementation you already wrote.
function makeUser(name: string, age: number) {
return { name, age };
}
type Args = Parameters<typeof makeUser>; // [string, number]
type Result = ReturnType<typeof makeUser>; // { name: string; age: number }Awaited<T> extracts the resolved type from a promise-like value, and it also unwraps nested promises. It matches what await does at runtime.
This is important in async code where a function may return a promise of a promise-like value, or where you want to model the final value after awaiting. It keeps async type logic aligned with actual execution.
type A = Awaited<Promise<string>>; // string
type B = Awaited<Promise<Promise<number>>>; // number
type C = Awaited<string>; // stringYou can build many utilities with mapped types and conditional types. The key idea is to transform properties or infer parts of a type rather than writing the result manually.
A common interview pattern is to implement a simplified version of the built-ins. That proves you understand that Partial, Pick, and friends are just type-level transformations, not magic.
type MyPartial<T> = { [K in keyof T]?: T[K] };
type MyPick<T, K extends keyof T> = { [P in K]: T[P] };
type MyReturnType<F> = F extends (...args: any[]) => infer R ? R : never;
type User = { id: string; name: string };
type X = MyPartial<User>; // { id?: string; name?: string }
type Y = MyPick<User, 'id'>; // { id: string }
type Fn = (a: number) => boolean;
type Z = MyReturnType<Fn>; // booleanA slightly richer implementation shows how the pieces fit together. Omit can be built from Pick plus Exclude, and Required can be built by removing optional modifiers with -?.
Interviewers often like this because it tests whether you know the building blocks and can reason about type operators compositionally.
type MyRequired<T> = { [K in keyof T]-?: T[K] };
type MyOmit<T, K extends keyof any> = Pick<T, Exclude<keyof T, K>>;
type User = { id?: string; name?: string; email?: string };
type A = MyRequired<User>; // all required
type B = MyOmit<User, 'email'>; // id, nameA frequent mistake is confusing shape transformation with value transformation: utility types change the static type only, not the runtime object. Another trap is forgetting that Pick and Omit operate on keys, so the key constraint matters.
Watch for these interviewer favorites:
Partial<T> does not make nested objects partial unless you define a deep version.Required<T> only removes optional markers; it does not add missing runtime values.Record<K, V> requires every key in K to be present.ReturnType and Parameters need a function type, not an arbitrary object.Awaited unwraps promise-like types, but it does not execute async code.When implementing utilities from scratch, the exact syntax of mapped types and infer is usually what they test.