Java OOPs Interview Questions With Real Examples That Actually Get Asked

⏱️ 9 min read | 📚 Updated July 2026

Picture this: you’ve cleared the aptitude round at TCS or cracked the coding test at an EPAM walk-in. Now you’re sitting across from a technical interviewer who leans back and says, “Tell me the four pillars of OOP.” You rattle them off. Then comes the real question: “Give me a production scenario where you used polymorphism to avoid a chain of if-else blocks.” Silence.

That’s the gap this post closes. Java OOPs interview questions are evergreen — every company from Infosys to a Series-B startup asks them — but most candidates memorize definitions without understanding the why. After reading this, you’ll be able to explain abstraction, encapsulation, inheritance, and polymorphism with concrete code, justify your design choices, and handle the follow-up questions that separate shortlisted candidates from the rejected ones.

This guide is for Java developers with 0–4 years of experience preparing for service companies (TCS, Infosys, Wipro) and product companies (EPAM, startups). All code examples are Java 17 compatible.

Table of Contents

• What Interviewers Are Actually Testing
• OOPs Questions by Interview Round
• The Four Pillars — Deep Dives With Code
• Common Wrong Answers and How to Fix Them
• A Realistic 1-Week Prep Plan
• Frequently Asked Questions

What Interviewers Are Actually Testing

When a TCS or Wipro interviewer asks OOPs questions in a service-company round, they’re checking baseline competence — can you explain the concepts clearly and write basic code. At EPAM or a product startup, the bar shifts. They want to see design judgment: can you pick the right OOP tool for a real problem, and do you know when not to use inheritance?

The single biggest signal interviewers look for is whether you can connect theory to working code. Saying “encapsulation is data hiding” gets you nowhere. Showing a BankAccount class where balance is private and only modified through validated setters — that gets you to the next round. Keep this framing in mind through every section below.

OOPs Questions by Interview Round

Round	Duration	OOPs Topics	Difficulty
TCS / Infosys Written	20–30 min	Definitions, output prediction, basic inheritance MCQs	Low
Technical Interview Round 1	45–60 min	Pillars with examples, method overloading vs overriding, abstract class vs interface	Medium
EPAM / Startup Technical	60–90 min	Design problems, SOLID principles, real tradeoffs of inheritance vs composition	High

The Four Pillars — Deep Dives With Code

1. Encapsulation — Not Just “Private Fields”

Encapsulation means bundling data and the methods that operate on it together, and controlling access through a well-defined interface. The classic mistake candidates make is saying encapsulation is just about making fields private. That’s necessary but not sufficient. A class that has a private field but a setter that accepts any value without validation is encapsulating nothing.

public class BankAccount {
    private double balance; // private field — start of encapsulation

    public void deposit(double amount) {
        if (amount <= 0) throw new IllegalArgumentException("Amount must be positive");
        this.balance += amount; // logic lives here, not with the caller
    }

    public double getBalance() {
        return balance; // read-only access; no direct mutation allowed
    }
}

The balance field can never go negative through deposit because the class owns the rule. In a microservices context, this is exactly how a WalletService protects its internal state — no other service touches the balance directly; they call an API. Follow-up they'll ask: "What breaks if we make balance public?" Answer: any caller can set it to -10000, bypassing business rules entirely. Thread safety also becomes impossible to guarantee.

2. Inheritance — Powerful, and Easily Abused

Inheritance lets a subclass reuse and extend behaviour from a superclass. The interview angle here is usually the "IS-A" test, method overriding, and super. But the question that trips mid-level candidates is: "When would you choose composition over inheritance?" That's where EPAM and startups separate you from TCS rote-learners.

public class Vehicle {
    protected String brand;

    public void startEngine() {
        System.out.println(brand + " engine started");
    }
}

public class ElectricCar extends Vehicle {
    @Override
    public void startEngine() {
        // Electric cars don't have a combustion engine
        System.out.println(brand + " motor activated silently");
    }
}

Notice the @Override annotation — always use it. It makes the compiler catch typos like startengine() that would silently create a new method instead of overriding. Follow-up: "Can Java support multiple inheritance?" No, not with classes — to avoid the Diamond Problem. But a class can implement multiple interfaces. If those interfaces have default methods with the same signature, the implementing class must override it explicitly. That's a Java 8+ detail that impresses interviewers.

Pro Tip: If inheriting a class requires you to override methods just to throw UnsupportedOperationException, that's a Liskov Substitution Principle violation — a red flag in any design discussion. Mention this at EPAM or a startup and you'll stand out immediately.

3. Polymorphism — The One That Actually Comes Up in Production

Polymorphism is the ability of a single interface to represent different underlying types. Java supports two kinds: compile-time (method overloading) and runtime (method overriding via dynamic dispatch). Runtime polymorphism is what interviewers care about, because it's what lets you write extensible systems.

public abstract class PaymentProcessor {
    public abstract void process(double amount);
}

public class UpiProcessor extends PaymentProcessor {
    @Override
    public void process(double amount) {
        System.out.println("Processing ₹" + amount + " via UPI");
    }
}

public class CardProcessor extends PaymentProcessor {
    @Override
    public void process(double amount) {
        System.out.println("Processing ₹" + amount + " via Card");
    }
}

// In your service:
PaymentProcessor processor = getProcessor(userChoice); // returns UPI or Card
processor.process(500.0); // correct method called at runtime

This is the real answer to "where does polymorphism help in production?" — a payment gateway, a notification service (Email/SMS/Push), a report exporter (PDF/Excel/CSV). One method call, multiple behaviours. Follow-up: "What is dynamic dispatch?" The JVM resolves which overridden method to call based on the actual object type at runtime, not the reference type. This happens through the vtable mechanism — you don't need to explain vtables in an interview, but knowing the term shows depth.

4. Abstraction — Hiding Complexity, Not Just Using Abstract Classes

Abstraction means exposing only what's necessary and hiding implementation details. In Java, you achieve it through abstract classes and interfaces. The question candidates always get confused on: "What's the difference between an abstract class and an interface, and when do you pick which?"

Feature	Abstract Class	Interface
Constructor	Yes	No
State (fields)	Yes, including instance variables	Only public static final constants
Multiple inheritance	No (one class only)	Yes (a class can implement many)
Default methods	Yes (since always)	Yes (since Java 8)
Use when	Shared base behaviour + IS-A relationship	Defining a contract/capability (CAN-DO)

The practical rule: use an interface when you're defining a capability (Serializable, Comparable, Runnable). Use an abstract class when you have shared code that subclasses should inherit along with a common identity. Reach for Oracle's official Java API docs to verify these definitions if you're unsure. For a deeper look at related patterns, check our Java Advanced topics section.

Common Wrong Answers and How to Fix Them

Mistake 1: "Overloading is runtime polymorphism." Wrong — overloading is resolved at compile time by the compiler based on method signatures. Runtime polymorphism is about overriding. If you say this in a Wipro or Infosys interview, expect the interviewer to push back.

Mistake 2: Confusing super() with this(). super() calls the parent class constructor; this() calls another constructor in the same class. Both must be the first statement in a constructor — so you can't use both in the same constructor. Candidates frequently get this wrong in written tests.

Mistake 3: Thinking interfaces can't have state since Java 8. They still can't have instance state. But they can have static fields (which are constants) and default methods with behaviour. Don't conflate the two.

Pro Tip: When an interviewer asks "can we instantiate an abstract class?" the answer is no — but you can create an anonymous subclass inline: new AbstractClass() { ... }. That nuance shows you've actually used the language, not just read about it.

For foundational Java concepts that underpin OOP behavior, our Java Basics guide covers memory model and class loading in detail.

A Realistic 1-Week Prep Plan

Don't try to prep everything at once. Here's what actually works for the Indian interview circuit:

• Day 1–2: Code one real class demonstrating all four pillars — a BankAccount or Employee hierarchy. Write it from scratch, no copy-paste.
• Day 3: Practice the abstract class vs interface tradeoff. Build a Shape hierarchy (Circle, Rectangle) using both approaches; feel the difference.
• Day 4: Study method overriding edge cases — covariant return types (allowed in Java), checked exception narrowing, and the final keyword blocking overrides.
• Day 5: Do 5–6 OOP design questions on LeetCode's design problem set — Design Parking Lot is a classic Infosys/EPAM favourite.
• Day 6: Mock interview with a friend or record yourself answering out loud. Hearing yourself say "polymorphism is when..." is brutal but effective.
• Day 7: Review your weakest pillar only. Rest. Overloading your brain the night before does not help.

Finally, bookmark the Oracle Java OOP Concepts tutorial — it's authoritative, free, and exactly what the Java specification says. If an interviewer challenges your answer, citing the spec wins the argument. For more structured practice on advanced topics, see our Premium interview prep course with company-specific mock rounds.

Frequently Asked Questions

What is the most common Java OOPs interview question asked at TCS and Infosys?

"Explain the four pillars of OOP with examples" is asked in virtually every TCS and Infosys technical round. The key is not to recite definitions but to immediately follow each pillar with a one-line real-world example — like using polymorphism to build a payment gateway that supports UPI, card, and net banking without changing calling code.

Is Java 100% object-oriented?

No, and this is a trick question interviewers love. Java is not purely object-oriented because it has primitive types (int, char, double, etc.) that are not objects. A purely OO language treats everything as an object. You can use wrapper classes (Integer, Double) to box primitives, but the primitives themselves break pure OO.

What is the difference between method overloading and method overriding?

Overloading happens at compile time — same method name, different parameter signatures in the same class. Overriding happens at runtime — a subclass redefines a method from its superclass with the same signature. The common wrong answer is calling overloading "runtime polymorphism"; it's actually compile-time (static) polymorphism.

Can a constructor be inherited in Java?

No. Constructors are not inherited. A subclass can call a parent constructor explicitly using super() as the first line of its own constructor, but it doesn't inherit the constructor itself. This is why every class needs its own constructor (or the compiler generates a default no-arg one if you don't write any).

When should I use an interface over an abstract class in a real project?

Use an interface when you're defining a contract that unrelated classes will implement — like Serializable or Comparable. Use an abstract class when you have shared implementation code (not just a contract) and the subclasses share a clear IS-A relationship. In modern Java 17 code, interfaces with default methods blur this slightly, but the IS-A vs CAN-DO distinction is still the clearest mental model.

How do startups and product companies like EPAM approach OOPs questions differently from TCS?

TCS and Infosys typically test definition recall and basic code output. EPAM and startups ask you to design a small system — "Design a ride-sharing app's fare calculator" — and evaluate whether you naturally reach for polymorphism, abstraction, and encapsulation rather than a single bloated class with if-else chains. SOLID principles and composition-vs-inheritance tradeoffs become critical at this level.

PRIMARY_IMAGE: Hero illustration showing four interlocking gears, each labeled with one OOP pillar (Abstraction, Encapsulation, Inheritance, Polymorphism) in Java-themed blue and orange colors, with a Java coffee cup logo subtly in the background. SECONDARY_IMAGE: Mid-article diagram showing a UML-style class hierarchy — PaymentProcessor abstract class at top, with UpiProcessor and CardProcessor as subclasses, connected by arrows, alongside a side-by-side comparison box of Abstract Class vs Interface key differences.