Lesson 2 of 80

Interfaces vs Type Aliases

Q: When would you reach for a type alias over an interface, and vice versa — is it purely a style preference?

A strong answer covers: interface supports declaration merging (re-declaring the same name adds members) and extends — useful when a shape might need augmenting later; type can express things interface cannot: unions, intersections, tuples, primitives, and mapped/conditional types; Not purely style — each has real capabilities the other lacks.

Both describe a shape, and for plain object types they're nearly interchangeable — but each can do something the other genuinely cannot.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

You declare `interface Window { myLibVersion: string }` and later, in a different file, declare `interface Window { featureFlags: Record<string, boolean> }`. What happens?

The two declarations merge — Window ends up with both propertiesTypeScript rejects it as a duplicate identifierThe second declaration silently overwrites the first

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Interfaces vs Type Aliases

What interviewers actually ask about this, and what a strong answer has to cover.

When would you reach for a type alias over an interface, and vice versa — is it purely a style preference?

A strong answer covers

interface supports declaration merging (re-declaring the same name adds members) and extends — useful when a shape might need augmenting later
type can express things interface cannot: unions, intersections, tuples, primitives, and mapped/conditional types
Not purely style — each has real capabilities the other lacks

Likely follow-ups

What's declaration merging, concretely — what happens if you declare the same interface name twice?
Could you express a union type like 'string | number' using interface? Why or why not?

Practice these with the AI interviewer →

The plain-language idea

interface and type both describe a shape, and from the structural typing lesson: TypeScript doesn't care which one you used to describe it — compatibility is about shape either way. For a plain object type, they're nearly interchangeable. The real differences show up at the edges.

interface Point   { x: number; y: number }
type PointAlias  = { x: number; y: number };

Both work identically here. The differences that actually matter:

interface supports declaration merging — declaring the same interface name twice adds to it, rather than conflicting.
type can express things interface cannot — unions, intersections, tuples, primitives, and mapped/conditional types.

See it in a real thing: extending a library's types

// some-library's own types.d.ts
interface Window {
  myLibVersion: string;
}

// your app's types.d.ts — this ADDS to Window, it doesn't conflict
interface Window {
  featureFlags: Record<string, boolean>;
}

// now Window has both properties, merged
window.myLibVersion;
window.featureFlags;

Declaring interface Window a second time doesn't error — it merges. This is exactly how you augment a third-party library's or the global Window's types without editing their source. Try the same thing with type Window = {...} twice, and TypeScript rejects it as a duplicate identifier — type can't be reopened once declared.

interface vs type: where they actually divergeStep 1 of 3

interface User { name: string } interface User { age: string } — two declarations MERGE into one.

What people usually miss

Watch out

"Which one compiles faster" isn't the real deciding factor. At normal codebase scale the difference is negligible — pick based on capability, not a performance myth.
A common rule of thumb: use interface for public object/API shapes that might need extending later (declaration merging is the whole reason to reach for it); use type for unions, tuples, primitives, and anything mapped/conditional.
implements works with both, and either way it only checks the shape — a class implements-ing an interface (or a type alias describing an object shape) doesn't create any special runtime coupling, consistent with structural typing from the last lesson.
Declaration merging is opt-in behavior, not an accident. It exists specifically so you (or a library) can add to an existing interface across multiple files — it's not TypeScript silently tolerating a duplicate.

Why this matters in interviews

"When would you use type over interface?" checks whether you know each one's actual capabilities, not just that they're "basically the same" — the honest answer is that they overlap heavily but aren't redundant, and the difference is what each can express, not a stylistic coin flip.