Java interview questions — practice with real interview prompts

String literals are interned into the string constant pool, so a and b reference the exact same pooled object and a == b is true. new String("hi") is explicitly told to allocate a fresh object on the heap, so c is a different reference and a == c is false even though the characters match. == compares references, not contents — .equals() is what compares the actual characters and would return true for all three. The trap is that == appears to work for literals because of interning, then silently breaks for strings built at runtime (from input, concatenation, or new), which is why you should always use .equals() to compare string values.

Implementing java.lang.Comparable<T> and overriding its single method compareTo(T o) establishes the natural ordering for a class. Collections.sort (or List.sort) can then sort a list of those objects without needing an external Comparator.

Try-with-resources (try (var r = ...) { ... }) automatically calls close() on each resource when the block exits — normally or via an exception — as long as the resource's type implements AutoCloseable (or Closeable, which extends it and narrows the thrown type to IOException). Resources close in reverse order of declaration. A subtle but important detail: if the body throws and close() also throws, the body's exception is the one propagated and the close() exception is attached as a suppressed exception (retrievable via Throwable.getSuppressed()) — the opposite of the old try/finally idiom, where a throwing finally would mask the original error.

ArrayList stores null references without restriction because it indexes by position. HashSet allows a single null element (backed by a HashMap that allows one null key). Hashtable throws NullPointerException on any null key or value, as does ConcurrentHashMap, which disallows null keys and values to avoid ambiguity in concurrent reads.

Comparable defines the natural ordering inside the class itself. The compareTo return sign maps to before/equal/after and is the single method of the java.lang.Comparable interface.

Comparable embeds the natural ordering inside the class (one method, one order). Comparator is external and can be created in multiple variants to sort the same objects in different ways, even for third-party classes you cannot edit.

The equals method considers only id and name when determining equality (line 13), but the hashCode method on line 18 also includes email in the computation via Objects.hash(id, name, email). The equals/hashCode contract requires that two objects for which equals returns true must have the same hash code. Two Employee objects with the same id and name but different email values would be considered equal yet produce different hash codes, breaking the contract. The fix is to remove email from the hashCode computation: return Objects.hash(id, name);.

After map.put(k, "value") stores the entry, k.setName("beta") changes the name field, which is the sole input to hashCode. The entry was placed in the bucket corresponding to the hash of "alpha", but map.get(k) now computes the hash of "beta" and looks in a different bucket, so it returns null even though the exact same object reference is in the map. The equals and hashCode implementations themselves are internally consistent; the bug is mutating a HashMap key after insertion. Option (b) is not a bug — instanceof is a valid pattern here. Option (c) is incorrect because hashCode correctly uses the same field as equals. Option (d) is irrelevant to the failure.

The equals/hashCode contract requires that equal objects return equal hash codes. HashMap first uses hashCode() to pick a bucket, then equals() to find the entry within it. The default Object.hashCode() is identity-based, so two distinct-but-equals objects almost always produce different hash codes, route to different buckets, and a get() with an equal-but-not-same key returns null — the entry is effectively lost. It is not a compile error: the compiler never forces you to override both, which is exactly why this bug is so common. Always override hashCode() whenever you override equals() (and prefer the same fields in both).

Stream operations split into intermediate (lazy, return a new Stream) and terminal (eager, produce a result or side effect and consume the stream). collect, forEach, and count are terminal — they trigger the pipeline and you cannot reuse the stream afterward. map and filter are intermediate: they only describe a transformation and do nothing until a terminal op pulls elements through. The practical consequence of laziness is that a pipeline of map/filter with no terminal op runs zero times — a common 'my forEach printed nothing' confusion — and that intermediate ops are fused and applied element-by-element rather than as separate passes. Other terminal ops include reduce, findFirst, anyMatch, toArray, and min/max.

Java is always pass-by-value, with no exceptions. For object types, the value that is copied is the reference itself, not the object — so the parameter and the caller's variable initially point at the same object. Mutating that shared object's state (e.g. list.add(x) or obj.setName(...)) is visible to the caller, which is why people mistakenly call it 'pass-by-reference'. But reassigning the parameter (obj = new Thing()) only rebinds the local copy of the reference; the caller's variable still points at the original object. The tell that it is pass-by-value: a method cannot swap two of the caller's variables or make the caller's variable point somewhere new.

This is a switch expression with arrow labels. day is 6, which matches case 6, 7 ->, so kind is assigned "weekend" and the program prints weekend. Arrow-form switch has no fall-through — each label runs only its own branch and yields a value, unlike the old colon-and-break statement form where a missing break would fall through to the next case. A multi-value label (case 6, 7) matches either constant. Switch expressions must be exhaustive (hence default), and the whole switch evaluates to a single value you can assign. The 'weekendunknown' option is the fall-through answer you'd fear with colon syntax and no break — but arrow labels never fall through.

Checked exceptions extend Exception (excluding RuntimeException) and the compiler forces you to catch or declare them with throws; they model recoverable external conditions like IOException. Unchecked exceptions extend RuntimeException (plus the Error family) and carry no compiler obligation; they model programming bugs like NullPointerException. The whole hierarchy descends from Throwable → Exception/Error. A strong answer names the RuntimeException boundary and the compiler's role; this informs API design — overusing checked exceptions leads to noisy throws chains and swallowed exceptions.

Interfaces define contracts and support multiple inheritance of type; abstract classes share state, constructors, and partial implementation within a single-inheritance hierarchy. Default methods (Java 8+) let interfaces ship concrete behavior, so the 'interfaces are only signatures' distinction is outdated — but interfaces still can't hold instance fields or constructors, which remains the deciding factor. In modern design, prefer interfaces for flexibility (a type can implement many) and reach for an abstract class only when shared mutable state or constructor logic genuinely belongs in the hierarchy.

Class loading follows a fixed sequence: Loading reads the bytecode and produces the Class object; Linking then runs as Verification (bytecode safety checks), Preparation (static fields get memory and default zero values, NOT their declared values yet), and Resolution (constant-pool symbolic references become direct references); finally Initialization runs static initializer blocks and assigns static fields their actual values. The key distinction interviewers probe is Preparation vs Initialization — a static int x = 5 is set to 0 in Preparation and only becomes 5 in Initialization, which is why static state is observable as its zero value during early bootstrapping. Initialization is lazy: it happens on first active use (instantiation, a static access, etc.), not at JVM startup.

a is true: LinkedHashMap uses a doubly-linked list running through its entries, preserving insertion order by default. The constructor LinkedHashMap(int, float, boolean) with accessOrder=true switches it to access-order (LRU) mode.

b is false: CopyOnWriteArrayList creates a snapshot of the underlying array at iterator-creation time. Its iterator never throws ConcurrentModificationException — it simply reflects the list's state when the iterator was created, even if other threads modify the list concurrently.

c is true: EnumSet is an abstract class whose concrete subclasses (RegularEnumSet for ≤64 elements, JumboEnumSet otherwise) store elements as bit fields in a long[]. Like most non-concurrent collections in java.util, it is not thread-safe.

d is true: TreeSet is a NavigableSet backed by a TreeMap. It relies on natural ordering (elements must implement Comparable) or an explicit Comparator provided via a constructor. If neither is available and elements are not mutually comparable, operations will throw ClassCastException at runtime.

e is false: PriorityQueue is a binary heap. It guarantees that peek()/poll() return the least element (per the ordering), but its Iterator traverses the underlying array in arbitrary heap order — not sorted order.

Correct answers: a, c, d.

Generics are implemented by erasure: type arguments exist only at compile time and are erased to their bounds (or Object) in the bytecode, so the runtime has no List<String> type to check against. That makes instanceof List<String> a compile error, and only the reifiable unbounded wildcard form instanceof List<?> is permitted. Erasure also forbids new T[10] (the runtime can't know T's reified type) and new ArrayList<String>[5] (generic array creation), because arrays are covariant and reified while generics are not — allowing them would let a String[]-shaped store silently accept the wrong element type and defeat the type system. The usual workaround for generic arrays is an Object[] cast or, better, a List<T>.

Autoboxing an int into an Integer goes through Integer.valueOf, which caches boxed values in the range -128 to 127. So a and b (both 100) reference the same cached object and a == b is true, while c and d (both 200) are outside the cache, get separate Integer objects, and c == d is false because == compares references for objects. The fix is to compare wrapper values with .equals() or .intValue(), never ==. This is a notorious trap because small test values (which fall in the cache) make == appear to work, then the same code silently breaks in production once the numbers grow past 127.

orElse(expensive()) takes a value argument, so expensive() is evaluated eagerly — before orElse runs and regardless of whether the Optional is present. It prints computing and returns "fallback", but because the Optional actually holds "value", that fallback is discarded and r is "value". So the output is computing then value. The trap: the side effect (and any cost) of the default happens even though it's never used. Use orElseGet(Main::expensive) to defer the computation behind a Supplier so it runs only when the Optional is empty. Choosing orElse over orElseGet for an expensive or side-effecting default is a real performance and correctness bug.

Each individual get and put on a ConcurrentHashMap is atomic, but the sequence get → check → put is not. Two threads can both read current = 5, both compute 6, and both put(key, 6) — so one increment is lost. The map being concurrent only protects single operations, never a compound read-modify-write you compose yourself. The fix is an atomic combinator the map runs under its own per-bin lock: counts.merge(key, 1, Integer::sum) (or compute/computeIfAbsent), or use LongAdder/AtomicInteger values. Option d is a real Java gotcha in other contexts but irrelevant here — the arithmetic value is correct; the lost-update race is the actual bug. Reaching for a concurrent collection and assuming compound operations are now safe is a classic mistake.

HashMap explicitly permits one null key and any number of null values. ConcurrentHashMap, by contrast, throws NullPointerException on any attempt to insert a null key or null value. This restriction is intentional: in a concurrent map, ambiguities arise if get returns null because it cannot distinguish 'the key maps to null' from 'the key is absent.' Eliminating nulls removes that ambiguity and avoids the need for the containsKey workaround that single-threaded HashMap callers can use.

CopyOnWriteArrayList creates a fresh snapshot copy of the underlying array each time the list is modified, and its iterator operates on a frozen reference to the array that existed at the time the iterator was created. Because mutations are not reflected back through the iterator's view, the remove() operation is unsupported and always throws UnsupportedOperationException. The iterator also never throws ConcurrentModificationException because it never sees structural changes made after it was created.

The TREEIFY_THRESHOLD constant is defined as 8 in HashMap's source. When a bin reaches 8 entries, the treeifyBin method is called, but it first checks if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY), where MIN_TREEIFY_CAPACITY = 64. If the table length is below 64, the method calls resize() instead of converting the bin to a tree. Only when the table has at least 64 slots will the linked list in that bucket be replaced with a TreeNode-based red-black tree. This design choice reflects the fact that resizing is cheaper and more broadly beneficial when the table is still small, whereas treeifying individual buckets becomes worthwhile only at larger table sizes where collisions are due to genuinely bad hash distribution rather than an undersized table.

PECS — Producer Extends, Consumer Super — tells you which wildcard bound to pick. ? extends T is for producers you read from (covariant, read-safe, write-forbidden because the exact subtype is unknown); ? super T is for consumers you write to (contravariant, write-safe, reads only yield Object). The mnemonic captures the variance rules that keep the type system sound. A strong answer ties each bound to read vs write and explains why (the unknown exact type); weak answers just recite the acronym. This shows up in real API design — e.g. Collections.copy and Stream.collect signatures — and in deciding flexible method parameter types.

The comparator chain applies three stages: (1) salary descending via comparingInt(salary).reversed(), (2) name descending via thenComparing(comparing(name).reversed()), and (3) years ascending via thenComparingInt(yearsOfService). Salary descending puts the two 120 000 employees (Carol, Eve) first, then the two 90 000 employees (Alice, Bob), then Dave at 80 000. Within the 120 000 tie, name descending orders "Eve" before "Carol" (E > C), giving Eve then Carol — years never come into play because names differ. Within the 90 000 tie, name descending orders "Bob" before "Alice" (B > A), giving Bob then Alice. Dave is alone at 80 000. Final sorted order: Eve (e), Carol (c), Bob (b), Alice (a), Dave (d). The critical subtlety is that reversed() is scoped: it negates only the comparator instance it is invoked on, not subsequent thenComparing appendages, and the second-stage name comparator was independently reversed before being passed in.