What Interviewers Want - Learning Module

Loading content...

0/246

Object-Oriented Understanding

Beyond Syntax: Proving You Understand OOP

In LLD interviews, interviewers assume you know object-oriented syntax. They're not checking whether you can write a class or define an interface. What they're evaluating is something deeper: whether you truly understand why OOP concepts exist and when to apply them.\n\nThis distinction is critical. Many candidates can recite the four pillars—encapsulation, inheritance, polymorphism, and abstraction—but struggle to apply them wisely. They inherit when they should compose. They expose internals when they should encapsulate. They force polymorphism where simple conditionals suffice. These missteps reveal superficial understanding.

What You Will Master

By the end of this page, you will understand how interviewers probe for genuine OOP comprehension, what signals distinguish surface knowledge from deep understanding, and how to demonstrate mastery through your design choices and explanations.

What Interviewers Mean by OOP Understanding

Object-oriented understanding in an LLD context goes far beyond knowing syntax. Interviewers evaluate whether you can:\n\n1. Model domains accurately using classes, interfaces, and relationships\n2. Apply encapsulation to protect invariants and hide complexity\n3. Use inheritance and composition appropriately based on relationship semantics\n4. Leverage polymorphism to enable extensibility where it matters\n5. Create meaningful abstractions that simplify without obscuring\n6. Avoid OOP anti-patterns that emerge from misunderstanding\n\nThe evaluation happens organically as you design. Every class you define, every method you assign, every relationship you draw reveals your understanding level.

The Implicit Test

Interviewers rarely ask 'What is polymorphism?' directly. Instead, they watch whether your design naturally uses polymorphism where appropriate—and critically, whether you can explain why you made that choice when asked. The test is implicit in your design, not explicit in a quiz.

Deep Encapsulation: Beyond Getters and Setters

Many developers think encapsulation means making fields private and adding getters/setters. This misses the point entirely. True encapsulation is about protecting invariants and hiding implementation decisions.\n\nWhat invariants means:\n\nAn invariant is a condition that must always be true for an object to be in a valid state. For example:\n- A Booking should always have a valid showId and at least one seat\n- A PaymentTransaction should never have a negative amount\n- A ParkingSpot that is occupied should always reference the occupying vehicle\n\nEncapsulation ensures these invariants cannot be violated from outside the object.

Weak Encapsulation

•Exposing mutable collections (returning lists that callers can modify)
•Using setters that allow invalid states (setAmount(-100))
•Exposing internal representation details (returning internal data structures)
•Requiring external coordination for valid transitions
•Public fields or unrestricted getters for all internal state

Strong Encapsulation

•Returning immutable views or copies of collections
•Validating all mutations within the object itself
•Hiding data structure choices behind behavior-oriented APIs
•Object manages its own state transitions completely
•Exposing only what's necessary for the object's role

Encapsulation Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// WEAK ENCAPSULATION - Invariants can be violated externally
public class BookingBad {
    private List<Seat> seats = new ArrayList<>();
    private BookingStatus status;
    
    // Problem: External code can add null seats or empty the list
    public List<Seat> getSeats() { return seats; }
    
    // Problem: Status can be set to anything
    public void setStatus(BookingStatus status) { this.status = status; }
}
 
// STRONG ENCAPSULATION - Object protects its own invariants
public class BookingGood {
    private final List<Seat> seats;
    private BookingStatus status;
    
    public BookingGood(Show show, List<Seat> selectedSeats) {
        if (selectedSeats == null || selectedSeats.isEmpty()) {
            throw new IllegalArgumentException("Booking requires at least one seat");
        }
        // Defensive copy to prevent external modification
        this.seats = new ArrayList<>(selectedSeats);
        this.status = BookingStatus.PENDING;
    }
    
    // Return immutable view - can't be modified
    public List<Seat> getSeats() {
        return Collections.unmodifiableList(seats);
    }
    
    // Object controls valid transitions
    public void confirm(PaymentConfirmation payment) {
        if (status != BookingStatus.PENDING) {
            throw new IllegalStateException("Can only confirm pending bookings");
        }
        // ... validate payment
        this.status = BookingStatus.CONFIRMED;
    }
    
    public void cancel(String reason) {
        if (status == BookingStatus.COMPLETED) {
            throw new IllegalStateException("Cannot cancel completed bookings");
        }
        this.status = BookingStatus.CANCELLED;
    }
}

Interview Signal

When you discuss your design, mention invariants explicitly: 'This class enforces that a booking always has at least one seat—that's an invariant it protects.' This signals deep understanding of encapsulation's purpose, not just mechanical application.

Inheritance vs Composition: The Critical Choice

Perhaps no OOP decision reveals understanding more clearly than the choice between inheritance and composition. Interviewers watch this closely because it's frequently misapplied.\n\nThe Core Distinction:\n\n- Inheritance models an "is-a" relationship: A Dog is an Animal\n- Composition models a "has-a" relationship: A Car has an Engine\n\nBut this simplistic framing is often insufficient. The deeper question is: Should behavior be shared through a class hierarchy or through delegation?

When to Use Inheritance vs Composition
Factor	Favors Inheritance	Favors Composition
Relationship Type	True 'is-a' that won't change (Circle is-a Shape)	'Has-a' or 'can-do' relationships (Car has-a Engine)
Behavior Variation	Subclasses are genuine specializations	Behavior varies independently of the object's type
Substitutability	Subclasses fully substitute for parent (Liskov)	Behaviors can be swapped without changing the object
Coupling Tolerance	Acceptable tight coupling; hierarchy is stable	Need loose coupling; behaviors may change independently
Multiple Behaviors	Single line of variation	Multiple orthogonal axes of variation

The Interview Trap: Over-Inheritance\n\nCandidates frequently overuse inheritance because it seems natural. Common mistakes include:\n\n- PremiumUser extends User (Role behavior should be composed, not inherited—users can change roles)\n- EmailNotification extends Notification when Notification should compose a notifier strategy\n- Creating deep hierarchies where multiple levels share little behavior\n\nInterviewers look for whether you instinctively reach for inheritance or whether you evaluate both options.

The Fragile Base Class Problem

Inheritance creates tight coupling between parent and child classes. Changes to the parent can break children in subtle ways. Interviewers are wary of deep hierarchies because they've seen this problem in production. Prefer shallow hierarchies (usually just one level) and use composition for most behavior sharing.

Inheritance vs Composition
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
// PROBLEMATIC INHERITANCE - Price calculation varies independently
abstract class Vehicle {
    protected String licensePlate;
    protected VehicleType type;
    
    abstract double calculateParkingPrice(Duration duration);
}
 
class Car extends Vehicle {
    double calculateParkingPrice(Duration duration) { /* car pricing */ }
}
 
class ElectricCar extends Car {  // Deep inheritance to add charging!
    private ChargingMeter meter;
    
    @Override
    double calculateParkingPrice(Duration duration) {
        return super.calculateParkingPrice(duration) + meter.getChargeCost();
    }
}
// What if we need ElectricMotorcycle? Multiple inheritance problem!
 
// BETTER: COMPOSITION - Pricing is a separate concern
class Vehicle {
    private String licensePlate;
    private VehicleType type;
    private PricingStrategy pricingStrategy;
    
    Vehicle(String licensePlate, VehicleType type, PricingStrategy pricing) {
        this.licensePlate = licensePlate;
        this.type = type;
        this.pricingStrategy = pricing;
    }
    
    double calculateParkingPrice(Duration duration) {
        return pricingStrategy.calculate(this, duration);
    }
}
 
interface PricingStrategy {
    double calculate(Vehicle vehicle, Duration duration);
}
 
class StandardPricing implements PricingStrategy { ... }
class ElectricPricing implements PricingStrategy {  // Adds charging cost
    private StandardPricing basePricing;
    double calculate(Vehicle v, Duration d) {
        return basePricing.calculate(v, d) + getChargingCost(v, d);
    }
}
// Now ANY vehicle can have electric pricing without deep inheritance!

Polymorphism Applied Correctly

Polymorphism—the ability to treat different implementations through a common interface—is powerful but often misapplied. Interviewers assess whether you use polymorphism to solve real variability or whether you force it unnecessarily.\n\nWhen polymorphism earns its place:\n\n1. Multiple implementations exist or are expected — Different payment processors, notification channels, scheduling algorithms\n2. The calling code shouldn't know the specific type — Processing payments without knowing if it's Stripe, PayPal, or bank transfer\n3. New implementations will be added — The system must be open for extension\n4. Complex conditionals would otherwise emerge — Replace type-checking with polymorphic dispatch

Forced Polymorphism

•Creating an interface with one implementation 'for future flexibility'
•Abstract classes where concrete implementations are identical
•Polymorphism for variation that will never change (hardcoded list of two items)
•Replacing a simple if/else with Strategy pattern for single-case behavior

Justified Polymorphism

•Payment processors—multiple exist, more will be added
•Notification channels—email, SMS, push have genuinely different implementations
•Scheduling algorithms—FCFS, SCAN, LOOK have different behaviors
•Chess piece movement—each piece type has distinct legal moves

Demonstrating Polymorphism Understanding in Interviews:\n\nWhen you introduce an interface or abstraction, explain why:\n\n*"I'm defining a PaymentProcessor interface because the system needs to support multiple payment methods—Stripe today, but likely PayPal and bank transfers soon. The booking service should work with any processor without knowing which one."*\n\nThis connects polymorphism to a concrete need, not abstract 'best practice.'

The Replace Conditional Refactoring

One of polymorphism's strongest use cases is replacing type-checking conditionals. If you find yourself writing 'if type == A then ... else if type == B then ...', this is often a signal that polymorphism should dispatch behavior instead. Interviewers respect candidates who recognize this pattern.

Abstraction at the Right Level

Abstraction is about hiding complexity behind simpler interfaces. But the art lies in finding the right level—abstracting enough to simplify without obscuring essential details.\n\nToo Little Abstraction:\n- Every detail is exposed\n- Clients must understand internal workings\n- Changes ripple across the entire codebase\n- Cognitive load is high\n\nToo Much Abstraction:\n- Simple operations require navigating layers\n- The actual behavior is hidden behind indirection\n- Debugging becomes archaeological excavation\n- Performance may suffer from abstraction overhead\n\nJust Right:\n- Clients interact with meaningful concepts\n- Implementation details are hidden but accessible when needed\n- Changes are localized appropriately\n- The abstraction maps to how people think about the domain

Abstraction Level Examples
Scenario	Too Little	Too Much	Just Right
Parking lot spot allocation	Client iterates arrays, checks spot sizes, handles concurrency	AbstractSpotAllocatorFactory → AllocatorBuilder → Strategy → Policy → Executor	ParkingLot.findAvailableSpot(VehicleType) — returns spot or null
Payment processing	Client constructs HTTP requests to payment APIs, parses responses, handles retries	PaymentFacade → PaymentOrchestrator → PaymentAdapter → PaymentClient → PaymentSerializer	PaymentProcessor.charge(amount, method) — returns PaymentResult
Notification sending	Client manages SMTP connections, SMS API keys, push notification tokens	NotificationEngine → ChannelRouter → ChannelFactory → ChannelImplManager → Sender	NotificationService.notify(user, message, channel) — handles channel-specific logic internally

Interviewers' Abstraction Test:\n\nInterviewers often probe abstraction decisions:\n- "Why did you create an interface here?"\n- "What if I only need one implementation?"\n- "This seems like a lot of layers—can we simplify?"\n\nStrong candidates defend their abstractions with concrete reasons or acknowledge when they've over-abstracted and simplify.

The Rule of Three

A useful heuristic: Don't abstract until you've seen three instances. One case isn't a pattern. Two may be coincidence. Three suggests genuine variation worth abstracting. This prevents premature abstraction while still capturing proven patterns.

Object Responsibilities: Who Does What

A key OOP skill is assigning responsibilities to the right objects. This connects to the Single Responsibility Principle, but more fundamentally it's about information expert—the object with the data should have the behavior.\n\nThe Interview Test:\n\nInterviewers watch where you place methods. If Booking holds the seats, then seat-related calculations belong there, not in a separate service. If ParkingLot tracks capacity, then availability checks belong there.

Responsibility Assignment
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
// POOR: Service knows too much about Booking's internals
class BookingService {
    boolean isCancellable(Booking booking) {
        // Service reaches into Booking's state - wrong!
        List<Seat> seats = booking.getSeats();
        BookingStatus status = booking.getStatus();
        LocalDateTime showTime = booking.getShow().getStartTime();
        
        return status != BookingStatus.CANCELLED 
            && status != BookingStatus.COMPLETED
            && showTime.isAfter(LocalDateTime.now().plusHours(1));
    }
    
    void cancel(Booking booking) {
        if (isCancellable(booking)) {
            booking.setStatus(BookingStatus.CANCELLED);  // Setter!
            // Service handles all the logic externally
        }
    }
}
 
// BETTER: Booking knows its own rules
class Booking {
    private BookingStatus status;
    private Show show;
    private List<Seat> seats;
    
    public boolean isCancellable() {
        // Booking has the data, so it should answer the question
        return status != BookingStatus.CANCELLED 
            && status != BookingStatus.COMPLETED
            && show.getStartTime().isAfter(LocalDateTime.now().plusHours(1));
    }
    
    public void cancel(String reason) {
        if (!isCancellable()) {
            throw new IllegalStateException("Booking cannot be cancelled at this time");
        }
        this.status = BookingStatus.CANCELLED;
        // Booking manages its own state
    }
}
 
class BookingService {
    // Service orchestrates, doesn't micromanage
    void processCancel(BookingId id, String reason) {
        Booking booking = repository.find(id);
        booking.cancel(reason);  // Delegate to the expert
        repository.save(booking);
        notifyUser(booking);
    }
}

Responsibility Assignment Guidelines

•Information Expert — Assign behavior to the object that has the necessary data
•Tell, Don't Ask — Tell objects what to do rather than asking for their data and doing it externally
•Low Coupling — Minimize how much objects need to know about each other's internals
•High Cohesion — Keep related behaviors together in the same object
•Protected State — Objects should manage their own state transitions

The Anemic Domain Model Smell

If your domain objects are mostly data containers (getters/setters only) with all logic in services, you have an anemic domain model. This isn't always wrong—in some architectures it's intentional—but in LLD interviews, interviewers often prefer rich domain models where objects have behavior. Be prepared to discuss the trade-offs.

Common OOP Anti-Patterns to Avoid

Interviewers watch for anti-patterns that reveal gaps in OOP understanding. Avoiding these mistakes signals experience:

OOP Anti-Patterns in LLD Interviews
Anti-Pattern	What It Looks Like	Why It's Problematic	Better Approach
God Object	One class (Manager, Controller, Handler) that does everything	Violates SRP, becomes maintenance nightmare, impossible to test	Decompose into focused classes with single responsibilities
Primitive Obsession	Using strings, ints everywhere instead of domain types	No type safety, can pass wrong values, no behavior encapsulation	Create value objects: Money, Email, VehicleId, etc.
Feature Envy	A method uses more of another object's data than its own	Behavior is in the wrong place; breaks information expert	Move the method to the object whose data it uses
Yo-Yo Problem	Deep inheritance hierarchy requiring constant jumping between classes	Hard to understand, fragile, defeats cognitive benefits of OOP	Prefer shallow hierarchies and composition
Refused Bequest	Subclass inherits but doesn't use or overrides parent methods to do nothing	Violates Liskov Substitution, indicates wrong hierarchy	Question if inheritance is appropriate; use composition instead

The Manager/Helper/Util Class Smell

Classes named 'XxxManager', 'XxxHelper', or 'XxxUtil' often indicate poor responsibility assignment. They tend to become God Objects. When you're tempted to create one, ask: 'Which existing object should own this behavior?' or 'What focused object should I create instead?'

Demonstrating OOP Understanding in Interviews

Your OOP understanding comes through in every design choice. Here's how to make it visible:

Strategies for Demonstrating OOP Mastery

•Verbalize Encapsulation Thinking — 'This class protects the invariant that an order always has at least one item—it validates in the constructor and doesn't expose the list mutably.'
•Explicitly Compare Inheritance and Composition — 'I considered inheritance for vehicle types, but pricing varies independently, so I'm composing with a pricing strategy.'
•Explain Polymorphism Purpose — 'I'm using an interface here because we need to swap implementations—different notification channels—without changing the caller.'
•Defend Abstraction Choices — Be ready to say 'I added this interface because...' or 'I kept this concrete because there's no variation yet.'
•Assign Responsibilities Deliberately — 'The Booking should answer whether it's cancellable—it has the status and show time data.'
•Flag Anti-Patterns Proactively — 'I'm avoiding a OrderManager because that tends to become a God Object; instead, Order handles its own transitions.'

The Meta Signal

Beyond specific techniques, what impresses interviewers is that you THINK about OOP deliberately. You consider trade-offs, question defaults, and make intentional choices. Even if you make a suboptimal choice, explaining your reasoning shows the understanding they're looking for.

Summary: Object-Oriented Understanding

We've explored the second critical dimension interviewers evaluate: deep comprehension of object-oriented principles and their appropriate application. Let's consolidate:

Key Takeaways

•OOP understanding is demonstrated, not stated — Your design choices reveal your comprehension level.
•Encapsulation protects invariants — It's not just about private fields; it's about objects guaranteeing their own validity.
•Inheritance vs Composition is a critical choice — Prefer composition unless true 'is-a' substitutability exists.
•Polymorphism must be justified — Use it for real variation, not speculative flexibility.
•Abstraction level matters — Too little exposes complexity; too much creates maze-like code.
•Responsibilities belong to information experts — Objects with the data should have the behavior.
•Anti-patterns signal inexperience — Avoid God Objects, Primitive Obsession, and related smells.
•Verbalize your reasoning — Make your OOP thinking visible to interviewers.

What's next:\n\nWith design thinking and OOP understanding covered, the next page explores pattern knowledge application—how interviewers assess whether you truly understand design patterns and can apply them purposefully rather than mechanically.

Page Complete

You now understand how interviewers evaluate OOP comprehension. This goes far beyond syntax—it's about applying encapsulation, inheritance, polymorphism, and abstraction wisely, and assigning responsibilities to the right objects. Next, we'll examine how to demonstrate pattern knowledge effectively.