Core Java interview questions — the follow-ups that catch people who only memorized syntax

Core Java shows up in almost every fresher and junior technical round in India, which means it's also one of the most rehearsed subjects walking in the door. Interviewers know this, so the actual questions rarely stop at the definition — they push one layer deeper, into the reason the language behaves the way it does.

== vs equals()

What gets recited: == compares references, equals() compares values.

The follow-up: "Two String objects created with new String("abc") — does == return true or false, and why is that different from two string literals?"

This is the question that separates memorized syntax from understanding the string pool. String literals are interned — the JVM reuses the same object for identical literals, so == can return true. new String(...) forces a new object on the heap regardless of the pool, so == returns false even though the value is identical. Reciting "use equals() for value comparison" without knowing why == sometimes accidentally works is a fresher tell.

Overloading vs overriding

What gets recited: overloading is same method name, different parameters, resolved at compile time; overriding is a subclass redefining a parent method, resolved at runtime.

The follow-up: "If a subclass overloads instead of overrides a parent method — same name, different signature — what actually happens when you call it through a parent reference?"

The real answer requires understanding static vs dynamic binding: the compiler picks the overload based on the reference type at compile time, so a parent-typed reference calling an overloaded method uses the parent's version, not the subclass's — which surprises people who assume all subclass behavior wins automatically.

Exception handling

What gets recited: try-catch-finally, checked vs unchecked exceptions.

The follow-up: "Why does Java force you to handle or declare checked exceptions, but not unchecked ones?"

The definition-only answer stops at the vocabulary. The real answer is a design philosophy: checked exceptions are for conditions a well-written program should anticipate and recover from (a file not existing), while unchecked exceptions represent programming errors (a null pointer, an out-of-bounds index) that forcing a catch block wouldn't meaningfully fix — you'd just be hiding a bug.

Collections

What gets recited: ArrayList vs LinkedList, HashMap vs TreeMap, one sentence each.

The follow-up: "You're inserting a million elements at the front of a list one at a time. Which implementation do you pick and why?"

This forces the trade-off out of hiding: ArrayList shifts every subsequent element on each front-insert, making it O(n) per insert; LinkedList does it in O(1) because it's just adjusting pointers. Candidates who only memorized "ArrayList is fast for reads, LinkedList is fast for inserts" as a flat fact struggle to apply it the moment the scenario isn't phrased exactly like the flashcard.

HashMap internals

What gets recited: HashMap stores key-value pairs using a hash function to determine the bucket.

The follow-up: "Two different keys produce the same hash code. What happens, and what would break if equals() weren't implemented correctly for your key's class?"

This is a favorite at the middle level specifically because it exposes whether someone has only used HashMap or actually understands it. The answer: a collision puts both entries in the same bucket, resolved via a linked list or tree of entries; if equals() is broken or missing on a custom key class, get() can silently fail to find a value that's actually stored there, because the map can't confirm two keys with the same hash are actually equal.

Why the follow-up is always the real question

Every one of the definitions above is in the first page of any Java interview prep guide, which is exactly why interviewers don't stop there — a definition tells them what you've read, not what you understand. The follow-up asks you to predict a behavior you haven't necessarily memorized, which is a much harder thing to fake.

---

Prepair asks Core Java questions scoped to your level, fresher through experienced, and the follow-ups work the same way — a real reason to explain, not just a term to define. Try a free interview — 3 a month, no signup required to start.