Abstraction
OOP · 8 interview questions
Abstraction is choosing which details to expose and which to hide. A List tells you it can add, remove and iterate; whether it is backed by an array or a linked structure is deliberately not part of the contract.
The practical value is that callers depend on a promise rather than a mechanism. As long as the promise holds, the mechanism can be replaced — which is what makes large systems changeable at all.
The failure mode worth naming is the leaky abstraction: an interface that technically hides the implementation while its performance or error behaviour still forces callers to know what's underneath. An interface method that is O(1) on one implementation and O(n) on another has leaked.
Abstraction interview questions
- What is abstraction?
- Exposing only the essential behaviour of something while hiding the implementation details, so callers depend on what it does rather than how it does it.
- What is a leaky abstraction?
- One whose details show through despite the interface hiding them — usually via performance or error behaviour. An interface whose implementations differ from O(1) to O(n) forces callers to know which one they hold, which is exactly what it claimed to hide.
- Why they ask: Naming this shows you've hit the limits of the idea in practice, not just learned the definition.
- What is an abstract class?
- A class that cannot be instantiated and may declare methods without implementations. It exists to be extended, providing shared state and behaviour while leaving specific pieces to subclasses.
- Why can't you instantiate an abstract class?
- Because it may contain methods with no implementation, so an instance could be asked to do something it has no code for. It represents an incomplete concept.
- Abstraction or encapsulation — which one is 'hiding'?
- Both, at different levels. Abstraction hides complexity at the design level by deciding what to expose. Encapsulation hides data at the implementation level by enforcing that decision with access control.
- What does it mean for code to mix levels of abstraction?
- A single function doing both high-level orchestration and low-level detail — calling processOrder() and then manually formatting a date string next to it. It makes the function hard to read because there is no consistent altitude.
- What's the risk of abstracting too early?
- You design the interface around one use case and it fits the second one badly, so the abstraction has to be reworked or worked around. An abstraction needs at least two or three real cases before its shape is knowable.
- Give a real abstraction you use constantly without thinking about it.
- A file handle. Reading bytes is the same call whether the data is on an SSD, a network mount or a pipe. The operating system exposes read and write; everything about the device is hidden.
You'll forget most of this by next week
That's not a discipline problem, it's how memory works. In the app these come back on an expanding schedule — right before you'd lose them.
Start free for 7 days