Interfaces & Types
TypeScript describes data by its shape — a set of property and method names and types — rather than by a class hierarchy the way nominal languages do. Two tools describe an object's shape: interface and the type alias. Both are checked at compile time and fully erased at runtime — the emitted JavaScript has no interfaces and no aliases, only values.
The idea beginners often miss: type compatibility in TypeScript is structural. An object fits a type if it has the required members — even if it never declares that interface by name. That is where duck typing comes from, along with the special excess-property check on fresh literals, and the fact that interface and type are largely interchangeable for object shapes yet diverge on declaration merging, unions, and computed types. The full map lives in the layers below.
Topic map
- Interfaces — the shape contract for an object: properties, methods,
?,readonly,implements,extends; why an interface costs nothing at runtime. - Type Aliases —
typeas a name for any type; howinterfacediffers fromtype— merging, unions, ways to extend, and their trade-offs. - Structural Typing — compatibility by shape, duck typing, and the ⚠️ excess-property check on object literals.
- Index Signatures —
[key: string]: Tfor an open-ended key set and how that differs fromRecord<K, V>.
Common traps
| Mistake | Consequence | |
|---|---|---|
Thinking an interface exists at runtime | An interface is fully erased at compile time; you cannot read it via typeof while running | |
Confusing an interface with a class | An interface has no method bodies or constructor; you cannot new it | |
Treating interface and type as perfect synonyms | Only type expresses unions, tuples, and computed types; only interface supports declaration merging | |
| Expecting the excess-property check on any assignment | The excess-property check fires only on fresh object literals, not on variables | |
| Using an index signature where a fixed key set is needed | { [k: string]: V } is open to any key; `Record<'a' \ | 'b', V>` requires exactly those keys |
| Assuming a repeated interface name is a duplicate-identifier error | Same-named interfaces merge; a duplicate type of the same name is an error |
Interview relevance
Interfaces and types come up on almost every TypeScript interview — but the check is your model of the type system, not the syntax. A candidate who explains that types are erased and compatibility is structural stands out from "it's like Java, just a contract".
Typical checks:
- What an
interfacedescribes and why it costs nothing at runtime. - When to reach for
interfaceversustype, and what only one of them can do. - What structural typing is and why a fresh literal with an extra field errors while a variable does not.
- How
Record<K, V>differs from an index signature and when each fits. - What declaration merging is and why it is useful (e.g. augmenting
Window).
Common wrong answer: "interface and type are the same thing." That opens the discussion that for object shapes they are nearly interchangeable, but type does unions and computed types while interface does declaration merging — and the choice affects the extensibility of a public API.