TypeScript Types vs Interfaces — Complete Interview Guide

The Core Distinction in One Sentence

Interfaces describe the shape of objects and classes and support declaration merging. Type aliases can describe any type — primitives, unions, tuples, mapped types, conditional types — and cannot be merged. For plain object shapes both work equally well; the differences matter at the edges.

Syntax Comparison

// Interface — keyword-based, feels like a contract
interface User {
  id: number;
  name: string;
  email?: string; // optional property
}

// Type alias — assignment-based, more like a named formula
type User = {
  id: number;
  name: string;
  email?: string;
};

// Both produce identical structural types — TypeScript treats them the same
// when checking compatibility between objects and these definitions.

What Only type Can Do

Type aliases can represent things interfaces simply cannot:

// Union types — impossible with interface
type Status = "active" | "inactive" | "pending";
type ID = string | number;

// Primitive aliases
type Milliseconds = number;
type UserName = string;

// Tuple types
type Coordinate = [number, number];
type NamedEntry = [string, ...number[]];

// Mapped types
type Readonly<T> = { readonly [K in keyof T]: T[K] };

// Conditional types
type NonNullable<T> = T extends null | undefined ? never : T;

// Function type shorthand
type Handler = (event: Event) => void;
// (interfaces can describe call signatures too, but the syntax is clunkier)

What Only interface Can Do — Declaration Merging

You can declare the same interface name multiple times and TypeScript merges all declarations into one shape. This is declaration merging and it is the feature that enables library augmentation:

// First declaration — in your library's types
interface Window {
  myAnalytics: Analytics;
}

// Second declaration — in a consumer's augmentation file
interface Window {
  myFeatureFlag: boolean;
}

// TypeScript merges them — Window now has BOTH properties
// This is how libraries like @types/jest add methods to global Jest types

// Same trick works for extending third-party types:
declare module "express-session" {
  interface SessionData {
    userId: string;
    cart: CartItem[];
  }
}

Declaration merging is the primary reason to choose interface over type when writing library code or global augmentations. A type alias with the same name twice is a compile error.

Extending and Composing

Interfaces use extends. Type aliases use intersection (&). Both create a wider shape, but they behave differently when properties conflict:

// Interface extends — compile error on conflict
interface Animal {
  name: string;
}
interface Dog extends Animal {
  name: number; // Error: property 'name' in 'Dog' incompatible with 'Animal'
}

// Type intersection — silently produces 'never' on conflict
type Animal = { name: string };
type Dog = Animal & { name: number };
// Dog['name'] is string & number = never — no compile error here!
// This is a subtle and dangerous difference

// Interfaces extending type aliases — fully supported
type HasId = { id: number };
interface Product extends HasId {
  title: string;
  price: number;
}

// Type aliases intersecting interfaces — also fully supported
interface Named { name: string; }
type Employee = Named & { employeeId: string };

Class Implementation

Classes can implement both interfaces and type aliases that describe object shapes — but not unions or primitives:

interface Serializable {
  serialize(): string;
}

type Loggable = {
  log(): void;
};

class UserService implements Serializable, Loggable {
  serialize() { return JSON.stringify(this); }
  log() { console.log(this.serialize()); }
}

// This does NOT work — cannot implement a union
type StringOrNumber = string | number;
class Broken implements StringOrNumber {} // Error

Performance in Large Codebases

The TypeScript compiler can cache and reuse interface types more efficiently than complex type aliases in large projects. For simple object shapes the difference is negligible, but extremely complex intersection and conditional types can slow down type-checking in large monorepos. This is a secondary concern — choose the right abstraction first.