Java Interview Questions

== compares references (same object or not); .equals() compares character content. Two equal strings can be separate objects, so == may be false while .equals() is true.

String a = new String("java");
String b = new String("java");
System.out.println(a == b);        // false
System.out.println(a.equals(b));   // true

Why it matters: Most Java interviews open here to check you understand reference vs value semantics.

Common mistake: The string pool makes == true for literals, which tricks people into thinking == is a value compare.

Trade-off: Prefer .equals(), or Objects.equals() for null-safety; never rely on == for text.

Follow-up to expect: Why do two equal String literals sometimes compare equal with ==?

Keys are hashed, spread, and masked into a bucket. Collisions chain as a linked list; Java 8 treeifies a long chain into a red-black tree, and the table doubles and rehashes once size crosses capacity x load factor.

// bucket index = (n - 1) & spread(hash)
// chain length > 8  -> treeify (table >= 64)
// size > capacity * 0.75 -> resize x2, rehash

Common mistake: Lookup is O(1) only on average. A poor hashCode that clusters keys degrades it toward O(n).

Trade-off: HashMap is not thread-safe; use ConcurrentHashMap for concurrent access instead of locking the whole map.

Follow-up to expect: What happens if every key has the same hashCode?

Checked exceptions force callers to handle recoverable, expected conditions; RuntimeExceptions are unchecked and are the modern default in Spring/service code because they compose with lambdas and keep APIs clean.

Why it matters: Interviewers use it to see whether you design APIs or just sprinkle catches.

Common mistake: More checked exceptions means safer code. They leak low-level failures through every layer.

Trade-off: Wrap third-party checked exceptions at the boundary into a domain RuntimeException with context.

Follow-up to expect: Why does Spring translate SQLException into DataAccessException?

final fixes a variable reference or blocks overriding; finally always runs (except on System.exit) and is mostly replaced by try-with-resources; finalize() is deprecated for removal and must not be used for cleanup.

final List<String> xs = new ArrayList<>();
xs.add("ok");   // allowed: reference fixed, not contents
// xs = new ArrayList<>();  // compile error

Common mistake: final makes an object immutable. It fixes the reference, not the object state.

Trade-off: Use try-with-resources for cleanup and java.lang.ref.Cleaner for native resources.

Follow-up to expect: If final fixes the reference, why can you still add to a final List?

In practice ArrayList wins almost everywhere: it is a contiguous, cache-friendly array with amortized O(1) append. LinkedList pays per-node allocation and pointer-chasing, and even its "O(1)" insert requires walking to the node first.

Common mistake: LinkedList is faster for inserts/removes. Reaching position i is O(n), so add(i, x) is not faster.

Trade-off: For stack/queue semantics use ArrayDeque, not LinkedList or the legacy Stack.

Follow-up to expect: When does LinkedList structure genuinely help?

Collections.synchronizedMap locks the entire map. ConcurrentHashMap reads are lock-free (volatile values) and writes lock only the affected bin, using CAS when a bucket is absent, so reads stay concurrent and writes parallelize across buckets.

Why it matters: Concurrency depth separates mid-level from senior candidates.

Common mistake: size() and iteration are weakly consistent. You can read a stale count, which is usually fine but is not a snapshot.

Trade-off: It does not make compound actions atomic; use compute/merge/computeIfAbsent for check-then-act.

Follow-up to expect: How would you build an atomic counter with no lost updates?

HashMap/HashSet bucket by hashCode() and only then confirm with equals(). If equal objects return different hashes, the lookup can land in the wrong bucket, so get()/contains() returns false even though equals() matches.

Map<Point,String> m = new HashMap<>();
m.put(new Point(1,2), "p");
m.get(new Point(1,2));  // null unless hashCode is overridden too

Common mistake: equals is enough because it finds the match. But equals() never runs if the hash points elsewhere.

Trade-off: Records generate both methods for free; otherwise derive both from the same immutable fields.

Follow-up to expect: Why must hashCode stay stable while an object is a map key?

orElse’s argument is evaluated eagerly even when the value exists; orElseGet runs the supplier only when empty. The distinction scales into the whole Optional discipline: map/flatMap/filter chains that keep absence composable, and the anti-patterns (get() without isPresent, Optional fields, Optional parameters, Optional<List>).

order.find(id)
  .map(Order::total)
  .orElseGet(() -> priceService.recompute(id)); // only runs when empty

Why it matters: It is the cheapest filter question for “does this person actually use Optional or just recognize the word.”

Common mistake: That orElse is just a shorter spelling. A lazily-expensive default (a DB call, a log line) fires on every present-value path.

Trade-off: Optional is a return-type tool; fields and parameters stay nullable-friendly or overloaded. Saying the boundary out loud is the senior part of the answer.

Follow-up to expect: Why not Optional<List<T>>: and what do you return instead?

Generics exist at compile time and erase to raw types in bytecode: no new T(), no T.class, no instanceof List<String>, no overloads differing only in type arguments, no generic arrays. Workarounds are Class<T> tokens and captured supertypes (Jackson TypeReference).

Why it matters: It tests whether generics are understood as a type-system decision or a syntax feature; the follow-up ladder (why not reified, arrays vs lists) is all mechanism.

Common mistake: That erasure is a bug rather than the compatibility bargain it was. And that reified generics are free.

Trade-off: Arrays are covariant and runtime-checked (ArrayStoreException); generics are invariant and compile-time checked. Collections beat arrays exactly because of this.

Follow-up to expect: Explain PECS: when ? extends and when ? super?

Records generate the canonical constructor, accessors, equals/hashCode/toString from components. Immutable data carriers with real identity-by-value. Immutability is shallow: a record holding a List still has a mutable list unless the compact constructor does List.copyOf.

Why it matters: Modern-Java fluency signal: it also opens the door (interviewers steer there) to compact-constructor validation and pattern matching in switch.

Common mistake: Records as JPA entities (they are not. No proxying/no-arg story) or as enums’ successor; and that final fields alone mean deep immutability.

Trade-off: The right shape is DTO/value object/map key; anything needing inheritance, mutation, or lazy build stays a class or builder.

Follow-up to expect: Where do you put validation in a record, and what does the compact constructor let you normalize?