Difference between abstract class and interface, with scenario

WHAT THIS TESTS: This question probes your grasp of TypeScript's type system versus its runtime model. Interviewers want to see that you understand an abstract class is a real JavaScript class that runs in the browser or Node, consumes the single extends slot, and can hold fields and constructor logic. They also want to know you see an interface as a purely compile-time contract that is erased after type-checking and supports multiple implementation. The scenario portion checks whether you can justify locking a class into an inheritance hierarchy to guarantee shared state or initialization behavior.

A GOOD ANSWER COVERS: First, state that an abstract class can contain implemented methods, property fields, and a constructor that runs when subclasses are instantiated, while an interface describes only a shape with no runtime footprint. Second, note that TypeScript limits a class to one extends but allows multiple implements, so an abstract class is a heavier commitment. Third, explain that you reach for an abstract class when you need to enforce a contract and also share concrete behavior or state that would be dangerous to duplicate, such as initialization order or internal caches. Fourth, describe the scenario in terms of the is-a relationship and the risk of getting it wrong if you used an interface instead.

COMMON WRONG ANSWERS: Claiming that an abstract class is simply an interface that can have method bodies misses the runtime and single-inheritance implications. Saying you would use an abstract class just because you want to share a helper method ignores the fact that composition or a utility function could do the same thing without consuming extends. Confusing TypeScript interfaces with Java-style default methods is another red flag; TypeScript interfaces cannot carry implementation. Finally, giving a scenario where no shared state or constructor logic is needed shows you do not understand the trade-off.

LIKELY FOLLOW-UPS: The interviewer might ask how you would unit test a component that depends on an abstract class versus an interface. They could ask what happens to existing subclasses if you add a new abstract method to the base class. They might also probe whether you would ever combine both patterns, such as an abstract class implementing an interface to keep the contract separate from the implementation.

ONE CONCRETE EXAMPLE: Consider a charting library where every data source must expose a fetchData method, but every source also needs identical caching and request-deduplication logic. You define an abstract class ChartDataSource with an abstract fetchData method and a concrete internal cache map. Subclasses like LineChartSource and BarChartSource extend ChartDataSource, implement fetchData, and automatically inherit the cache. If you used an interface, you could enforce fetchData, but you would have to copy the cache logic into every subclass or risk inconsistent behavior. Because the cache is stateful and must be initialized before any fetch runs, the abstract class is the correct tool.