Interfaces & Type Aliases

Both interface and type give a name to a type so you can reuse it. They overlap a lot — for a plain object shape they are interchangeable — which is exactly why interviewers like asking about the differences.

An interface declares a named object type: properties, methods, call signatures, index signatures. That's all it can describe. A type alias is a new name for any type expression — an object shape, but also a primitive, a union, a tuple, a function type, or the result of a mapped or conditional type. The alias doesn't create anything new; it's a label stuck on whatever is to the right of the =.

A useful mental model: an interface is a named contract that stays open (you can add to it later, see Declaration merging); a type alias is a closed label for a type expression. And because TypeScript is structural, neither one creates a "brand" — two types with the same members are compatible no matter what they're called or how they were declared.

interface PersonI {
  name: string;
  age?: number;
}

type PersonT = {
  name: string;
  age?: number;
};

type ID = string | number;

const a: PersonI = { name: "Ana" };
const b: PersonT = a; // fine: same members, different declaration kind
const id: ID = 42;

type PersonT = { name: string; age?: number };

type ID = string | number; // union
type Point = [x: number, y: number]; // tuple
type Callback = (err: Error | null) => void; // function type
type Status = "idle" | "loading" | "done"; // union of literal types
type Nullable<T> = T | null; // generic alias of anything
type PersonKeys = keyof PersonT; // computed from another type: "name" | "age"
type ReadonlyPerson = { readonly [K in keyof PersonT]: PersonT[K] }; // mapped type

Both forms let you build a bigger type out of smaller ones, so you don't repeat properties. Interfaces do it with extends: "a Dog is everything an Animal is, plus these members." Type aliases do it with an intersection A & B: "a value that is an A and also a B", which for object types means it has the members of both.

The mental model for an intersection is a value that has to pass both checks at once. To be an A & B, an object must satisfy A's requirements and B's requirements, so it ends up needing all of their properties. (For unions vs intersections in general, and why string & number is never, see Unions vs intersections.)

interface Animal {
  name: string;
}

interface Dog extends Animal {
  breed: string;
}

const rex: Dog = { name: "Rex", breed: "Labrador" };
const stray: Dog = { name: "Rex" }; // ❌ TS2741: Property 'breed' is missing in type '{ name: string; }' but required in type 'Dog'.

type Animal = { name: string };
type Dog = Animal & { breed: string };

const rex: Dog = { name: "Rex", breed: "Labrador" };

type A = { name: string };
type B = { age: number };
type C = A & B;

const person: C = { name: "John", age: 30 };
const partial: C = { name: "John" }; // ❌ TS2322: Type '{ name: string; }' is not assignable to type 'C'.

interface HasId {
  id: string | number;
}

interface Timestamped {
  createdAt: Date;
}

interface Order extends HasId, Timestamped {
  id: string; // narrowed from string | number — allowed
  total: number;
}

const order: Order = { id: "ord_1", createdAt: new Date(), total: 99 };
const legacy: Order = { id: 7, createdAt: new Date(), total: 5 }; // ❌ TS2322: Type 'number' is not assignable to type 'string'.

Interfaces are open. If you declare an interface with the same name twice in the same scope, TypeScript doesn't complain — it merges the two declarations into one interface with the members of both. Type aliases are closed: declaring the same alias name twice is an error.

Why would a language want this? Because JavaScript objects get extended after the fact, and the types have to follow. The built-in lib files rely on it: Array<T> is declared in lib.es5.d.ts, and later lib files (lib.es2016.array.include.d.ts, lib.es2022.array.d.ts…) re-open interface Array<T> to add includes, at and so on, depending on your target and lib settings. The same mechanism lets you add a property to Window or to a library's types (see Global declarations and extending window and Module augmentation).

This is the example from my notes:

interface Person {
  name: string;
}

interface Person {
  age: number;
}

const person: Person = { name: "John", age: 30 }; // works due to merging
const nameOnly: Person = { name: "John" }; // ❌ TS2741: Property 'age' is missing in type '{ name: string; }' but required in type 'Person'.

interface Person {
  name: string;
  age: number;
}

interface Person {
  age: string; // ❌ TS2717: Subsequent property declarations must have the same type.  Property 'age' must be of type 'number', but here has type 'string'.
}

type Point = { x: number }; // ❌ TS2300: Duplicate identifier 'Point'.
type Point = { y: number }; // ❌ TS2300: Duplicate identifier 'Point'.

interface Logger {
  log(message: string): string;
}

interface Logger {
  log(code: number): number;
}

declare const logger: Logger;

const s = logger.log("started"); // const s: string
const n = logger.log(404); // const n: number

declare global {
  interface Window {
    __APP_VERSION__: string;
  }
}

window.__APP_VERSION__ = "1.4.2";
console.log(window.__APP_VERSION__.toUpperCase());

extends isn't limited to other interfaces. An interface can extend any object type whose members are statically known: a type alias for an object, an intersection of object types, the result of a utility type like Omit<User, "password">, even a class (its instance type). The checker just needs to be able to list the parent's members so it can copy them in.

The one thing it can't extend is something that isn't a single, known shape — a union (which object is it?), a primitive, or a bare type parameter.

type Named = { name: string };
type Timestamps = { createdAt: Date; updatedAt: Date };

interface User extends Named, Timestamps {
  email: string;
  password: string;
}

interface PublicUser extends Omit<User, "password"> {
  avatarUrl?: string;
}

const pub: PublicUser = {
  name: "Ana",
  email: "ana@example.com",
  createdAt: new Date(),
  updatedAt: new Date(),
};

const withPassword = { ...pub, password: "hunter2" };
const leaked: PublicUser = withPassword; // fine: not a fresh literal, so no excess property check

type ID = string | number;
type Shape = { kind: "circle"; radius: number } | { kind: "square"; side: number };

interface BadId extends ID {} // ❌ TS2312: An interface can only extend an object type or intersection of object types with statically known members.
interface BadShape extends Shape {} // ❌ TS2312: An interface can only extend an object type or intersection of object types with statically known members.

type Tagged = Shape & { id: string }; // fine: & works on anything

They look like two spellings of the same thing, and most of the time they produce the same shape. They are not equivalent in two ways that interviewers love: what happens when the two sides conflict, and how much work they cost the type checker.

With extends, the checker builds a new interface and verifies it is a valid subtype of its parent, so a conflicting property is an error right at the declaration. With &, the checker doesn't verify anything when you write the type — it just intersects the property types, and a conflict quietly produces never. You only find out later, when you try to create a value and can't.

interface A {
  id: string;
}

interface B extends A { // ❌ TS2430: Interface 'B' incorrectly extends interface 'A'.
  id: number;
}

type A = { id: string };
type B = A & { id: number };

type BId = B["id"]; // type BId = never

const b: B = { id: "x" }; // ❌ TS2322: Type 'string' is not assignable to type 'never'.

type Circle = { kind: "circle"; radius: number };
type Square = { kind: "square"; side: number };

type Both = Circle & Square; // type Both = never

const both: Both = { kind: "circle", radius: 1, side: 2 }; // ❌ TS2322: Type 'string' is not assignable to type 'never'.

type Base = { status: string; log(msg: string): void };
type Narrowed = Base & { status: "active"; log(code: number): void };

type Status = Narrowed["status"]; // type Status = "active"

declare const n: Narrowed;
n.log("ready"); // fine
n.log(200); // fine: methods from both sides become overloads

type WithStringId = { id: string; name: string };
type WithNumericId = { id: number; age: number };
type Merged = WithStringId & WithNumericId;

const m: Merged = { id: 1, name: "Ana", age: 30 };

From my notes: use an interface for defining object shapes, especially in class-based code — APIs, configs, component props — because interfaces work well with classes that extend and implement them. Use a type for unions, intersections and tuples, and for aliases of primitives, arrays and functions.

That's a good rule of thumb, and it matches the TypeScript handbook's advice ("use interface until you need features from type"). These are the examples from my notes:

interface User {
  id: number;
  name: string;
  email: string;
}

class Person implements User {
  constructor(
    public id: number,
    public name: string,
    public email: string,
  ) {}
}

type ID = number | string;
type PersonT = { name: string; age: number };
type Employee = PersonT & { role: string };

type StringAlias = string;
type NumberArray = number[];
type AddFunction = (a: number, b: number) => number;

const add: AddFunction = (a, b) => a + b;

// 1
{ id: string; save(): void }
// 2
"GET" | "POST"
// 3
[latitude: number, longitude: number]
// 4
(value: string) => boolean
// 5
{ [K in "a" | "b"]: number }

class X implements Y asks the compiler one question: is an instance of X assignable to Y? If not, you get an error at the class declaration. That's all it does. It doesn't copy any members into the class, doesn't give types to your method parameters, and leaves no trace in the emitted JavaScript.

Because TypeScript is structural, you don't even need implements for a class to be usable where a Y is expected — any class whose instances have the right shape already is one. The value of implements is moving the error to where it's most useful: the class itself, at the moment you write it, rather than wherever the instance is first passed around.

This is the example from my notes, plus what happens when something is missing:

interface Animal {
  makeSound(): void;
}

class Dog implements Animal {
  makeSound() {
    console.log("Woof!");
  }
}

interface Speaker {
  speak(): void;
  volume: number;
}

class Quiet implements Speaker { // ❌ TS2420: Class 'Quiet' incorrectly implements interface 'Speaker'.
  speak() {}
}

interface Handler {
  handle(event: string): number;
}

class ClickHandler implements Handler {
  handle(event) { // ❌ TS7006: Parameter 'event' implicitly has an 'any' type.
    return event.length;
  }
}

class TypedHandler implements Handler {
  handle(event: string) {
    return event.length;
  }
}

Functions are values in JavaScript, so you need ways to write their types: for a variable holding a callback, for a parameter that receives one, for an object property that is a method. TypeScript gives you three syntaxes, and they mostly describe the same thing.

1. A function type expression: (a: number, b: number) => number. The parameter names are documentation only.
2. A call signature inside an object type or interface: { (a: number, b: number): number } — note the : instead of =>. This is the form to use when the function also has properties.
3. For functions that live on objects, method syntax greet(name: string): void or property syntax greet: (name: string) => void. These look interchangeable, but under strictFunctionTypes they're checked differently.

type AddFn = (a: number, b: number) => number;

interface AddFnI {
  (a: number, b: number): number;
}

const add: AddFn = (x, y) => x + y;
const add2: AddFnI = add;

interface Counter {
  (): number;
  count: number;
  reset(): void;
}

function makeCounter(): Counter {
  const counter = () => ++counter.count;
  counter.count = 0;
  counter.reset = () => {
    counter.count = 0;
  };
  return counter;
}

const next = makeCounter();
next(); // 1
next(); // 2
next.reset();
console.log(next.count); // 0

interface MethodStyle {
  handle(value: string | number): void;
}

interface PropertyStyle {
  handle: (value: string | number) => void;
}

const onlyStrings = (value: string) => console.log(value.toUpperCase());

const m: MethodStyle = { handle: onlyStrings }; // compiles: method parameters are bivariant
const p: PropertyStyle = { handle: onlyStrings }; // ❌ TS2322: Type '(value: string) => void' is not assignable to type '(value: string | number) => void'.

m.handle(42); // compiles; at runtime: TypeError: value.toUpperCase is not a function

Sometimes you know the type of the values but not the names of the keys: a cache keyed by URL, word counts, a map of feature flags loaded from a server. An index signature describes that: { [key: string]: number } means "any string key, and every value is a number". The name key is just documentation.

Think of it as a promise about every possible key at once. That's powerful, and it's also why index signatures need care: the checker believes the promise even for keys that don't exist.

const scores: { [name: string]: number } = {
  alice: 90,
  bob: 72,
};

scores.carol = 85; // fine: any string key is allowed
scores["dave"] = 60;
scores.erin = "A"; // ❌ TS2322: Type 'string' is not assignable to type 'number'.

const missing = scores.zoe; // const missing: number
missing.toFixed(1); // compiles; at runtime: TypeError: Cannot read properties of undefined (reading 'toFixed')

interface Config {
  [key: string]: number;
  name: string; // ❌ TS2411: Property 'name' of type 'string' is not assignable to 'string' index type 'number'.
}

interface ConfigFixed {
  [key: string]: number | string;
  name: string;
  retries: number;
}

interface Headers {
  readonly [key: `x-${string}`]: string;
  accept: string;
}

const h: Headers = { accept: "text/html", "x-request-id": "abc", authorization: "t" }; // ❌ TS2353: Object literal may only specify known properties, and 'authorization' does not exist in type 'Headers'.

interface UserI {
  name: string;
}

type UserT = {
  name: string;
};

declare const ui: UserI;
declare const ut: UserT;

const a: Record<string, unknown> = ut; // fine
const b: Record<string, unknown> = ui; // ❌ TS2322: Type 'UserI' is not assignable to type 'Record<string, unknown>'.

Both describe "an object whose keys are some set of strings". The difference is whether that set is open or closed.

An index signature is open: { [lang: string]: string } allows any number of keys — zero, one, or a thousand — and promises nothing about which exist. A mapped type is closed: { [L in "en" | "fr"]: string } iterates over a specific union of keys and produces exactly one property for each, so the result is { en: string; fr: string } — both required, nothing else allowed in a literal. Record<K, V> is a mapped type (see Record<K, V>); with K = string the mapped type has no specific keys to iterate, so it becomes an index signature.

type Lang = "en" | "fr" | "de";

type Open = { [lang: string]: string };
type Closed = { [L in Lang]: string }; // type Closed = { en: string; fr: string; de: string }

const greetingsOpen: Open = { en: "Hello" }; // fine: any subset of any keys
const greetingsClosed: Closed = { en: "Hello", fr: "Bonjour" }; // ❌ TS2741: Property 'de' is missing in type '{ en: string; fr: string; }' but required in type 'Closed'.

type Wrong = { [lang: Lang]: string }; // ❌ TS1337: An index signature parameter type cannot be a literal type or generic type. Consider using a mapped object type instead.

type Same = Record<string, string>; // identical to Open

interface Settings {
  theme: "light" | "dark";
  fontSize: number;
}

type Setters = {
  [K in keyof Settings]: (value: Settings[K]) => void;
};

const setters: Setters = {
  theme: (value) => console.log(value), // value: "light" | "dark"
  fontSize: (value) => console.log(value.toFixed(0)), // value: number
};