FrontendHaltUtility types and type vs. interface
Transform existing types with built-in utilities and choose between type and interface deliberately.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain utility types and type vs. interface in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Explain it simply
TypeScript ships built-in generic utilities — Partial, Required, Pick, Omit, Record, Readonly, and others — that transform an existing type instead of redefining it by hand. type and interface both describe object shapes, but they differ in extension mechanics and what they can express.
One-line definition: Transform existing types with built-in utilities and choose between type and interface deliberately.
02Mental model
Derive types from a single source of truth instead of duplicating field lists: Pick<User, 'id' | 'name'> and Omit<User, 'password'> stay in sync automatically when User changes, whereas a hand-written duplicate type silently drifts. Prefer interface for public object shapes meant to be extended or declaration-merged; prefer type for unions, tuples, and mapped or conditional type expressions interface syntax can't represent.
03Step by step
- Identify the source-of-truth type and derive variants from it rather than duplicating fields.
- Use Partial for optional-update payloads, and Pick or Omit for narrowed views.
- Use Record for uniform key-value maps.
- Reach for interface when you need declaration merging or a clearly extensible public contract.
- Reach for type when modeling a union, tuple, or a mapped or conditional expression.
04Working example
interface User { id: string; name: string; email: string; password: string; }
type PublicUser = Omit<User, 'password'>;type UserUpdate = Partial<Pick<User, 'name' | 'email'>>;type UsersById = Record<string, User>;
function updateUser(id: string, patch: UserUpdate) { /* ... */ }PublicUser automatically drops password and stays correct if User gains new fields. UserUpdate only allows name and email, both optional, so a caller can't accidentally try to patch id. Record<string, User> expresses a uniform lookup map without writing an index signature by hand.
05Where it is used
- API response types that exclude internal-only fields
- PATCH endpoint payload types derived from the full entity
- Lookup maps or dictionaries keyed by id
- Extending a third-party library's declared interface through declaration merging
06Common mistakes
- Manually retyping a narrowed shape instead of deriving it with Pick or Omit, causing drift
- Using interface for a union type, which isn't expressible and requires type
- Assuming type and interface are interchangeable in every case, including declaration merging
- Overusing Partial on a type where some fields should always remain required
07Interview answer
Show you derive types instead of duplicating them — naming the specific utility such as Pick, Omit, Partial, or Record for a scenario is a stronger signal than a generic 'TypeScript has utility types' answer.
Why does Omit<User, 'password'> stay correct automatically if a new optional field is added to User, while a hand-written PublicUser type wouldn't?
Omit computes its result from User's current shape every time the compiler checks it, so any new field on User is included automatically; a hand-written duplicate type is a separate static declaration that has to be manually updated, and forgetting to do so lets it silently drift out of sync.
DDConcept deep dives
Deep dive 1
Derive types instead of duplicating them
Pick, Omit, Partial, Required, and Record all compute a new type from an existing one at the type level, so the derived type automatically reflects later changes to its source. A hand-written type that happens to look the same at one point in time has no such connection, and silently drifts the moment the source type changes and nobody remembers to update every duplicate.
- Treat one type as the source of truth and derive request/response/update variants from it.
- A compile error on a derived type after a source change is the system working correctly.
- Duplication that looks identical today is a maintenance liability tomorrow.
Deep dive 2
type and interface differ in what they can express and extend
interface declarations can be reopened via declaration merging — useful for augmenting a third-party library's types — and read clearly as an extensible object contract. type aliases can express unions, tuples, primitives, and the results of mapped or conditional type expressions that interface syntax has no equivalent for. Neither is strictly 'better'; each fits a different kind of type.
- Use interface for public, extensible object contracts and declaration merging.
- Use type for unions, tuples, and mapped/conditional type results.
- Two interfaces with the same name merge; two type aliases with the same name conflict.
Deep dive 3
Utility types compose
Pick, Omit, Partial, and Record can be nested to express precise derived shapes — for example, making only a subset of an existing type's fields optional, or building a lookup map whose values are themselves a narrowed view of another type. This composability is what makes deriving from one source type expressive enough to replace most hand-written duplicate types.
- Partial<Pick<T, K>> makes only a specific subset of fields optional.
- Extract intermediate named types when a composed expression gets hard to read.
- Composition should still resolve to a type you can reason about at the call site.
type EditableFields = 'name' | 'email';type ProfileUpdate = Partial<Pick<Profile, EditableFields>>;Naming EditableFields separately documents intent and can be reused anywhere else the same subset of fields needs to be referenced.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Intermediate · Coding · 1 min · Question 1What is the practical benefit of Pick and Omit over hand-written types?Open model answer
Model answer
They derive a new type directly from an existing one, so when the source type gains, removes, or renames a field, the derived type updates automatically at compile time instead of silently drifting out of sync with a manually duplicated definition.
interface User { id: string; name: string; email: string; passwordHash: string }
type PublicUser = Omit<User, 'passwordHash'>;type Credentials = Pick<User, 'email' | 'passwordHash'>;Intermediate · Coding · 1 min · Question 2When should interface be chosen over type?Open model answer
Model answer
Choose interface for object shapes meant to be part of a public, extensible contract, especially when declaration merging is useful, such as extending a third-party library's types. Choose type when the shape is a union, tuple, or the result of a mapped or conditional expression.
interface ButtonProps { variant: 'solid' | 'ghost' } // object contracttype Status = 'idle' | 'loading' | 'done'; // union — needs `type`type Pair = [number, number]; // tuple — needs `type`Intermediate · Coding · 1 min · Question 3What does Readonly<T> protect against, and what doesn't it protect against?Open model answer
Model answer
It marks all of T's properties as readonly at the type level, so the compiler flags reassignment attempts. It provides no runtime immutability — a caller who bypasses the type system or receives the object through untyped code can still mutate it.
const cfg: Readonly<{ url: string }> = { url: '/api' };cfg.url = '/other'; // compile error(cfg as any).url = '/other'; // no runtime protectionIntermediate · Coding · 1 min · Question 4How does Record<K, V> differ from an indexed signature written by hand?Open model answer
Model answer
Record<K, V> is a builtin generic utility that produces the same mapped-object shape as a hand-written { [key: K]: V } index signature, but is more concise and communicates intent clearly, especially when K is a union of string literals rather than plain string.
type Roles = 'admin' | 'editor' | 'viewer';type Permissions = Record<Roles, string[]>;// { admin: string[]; editor: string[]; viewer: string[] } — all keys requiredAdvanced · Coding · 1 min · Question 5Can two interfaces with the same name in the same scope coexist?Open model answer
Model answer
Yes — this is declaration merging. TypeScript combines their members into a single interface. Two type aliases with the same name in the same scope, by contrast, produce a compile error because type aliases can't be merged.
interface Window { myGlobal: string; } // merges with the built-in Window// type Window = { ... } // Error: Duplicate identifierIntermediate · Conceptual · 1 min · Question 6What happens if you use Partial on a type where every field should always be required for a create operation?Open model answer
Model answer
It would incorrectly allow every field to be omitted, weakening validation for the create case. A separate type — either the full type unmodified, or one derived with only the specific optional fields picked out — better matches that requirement.
Open question page →Beginner · Conceptual · 1 min · Question 7What does NonNullable<T> do?Open model answer
Model answer
It removes null and undefined from a type, which is useful when narrowing a value that's known through other logic to always be present, without repeating a manual conditional type.
Open question page →Advanced · Conceptual · 1 min · Question 8How does ReturnType<typeof fn> help avoid duplicated type definitions?Open model answer
Model answer
It extracts a function's return type directly from its implementation, so if the function's return shape changes, dependent types update automatically instead of needing a parallel manual type declaration.
Open question page →Advanced · Conceptual · 1 min · Question 9Can an interface extend a type alias?Open model answer
Model answer
Yes, as long as the type alias resolves to an object type; interface extends works with both other interfaces and compatible type aliases, though it cannot extend a union type.
Open question page →Intermediate · Conceptual · 1 min · Question 10What's a risk of chaining many utility types together, like Partial<Omit<Pick<T, ...>, ...>>?Open model answer
Model answer
Deeply nested utility-type expressions can produce error messages and hover tooltips that are hard to read, so extracting intermediate named types often improves maintainability even though the runtime behavior is identical.
Open question page →SCScenario questions
Scenario 1
A codebase has three manually written types — CreateUserInput, UpdateUserInput, and PublicUser — that have each drifted out of sync with the main User interface after recent field changes.
- Identify User as the single source of truth.
- Derive UpdateUserInput with Partial and Pick for only the editable fields.
- Derive PublicUser with Omit to exclude sensitive fields.
- Keep CreateUserInput close to User but explicit about which fields are server-generated.
Reveal worked answer
I would make User the canonical shape and derive the others from it: PublicUser as Omit<User, 'passwordHash'>, UpdateUserInput as Partial<Pick<User, 'name' | 'email'>> for only the fields a user can edit, and CreateUserInput as Omit<User, 'id' | 'createdAt'> since those are server-assigned. Any future field change to User then propagates through all three automatically instead of requiring three manual edits.