What is the Liskov Substitution Principle and how is it violated?
Assesses fundamental understanding of OOP Concepts conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
The Liskov Substitution Principle says objects of a subtype must be usable anywhere the supertype is expected, without the caller knowing or behaving differently. Subtypes may strengthen guarantees, never weaken them.
The classic violation is Square extends Rectangle. Setting width on a rectangle implies height is unchanged, but a square must also change height, so code that mutates a rectangle breaks when handed a square.
void resize(Rectangle r) {
r.setWidth(5);
r.setHeight(4);
assert r.area() == 20; // fails for Square
}
Another violation is a subtype that throws for a method the base promises to support, or that returns a narrower result. Fixes include favouring composition, extracting a common interface with only genuinely shared behaviour, or making the hierarchy immutable. LSP is really about honouring the base type's preconditions, postconditions and invariants.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.