Interface vs. Class in TypeScript: The Choice Recruiters Notice

When writing TypeScript, one of the most common questions pops up: Should I model my data with an interface or a class?

At first glance, it feels like a minor decision. But here’s the secret: this choice often signals to recruiters and senior engineers how well you understand TypeScript’s philosophy and real-world software design.

So let’s break it down in plain, pragmatic terms.

Interfaces: The Pure Data Contract

An interface in TypeScript is like a handshake. It defines what the data looks like without dictating how it behaves.

Key traits:

• Compile-time only → Gone after transpilation.
• Lightweight → Perfect for DTOs (data transfer objects).
• Extensible → Easy to extend and merge.

Example:

Copy
1export interface User {
2  id: number
3  fName: string
4  lName: string
5  email: string
6  role: Role
7}

Here, User is a contract between backend and frontend. Nothing more, nothing less.

Best for:

API responses

Component props typing

State definitions in NgRx/Redux/Pinia

Classes: Data + Behaviour

A class goes beyond just structure — it exists at runtime and brings behaviour along.

Key traits:

• Runtime presence → Becomes real JS code.

• Encapsulation → Can include methods, getters, and validation.

• Instantiation → Great for creating reusable model objects.

Example:

Copy
1export class User {
2  constructor(
3    public id: number,
4    public fName: string,
5    public lName: string,
6    public email: string,
7    public role: Role
8  ) {}
9
10  get fullName(): string {
11    return `${this.fName} ${this.lName}`;
12  }
13}

This User isn’t just data — it knows how to give you its full name without repeating logic elsewhere.

Best for:

• Models with computed fields

• Data transformations

• Business logic tied to an entity

The Rule of Thumb

Think of it this way:

• Interfaces = contracts.

• Classes = contracts + behaviour.

• If it’s just shape from backend → Interface.

• If it needs logic attached → Class.

What Recruiters Really Notice

When recruiters or tech leads skim your GitHub repo or review code samples, they’re not just checking if your app works — they’re looking for pragmatism and judgment.

Interfaces for API responses (User, LoginResp, etc.) → shows clean TypeScript thinking.

Classes for models with logic → shows you know when to scale complexity.

The sweet spot is balance: don’t over-engineer with classes everywhere, but don’t shy away when logic calls for it.

Final Takeaway

Both interfaces and classes are essential in TypeScript. The magic is knowing when to reach for which.

Use interfaces for clean, lightweight contracts.

Use classes when your models need behavior.

If you showcase both approaches in your portfolio, you’ll stand out as someone who understands not just TypeScript, but good software design choices.

Your turn: In your projects, do your models live as pure contracts (interfaces) or do they carry smarts (classes)?