See exactly what you get for ₹99

== asks “are these the same object?”. equals() asks “is the text the same?”. a and b are the one shared pooled object, so == is true. new String("java") deliberately makes a second object, so a == c is false — but the text still matches, so equals is true.

Output: true false true

Why: a and b point to the same literal in the string pool, so == is true. new String() creates a separate heap object, so a == c is false. equals is overridden in String to compare contents, so it is true. The lesson: == compares references, equals() compares values — the most asked Java fresher question.

Follow-up: "How do you make a == c true?" → call c = c.intern(), which returns the pooled copy of the same content.

Don’t say: "== compares the text" — that assumes two strings with the same characters are always one object, and it fails the moment a String comes from new, user input or a DB.

Encapsulation is locking the data inside the class and letting people touch it only through your methods. The balance is private, so the only way to change it is withdraw() — and withdraw() can refuse. That is the point: one place to put the rule.

Say this: That is encapsulation. The data and the methods that control it are bundled in one class, and direct access is hidden so validation can live in one place. For example, a BankAccount keeps balance private and exposes withdraw(amount), which checks for insufficient funds before changing it; no other class can set the balance to a negative number.

Follow-up: "How is that different from abstraction?" → abstraction hides implementation (interfaces, abstract classes show what, not how); encapsulation hides data. Be ready with one real example for all four pillars: inheritance reuses via extends; polymorphism is one interface, many forms (overloading at compile time, overriding at runtime).

Don’t say: "It's abstraction" or just "data hiding" with no example — interviewers are checking whether you can connect the word to code you would actually write.

Three boxes, one inside the other. The JVM is the small engine that actually runs your program. The JRE is that engine plus Java’s ready-made libraries — enough to run an app. The JDK is the JRE plus tools like javac — enough to write an app. A developer installs the JDK. Someone who only wants to run the finished app needs the JRE.

Say this: The JVM is the engine that actually runs the bytecode. The JRE is the JVM plus the standard libraries — that is everything you need to run a Java program. The JDK is the JRE plus development tools like javac and the debugger — that is what you need to write Java. So on my laptop I install the JDK; a client machine that only runs the app needs just the JRE. The "write once, run anywhere" promise comes from bytecode being platform-independent, while each OS has its own JVM.

Follow-up: "Who compiles the code — the JVM?" → No, javac in the JDK compiles .java to .class bytecode; the JVM interprets and JIT-compiles that bytecode at runtime.

Follow-up: "Is Java platform-independent or is the JVM?" → The bytecode is platform-independent; the JVM itself is platform-specific.

Don’t say: "They are basically the same thing" or "the JDK runs programs and the JVM compiles" — reversing the roles is the most common fresher mistake.

Java starts your program by calling main. Each word is there so the JVM is able to call it: public — you are allowed to call me; static — call me without creating an object first; void — I give nothing back; String[] args — a box holding anything typed after the command.

Say this: public so the JVM, which is outside our class, is allowed to call it. static so the JVM can call it without first creating an object of the class — there is no object yet when the program starts. void because it returns nothing to the JVM. And String[] args receives the command-line arguments.

Follow-up: "Can main be written differently in newer Java?" → Java 21+ has preview features for simpler mains (unnamed classes, instance main), but the classic signature is still the standard one (verify exact version status).

Don’t say: "It's just the convention" — the interviewer wants the reason behind each keyword. Also don't claim static is for speed.

In Java a whole number divided by a whole number gives a whole number. So 7 / 2 is 3 and the .5 is simply thrown away. Make one side a decimal and you get 3.5.

Output: 3 1 3.5

Why: a / b with two ints is integer division, so 3.5 is truncated to 3. % gives the remainder, 1. In (double) a / b the cast applies to a first, making it 7.0, so the division becomes floating-point and gives 3.5.

Follow-up: "What if I write (double)(a / b)?" → 3.0 — the integer division happens first, then the cast. Cast order matters.

Java keeps ready-made Integer objects for the small numbers −128 to 127 and hands out the same one every time. So the two 127s are literally one object; the two 128s are two different objects. == asks “same object?”, equals() asks “same value?”

Output: true false true

Why: Integer caches values from −128 to 127, so x and y point to the same cached object and == is true. 128 is outside the cache, so autoboxing creates two separate objects and == compares references — false. equals compares the value, so it is true.

Follow-up: "So how should wrappers be compared?" → Always with equals(), never ==.

Encapsulation is locking the data inside the class and letting people touch it only through your methods. Abstraction is hiding the messy inside and showing a simple button. Short version: encapsulation hides the data, abstraction hides the working.

Say this: Encapsulation means bundling data together with the methods that operate on it, and restricting direct access to that data — in practice, private fields with public getters and setters. For example a BankAccount keeps balance private and exposes deposit() and withdraw(), so nobody can set a negative balance directly. Abstraction is different: it hides implementation complexity behind a simple interface — you call list.sort() without knowing the algorithm. One line to remember: encapsulation hides data, abstraction hides implementation.

Follow-up: "How do you achieve abstraction in Java?" → Abstract classes and interfaces.

Don’t say: "Encapsulation is hiding implementation behind an interface" — that is the definition of abstraction. The two are confused most often, and interviewers deliberately check for it.

Good answer hits: Local variables have no default · using one uninitialised is a compile error · instance and static fields do get defaults (0 / false / null) · the difference is a favourite trick question.

One-liner: There is no default — the compiler refuses to compile if you read it before assigning; only fields get 0/false/null.

Output: 3345

Why: + is evaluated left to right. 1 + 2 is integer addition = 3. Then 3 + "3" becomes string concatenation "33", and from there every + appends: "334", "3345".

Good answer hits: private methods — not visible to the subclass · final methods — explicitly locked · static methods are hidden, not overridden · a same-named private method in a subclass is a brand-new unrelated method.

One-liner: Private and final methods can't be overridden; static methods can only be hidden.