OOP interview questions
for developers in 2027

Most enterprise and product code in Java, C#, Kotlin, Python and TypeScript is organised with objects. Interviewers test object-oriented design because it predicts how maintainable your code will be — and because low-level design (LLD) rounds are now standard in many Indian product companies and GCCs for mid-level roles.

OOP skill sits under almost every software engineering role. AmbitionBox shows typical software engineer pay in India of ₹9.3–10.2 lakh in October 2026,⁶ and LLD performance is often what separates offers at the same level.

Pillars: encapsulation, inheritance, polymorphism, abstraction

4

SOLID principles

5

Typical software engineer pay in India (AmbitionBox, Oct 2026)

₹9.3–10.2 lakh

Most useful principle to demonstrate: composition over inheritance

1

Table: How OOP is tested in interviews (editorial summary)

interface PricingStrategy {
    Money priceFor(Ticket ticket, Instant exitTime);
}

class HourlyPricing implements PricingStrategy {
    private final Money ratePerHour;
    HourlyPricing(Money ratePerHour) { this.ratePerHour = ratePerHour; }
    public Money priceFor(Ticket t, Instant exit) {
        long hours = Math.max(1, Duration.between(t.entryTime(), exit).toHours());
        return ratePerHour.times(hours);
    }
}

class ParkingLot {
    private final SpotAllocator allocator;
    private final PricingStrategy pricing;
    ParkingLot(SpotAllocator allocator, PricingStrategy pricing) {
        this.allocator = allocator; this.pricing = pricing;
    }
    Money exit(Ticket t, Instant exitTime) {
        allocator.release(t.spot());
        return pricing.priceFor(t, exitTime);
    }
}

Explain: pricing varies, so it's behind an interface (strategy pattern, open/closed); the lot depends on abstractions passed in (dependency inversion), so tests can supply a fake allocator and a fixed price; adding flat or weekend pricing means a new class, not edits to ParkingLot.

"Explain polymorphism with an example from your work."

"Our notification service calls send() on a Notifier interface; email, SMS and WhatsApp implementations each handle it differently, and adding a channel didn't change the caller."

"Abstract class or interface?"

Interfaces define capabilities without state (and can have default methods in many languages); abstract classes share state and partial implementation. Prefer interfaces at boundaries.

"What is the Liskov substitution principle?"

Subtypes must work wherever their base type is expected without surprises. The classic violation: a Square that breaks a Rectangle's width/height behaviour.

"Why is singleton considered harmful?"

It introduces hidden global state and makes testing and concurrency harder. Prefer a single instance managed by dependency injection.

"What's wrong with a 2,000-line OrderService?"

It has many reasons to change (single responsibility violation). Split by responsibility: pricing, payment, notification, persistence.

"Composition vs inheritance — example?"

A Logger used by many classes (composition) rather than every class extending a LoggingBase.

"How does dependency injection help testing?"

Dependencies are passed in, so tests can substitute fakes or mocks without changing production code.

"Design a library management system."

Clarify features; identify entities (Book, Copy, Member, Loan); assign responsibilities; define interfaces for search and notification; discuss fines, reservations and extensibility.

Table: How OOP expectations have changed (editorial summary)

1. Five LLDs — Parking lot, library, elevator, splitwise, movie booking — each with a changing requirement added halfway.
2. Refactor a god class — Split responsibilities and add tests before and after.
3. Pattern fit — For each common pattern, find a real example in an open-source codebase.
4. Replace inheritance — Turn a deep hierarchy into composition with interfaces.
5. Review AI output — Ask an assistant for a class design and critique it against SOLID.

Table: Roles built on object-oriented design and typical pay in India (AmbitionBox, October 2026; indicative)

1. Week 1: Pillars — Examples of each pillar in your main language.
2. Week 2: SOLID and composition — Refactor small examples that violate each principle.
3. Week 3: Patterns and DI — Implement strategy, factory, observer, decorator; use DI in a small app.
4. Week 4: LLD and proof — Three LLD mocks; take the Object-Oriented Programming Certification.

Related: Software Architecture Fundamentals, Code Review and Code Quality and Java Programming.

• Feature design — deciding which classes own new behaviour before writing code.
• Refactoring — splitting a growing service class when a new requirement makes it harder to change.
• Interfaces at boundaries — wrapping payment, SMS or storage providers behind interfaces so they can be swapped or faked.
• Code review — questioning deep inheritance, god classes and hidden global state.
• Testing — using dependency injection so business logic can be tested without databases or networks.
• Design discussions — explaining trade-offs to teammates with simple diagrams.

• How do you approach design for new features — documents, diagrams or discussion?
• Is there a part of the codebase that's hard to change? Why?
• How do you use dependency injection and testing together?
• Do you favour composition or inheritance in practice?
• How are design decisions recorded?

"What is the open/closed principle, with an example?"

Code should be open to extension but closed to modification — add a new payment method by adding a class that implements PaymentMethod, not by editing a switch statement.

"What is dependency inversion?"

High-level modules depend on abstractions, not concrete details; the database or email provider is injected behind an interface.

"When is inheritance the right choice?"

For a genuine, stable is-a relationship where the subclass truly can stand in for the parent, and the base class is designed for extension.

"How would you refactor a 500-line method?"

Add tests around current behaviour, extract well-named methods for each step, move logic to the classes that own the data, and simplify conditionals — committing in small steps.

"What is the difference between an object and a class?"

A class is a blueprint describing data and behaviour; an object is an instance created from it with its own state.

• Textbook definitions without real examples.
• Deep inheritance hierarchies in LLD answers.
• Patterns for their own sake.
• God classes that do everything.
• Ignoring changing requirements in design rounds.

References are Oracle's Java OOP tutorial, Microsoft Learn's C# OOP tutorial, Python's classes tutorial, Martin Fowler's writing on dependency injection and his refactoring catalogue; pay from AmbitionBox (read October 2026). Interview formats and the history table are editorial summaries. Science of Apps publishes the free certification linked here. Last reviewed October 2026.

• Encapsulation — bundling data with the methods that change it, hiding internals.
• Polymorphism — one interface, many implementations.
• SOLID — five principles for maintainable object-oriented design.
• Composition — building behaviour by combining objects rather than inheriting.
• Design pattern — a reusable solution to a common design problem.
• Low-level design (LLD) — designing classes and interactions for a specific system.