Key differences: type alias vs interface for object shapes

What's really being asked

This question probes whether you understand TypeScript's type system beyond surface syntax. Interviewers want to see that you know when types are open for extension versus closed, how declaration merging affects library design, and whether you can pick the right tool for modeling objects versus unions or computed types. It separates developers who copy syntax from those who understand compiler behavior and maintainability.

The full answer

A strong answer hits four things in order. First, interfaces support declaration merging, meaning multiple declarations of the same name in the same scope automatically combine, which is critical for augmenting third-party types or evolving public APIs safely. Second, interfaces extend other interfaces using the extends keyword, while type aliases compose via intersection operators, and interfaces generally produce clearer error messages and faster structural comparisons for object shapes. Third, type aliases can represent unions, tuples, mapped types, conditional types, and primitives, whereas interfaces are limited to object-like structures. Fourth, practical preference: use interfaces for public contracts, class implements, and library definitions that consumers might need to augment; use type aliases for unions, derived types, or when you need to alias a complex expression that includes primitives or conditionals.

The mistakes people make

The biggest red flag is claiming the two are identical except for the keyword, because declaration merging and extensibility rules create real differences in large codebases. Another mistake is saying interfaces are always better for performance without explaining why, or asserting that type aliases cannot describe objects at all. Avoid recommending one universally; senior engineers should justify the choice based on team conventions, API surface area, and whether the shape might need augmentation.

What usually comes next

Interviewers often push deeper by asking how you would augment a third-party library type safely, which leads to interface merging. They might ask how to model a response that could be one of several shapes, pushing you toward a type alias with a union. Another follow-up is performance: ask when excessive intersection types on aliases might slow compilation compared to interfaces. They may also ask about class implements and whether there is any difference when a class implements an interface versus a type alias.

A concrete example

Imagine you are building a design system. You define a ButtonProps interface so consumers can merge in their own theme-specific props via declaration merging in a global file. Internally, you derive a StrictButtonProps type using Pick and Omit to create internal variants, because you need a computed mapping, not an extensible contract. The interface stays public and open; the type alias stays internal and closed.