What are the four pillars (or four main concepts) of OOP?

The four pillars of object-oriented programming are: (1) Encapsulation - bundling data (fields) and the methods that operate on that data into a single unit (class) and restricting direct access to some of the object's components, typically via access modifiers (private, protected, public) and getter/setter methods. This hides the internal state and protects invariants. (2) Abstraction - exposing only essential features of an object while hiding the complex implementation details; achieved in Java via abstract classes and interfaces; lets you work with the WHAT without knowing the HOW. (3) Inheritance - a mechanism by which a new class (subclass/child) is created from an existing class (superclass/parent), inheriting its attributes and methods; enables code reuse and establishes an IS-A relationship (e.g., Dog IS-A Animal). (4) Polymorphism - the ability of one interface (a method call or object reference) to work with different underlying forms; in Java this comes in two flavors: compile-time (overloading - same method name with different parameter lists) and runtime (overriding - subclass provides specific implementation of a method already declared in its superclass, resolved via dynamic dispatch). Together these four pillars enable modular, maintainable, and reusable code at scale.

What is the difference between an abstract class and an interface in Java?

An abstract class is a class declared with the abstract keyword that can have abstract methods (no body), concrete methods (with body), instance variables, constructors, and static methods. It supports single inheritance (a class can extend only one abstract class). An interface is a contract that declares method signatures (all public and abstract by default, except static and default methods since Java 8); all variables are public static final (constants). A class can implement multiple interfaces (multiple inheritance of type). When to use each: use an abstract class when you want to share code among closely related classes (template method pattern, common state, common behavior with partial specialization); use an interface when you want to define a contract that unrelated classes can implement (capability marker like Comparable, Runnable, or service interface). Since Java 8, interfaces can have default methods (with body) and since Java 9, private methods; this has made interfaces more flexible and reduced the gap with abstract classes. Modern Java design tends to favor interfaces for type contracts and abstract classes only when code reuse or shared state is genuinely needed.

What is inheritance in Java and what are its types?

Inheritance is a mechanism by which a new class (subclass, child class, derived class) is created from an existing class (superclass, parent class, base class), inheriting its fields and methods and adding its own. In Java, inheritance is achieved with the extends keyword (for classes) and implements keyword (for interfaces). Types of inheritance in Java: (1) Single inheritance - a class extends exactly one superclass (Java does NOT support multiple inheritance of classes because of the diamond problem; a class can implement multiple interfaces instead). (2) Multilevel inheritance - a class extends another class which itself extends another (A extends B extends C). (3) Hierarchical inheritance - multiple classes extend the same superclass (B and C both extend A). (4) Multiple inheritance (of type) - a class implements multiple interfaces (achieved via interfaces, not classes). (5) Hybrid inheritance - a combination of two or more of the above. The IS-A relationship is established: Dog IS-A Animal, Car IS-A Vehicle. Use inheritance only when there is a true IS-A relationship; prefer composition (HAS-A) when the relationship is not strictly hierarchical - the design principle 'favor composition over inheritance' is widely applied.

What is polymorphism in Java and what are its types?

Polymorphism is the ability of one interface (a method call or object reference) to work with different underlying forms. In Java, polymorphism comes in two main flavors: (1) Compile-time polymorphism (also called static binding or early binding) - achieved through method overloading (multiple methods with the same name but different parameter lists: number, type, or order of parameters) and operator overloading (limited in Java; + works for String concatenation and numeric addition, but custom operator overloading is not allowed). The compiler resolves which method to call based on the reference types at compile time. (2) Runtime polymorphism (also called dynamic binding or late binding) - achieved through method overriding (a subclass provides a specific implementation of a method already declared in its superclass, declared with the same name, return type, and parameters) and resolved at runtime via dynamic dispatch based on the actual object type, not the reference type. The classic example: Animal a = new Dog(); a.makeSound(); - calls Dog's makeSound() at runtime even though the reference type is Animal. The JVM uses a vtable (method table) per class to resolve overridden methods. Polymorphism is what enables extensible, pluggable designs (Strategy pattern, Observer pattern, dependency injection).

What is encapsulation in Java and why is it important?

Encapsulation is the bundling of data (fields/instance variables) and the methods that operate on that data into a single unit (a class), combined with access control to restrict direct external access to some of the object's components. In Java, encapsulation is achieved through: (1) access modifiers (private, default/package-private, protected, public) to control visibility; (2) getter and setter methods (often with validation, lazy initialization, or change notification); (3) immutability (final fields, no setters, defensive copies in constructors). Why encapsulation matters: (1) Data hiding - internal state is protected from unintended external modification, preserving invariants (e.g., a bank account balance cannot go negative because the setter enforces that rule). (2) Maintainability - the internal representation can change without breaking external callers, as long as the public methods preserve their contract. (3) Reusability - well-encapsulated classes are easier to compose and test. (4) Security - sensitive data is hidden from direct external access. (5) Reduced coupling - callers depend on the public interface, not the internal implementation. Best practice: fields should be private; expose only what is necessary through public methods; mark classes final when they should not be subclassed.

What is the diamond problem and how does Java resolve it?

The diamond problem occurs in languages that allow multiple inheritance of classes when a class inherits from two classes that both inherit from a common superclass, creating an ambiguity about which superclass method to use. For example: Class D extends B and C; both B and C extend A and override a method m(); D inherits m() from both B and C - which version is called? C++ allows this and requires explicit resolution. Java avoids the diamond problem entirely by NOT allowing multiple inheritance of classes - a class can extend only one superclass. Java does allow multiple inheritance of TYPE through interfaces - a class can implement multiple interfaces, and since Java 8 an interface can have default methods (methods with a body), the diamond problem can theoretically occur there too. Java resolves it as follows: (1) If a class inherits a default method from multiple interfaces, the compiler requires the class to explicitly override the method (this is a compile error otherwise). (2) If two interfaces have default methods and one extends the other, the more specific interface wins (interface B extends A; class implements B; default method from B is used). (3) If none of the above resolves it, the class must override and explicitly call one of the parent implementations using InterfaceName.super.method().

What is method overloading vs method overriding in Java?

Method overloading (compile-time polymorphism) is defining multiple methods with the same name in the same class (or in a subclass) but with different parameter lists (different number, type, or order of parameters). Overloading does NOT require the return type to differ (return type alone is not enough to disambiguate - Java would not know which to call). The compiler resolves which method to call based on the argument types at compile time. Examples: print(String s), print(int i), print(double d) - all named print but each handles different types. Method overriding (runtime polymorphism) is providing a different implementation of a method in a subclass that is already declared in the superclass. The overriding method must have the same name, same parameter list (otherwise it is overloading, not overriding), and a compatible return type (covariant return types are allowed since Java 5: an overriding method can return a subtype of what the superclass method returned). Access modifiers can be widened (private to public is OK; public to private is not). The @Override annotation is optional but strongly recommended - it tells the compiler to verify the override is correct. Override resolution happens at runtime via dynamic dispatch based on the actual object type.

What are the SOLID principles of object-oriented design?

SOLID is an acronym for five object-oriented design principles articulated by Robert C. Martin (Uncle Bob) that help create maintainable, extensible, and testable software. (1) Single Responsibility Principle (SRP) - a class should have only one reason to change; one class, one job. (2) Open/Closed Principle (OCP) - classes should be open for extension but closed for modification; add new behavior by adding new code, not by changing existing tested code. (3) Liskov Substitution Principle (LSP) - objects of a superclass should be replaceable with objects of a subclass without breaking the application; the subclass must honor the contract of the superclass (preconditions cannot be strengthened, postconditions cannot be weakened, invariants must be preserved). The classic violation is a Square extending Rectangle where Square.setSize(width, height) violates Rectangle's expected behavior. (4) Interface Segregation Principle (ISP) - clients should not be forced to depend on interfaces they do not use; prefer many small, focused interfaces over one large fat interface. (5) Dependency Inversion Principle (DIP) - high-level modules should not depend on low-level modules; both should depend on abstractions; abstractions should not depend on details. In Java this is achieved through dependency injection (constructor injection preferred). SOLID principles are heavily tested in Cognizant GenC Next, Infosys Power Programmer, and product company system design interviews.

OOPs Interview Questions in Java 2026: Top 40

Quick Answer: OOPs Interview Questions for Freshers 2026

The top 40 OOPs interview questions asked in Java fresher interviews at TCS, Infosys, Accenture, Cognizant in 2026 cover six clusters: the four pillars (encapsulation, abstraction, inheritance, polymorphism), abstract class vs interface (when to use each), inheritance types and the diamond problem, polymorphism (compile-time vs runtime), method overloading vs overriding, and SOLID design principles. Most fresher interviews include 5-8 OOPs MCQs plus 1-2 live coding questions (design a class hierarchy, implement an interface, override a method correctly). Infosys InfyTQ and Accenture AASS add a system-design-flavored OOPs question (design a library system, design a parking lot). For the full Q&A collection with 25 curated Java questions (OOPs is a major section), see the TutorsBot Java Interview Questions hub.

Why OOPs Matters So Much in Fresher Interviews

OOPs is the single highest-weight topic in service-company fresher Java interviews because: (1) every Java program is built on OOP, so the language forces you to internalize the concepts early; (2) OOPs questions test design thinking, not just syntax; (3) the same concepts extend directly to Spring/Spring Boot, microservices, and design patterns - so OOPs mastery is a leading indicator of mid-level readiness; (4) every other cluster (Collections, Exception Handling, Multithreading) is built on OOPs foundations; and (5) the four pillars are testable in multiple formats - MCQ, live coding, scenario question, and design discussion. TCS NQT has 2-3 OOPs MCQs; Wipro NLTH has 1-2; Infosys InfyTQ has 3-4 plus a live coding question; Cognizant GenC has 4-6 plus a system design discussion.

The 6 Topic Clusters Asked Most Often

Cluster 1: The Four Pillars of OOP

The mandatory baseline. Expect at least one question per pillar in most interviews: (1) What is encapsulation (bundling data and methods, restricting direct access via access modifiers, protecting invariants)? (2) What is abstraction (hiding implementation details, exposing only essential features; achieved through abstract classes and interfaces)? (3) What is inheritance (a new class inherits from an existing class, reusing code and establishing IS-A)? (4) What is polymorphism (one interface, multiple forms; compile-time via overloading and runtime via overriding)? The classic four-pillars question with one-paragraph answer for each is a near-universal fresher question. Follow-up: can you give an example of each from a real Java program? Common answers: encapsulation (a BankAccount class with private balance and public deposit/withdraw methods that enforce balance checks); abstraction (a List interface hides the ArrayList vs LinkedList implementation); inheritance (a SavingsAccount IS-A Account); polymorphism (Animal a = new Dog(); a.makeSound() calls Dog's makeSound() at runtime).

Cluster 2: Abstract Class vs Interface

The most-tested single OOPs question. The complete answer covers state (abstract classes can have instance variables and constructors; interfaces have only public static final constants), method types (abstract classes can have any mix of abstract, concrete, static, and (since Java 8) default methods; interfaces have only abstract methods plus (since Java 8) default and static methods plus (since Java 9) private methods), inheritance (single for abstract class via extends; multiple for interface via implements), use cases (abstract classes for code reuse among closely related classes - template method, common state; interfaces for type contracts that unrelated classes implement - capability markers, service interfaces), and historical context (before Java 8, interfaces had no methods with bodies and the choice was clearer; after Java 8 default methods and Java 9 private methods, the choice is more nuanced). Modern best practice: prefer interfaces for type contracts, use abstract classes only when you need shared state or significant code reuse. Common follow-up: can a class implement two interfaces that have a default method with the same signature (no - must override; or use InterfaceName.super.method() to disambiguate)?

Cluster 3: Inheritance Types and the Diamond Problem

Asked by Infosys InfyTQ and Cognizant GenC. Questions: What are the types of inheritance (single, multilevel, hierarchical, multiple of type, hybrid)? Does Java support multiple inheritance of classes (no - only single class inheritance via extends, but multiple interface inheritance via implements)? What is the diamond problem (a class inherits from two classes that both inherit from a common superclass; ambiguity about which superclass method to use; C++ allows it, Java does not for classes but does for interfaces since Java 8 default methods)? How does Java resolve the diamond problem for interfaces (compiler error if class inherits conflicting defaults; class must override; InterfaceName.super.method() to call one of the parents)? What is the Liskov Substitution Principle (objects of a superclass should be replaceable with objects of a subclass without breaking the application; the classic Square-Rectangle violation)? Why prefer composition over inheritance (composition = HAS-A, inheritance = IS-A; composition is more flexible and less coupled; the design heuristic 'favor composition over inheritance')? Common live coding question: design a class hierarchy for a library management system (Book, Author, Member, Library, Loan - identify IS-A vs HAS-A relationships).

Cluster 4: Polymorphism (Compile-Time vs Runtime)

Asked at Cognizant GenC Next and product company interviews. Questions: What is compile-time polymorphism (static binding, method overloading - same method name with different parameter lists, resolved at compile time by argument types)? What is runtime polymorphism (dynamic binding, method overriding - subclass provides specific implementation, resolved at runtime by actual object type via dynamic dispatch)? What is the vtable / method table (the JVM maintains a vtable per class; method calls are resolved by looking up the table; this enables dynamic dispatch)? What is covariant return type (an overriding method can return a subtype of what the superclass method returned since Java 5; e.g., superclass Cloneable.clone() returns Object, override can return your specific type)? What is the difference between early binding and late binding (early = at compile time, late = at runtime; virtual method invocation in Java is late binding)? Practical question: write code demonstrating both compile-time and runtime polymorphism, then explain what is printed and why.

Cluster 5: Method Overloading vs Overriding

Asked at every level. Questions: What is overloading (same method name, different parameter lists in same class or subclass; resolved at compile time; return type alone is not sufficient to disambiguate)? What is overriding (subclass provides specific implementation of superclass method; same name, same parameter list, compatible return type; @Override annotation recommended)? Can you override a static method (no - static methods are hidden, not overridden; the superclass static method is called regardless of actual object type)? Can you override a private method (no - private methods are not visible to subclasses; what looks like overriding is actually a new method)? What is method hiding (when a subclass defines a static method with the same signature as a superclass static method, the subclass version hides the superclass version; resolved at compile time by reference type, not actual object type)? Can constructors be overridden (no - constructors are not inherited; subclasses define their own constructors and must call super() if needed)? Common scenario question: what does the following code print - involves static vs instance method calls through a reference variable.

Cluster 6: SOLID Design Principles

Asked heavily at Cognizant GenC Next, Infosys Power Programmer, and product companies. (1) Single Responsibility Principle (SRP) - a class should have only one reason to change. (2) Open/Closed Principle (OCP) - classes should be open for extension but closed for modification; add new behavior via inheritance or composition, not by changing existing tested code. (3) Liskov Substitution Principle (LSP) - objects of a superclass should be replaceable with objects of a subclass without breaking the application; the subclass must honor the superclass contract. (4) Interface Segregation Principle (ISP) - clients should not be forced to depend on interfaces they do not use; prefer many small focused interfaces over one fat interface (the I vs IUser-vs-IUserReader-IUserWriter distinction). (5) Dependency Inversion Principle (DIP) - high-level modules should not depend on low-level modules; both should depend on abstractions; in Java achieved through dependency injection. Practical question: refactor the given code to follow SOLID principles; explain which principle was violated and how your refactor fixes it.

Common Fresher Pitfalls to Avoid

Confusing overloading and overriding: Overloading is same method name with different parameter lists in the SAME class or subclass; overriding is the same method signature in SUBCLASS providing new implementation
Forgetting @Override annotation: Without @Override, a typo in the method signature creates an overload, not an override - the superclass method is still called, leading to confusing bugs
Treating interface methods as default behavior: Before Java 8, all interface methods were abstract; if you add a method to an interface and don't update all implementations, they break to compile error
Inheritance abuse: Using inheritance for code reuse when composition would be more appropriate (e.g., a Car HAS-A Engine, not IS-A Engine)
Public fields instead of getters/setters: Breaks encapsulation; allows external code to modify internal state without validation, breaking invariants
Mutable objects in fields: A field of type List or Date should be defensively copied in the constructor and getter to prevent external modification of internal state
Tight coupling: Class A directly instantiating Class B (instead of depending on an interface) makes testing and reuse hard; prefer dependency injection
God classes: A class with hundreds of methods and dozens of fields; violates SRP; split by responsibility

How to Prepare in 30 Days

The strongest 30-day fresher OOPs interview preparation plan:

Week 1 - Foundations: Work through the Oracle Java OOP tutorial (docs.oracle.com/javase/tutorial/java/concepts/), read Head First Design Patterns (the most beginner-friendly patterns book), practice explaining the four pillars with concrete examples
Week 2 - Live coding: Build 5-6 small class hierarchies (BankAccount, Library, Shape, Employee, Vehicle), implement each in Java with proper encapsulation, inheritance, polymorphism, abstract classes vs interfaces
Week 3 - SOLID principles: Refactor 3-5 of your existing small projects to follow SOLID; study the strategy pattern, observer pattern, factory pattern, repository pattern
Week 4 - Mock interviews: Take 2-3 timed mock tests, review the Java Interview Questions hub OOPs section for the full Q&A collection, refine your answers to the top 10 scenario questions

For a structured, project-based path from OOPs fundamentals to backend developer roles, the TutorsBot Full Stack Development training covers OOP, design patterns, Spring Boot, and API development end-to-end.

Frequently Asked Questions

How many OOPs questions are asked in TCS NQT 2026?

TCS NQT 2026 typically includes 2-4 OOPs questions in the coding/technical section for Digital and Prime profiles. For Ninja profiles, the count is lower (1-2 MCQs). TCS Digital and TCS Prime add a live coding question asking you to design a class hierarchy.

Is OOPs enough to get placed in TCS/Wipro/Infosys?

OOPs alone is not enough - companies test a combination of OOPs (Java or C++), DSA (50-100 problems), SQL, and aptitude/reasoning. Strong OOPs mastery combined with Java collections, exception handling, and Spring Boot basics covers 70%+ of service-company fresher Java interview questions. Cognizant GenC Next and Infosys Power Programmer require deeper OOPs (SOLID, design patterns) than TCS NQT or Wipro NLTH.

What is the salary for OOPs-skilled freshers at these companies in 2026?

Salary bands for freshers with strong OOPs and Java skills in 2026: TCS Ninja ₹3.36 LPA, TCS Digital ₹7-8 LPA, TCS Prime ₹9-11 LPA. Wipro ₹3.5-5 LPA. Infosys (InfyTQ Power Programmer) ₹6.5-9.5 LPA, regular InfyTQ ₹3.6 LPA. Cognizant GenC ₹4.5-6 LPA, GenC Next ₹7-12 LPA. Accenture AASE ₹4.5-6 LPA, AASS ₹6-9 LPA. Capgemini ₹4-6 LPA. HCL ₹3.5-5.5 LPA. Product companies (Flipkart, Razorpay, PhonePe) pay 2-3x these bands for OOPs-fluent candidates who can also do DSA, system design, and Spring Boot.

What is the best resource for OOPs interview preparation?

The strongest resources are: the Oracle Java OOP tutorial (docs.oracle.com/javase/tutorial/java/concepts/ - covers everything precisely), Head First Design Patterns (the most beginner-friendly patterns book - uses Java examples), Effective Java by Joshua Bloch (the classic Java best-practices book - chapters on classes and interfaces, generics, enums, lambdas, streams, methods are essential), Refactoring Guru (refactoring.guru/design-patterns - visual explanations of all GoF patterns with code), Baeldung OOP articles (in-depth articles on specific Java topics), and the TutorsBot Java Interview Questions hub for curated 25 questions covering OOPs deeply. Combine the official documentation for correctness, Head First Design Patterns for visual understanding, Effective Java for industry best practices, and a curated interview question set for company-specific patterns.

Can I learn OOPs without learning a programming language first?

You can learn OOPs concepts (encapsulation, abstraction, inheritance, polymorphism) in any language - even pseudo-code. But to interview well, you need to express the concepts in a real language (Java, C++, Python, C#) with working code. The interview pattern is: explain the concept, then write code that demonstrates it. Java is the most common service-company language; Python is preferred for fresher data/ML roles; C++ is the language for embedded and system programming roles. Pick one language and learn OOPs deeply in it; the concepts transfer to other languages but the syntax does not.

Resources and Next Steps

The authoritative sources listed (Oracle Java OOP tutorial, Baeldung, GeeksforGeeks, Refactoring Guru, Effective Java) are the canonical references for OOPs fundamentals and design principles. For the full Java interview questions collection with 25 curated questions covering OOPs deeply plus Collections, Multithreading, Java 8, and Spring Boot, see the TutorsBot Java Interview Questions hub. For related interview prep, see our Java interview questions, Python interview questions, and DBMS interview questions guides.