Interview Questions

It is an array of buckets. put(k, v) calls k.hashCode(), mixes the high bits into the low bits (h ^ (h >>> 16)), and uses hash & (capacity - 1) to pick a bucket. Keys that land in the same bucket are chained; equals decides which entry matches. When a bucket holds more than 8 entries (and the table has at least 64 buckets) the chain becomes a red-black tree, so a bad hash degrades to O(log n), not O(n). When size exceeds capacity × load factor (default 16 × 0.75) the table doubles and entries are redistributed.

What they are really testing: The standard mid-level filter. They want buckets, hashCode then equals, resize, and treeification — in that order.

If a.equals(b) then a.hashCode() == b.hashCode(). (The reverse is not required — collisions are allowed.) Override equals without hashCode and two "equal" keys land in different buckets: set.contains(copy) returns false and a HashSet holds duplicates. A second trap: using a mutable object as a key and changing a field that feeds hashCode after insertion — the entry is now in the wrong bucket and effectively lost. Records and immutable keys avoid both.

What they are really testing: Whether they can predict the actual symptom, not just recite the rule.

Comparable<T> is implemented by the class itself (compareTo) and defines its one natural order — String alphabetical, Integer numeric. Comparator<T> is a separate object for any other order, and composes: Comparator.comparing(Employee::dept).thenComparing(Employee::salary, Comparator.reverseOrder()). Never compare with a - b; it overflows for large ints. Use Integer.compare.

What they are really testing: Fluency with the Comparator combinators, and the subtraction-overflow bug.

Collections in java.util keep a modification count; if the collection is structurally changed during iteration by anything other than the iterator itself, the next next() throws ConcurrentModificationException. It is a best-effort bug detector, not a thread-safety guarantee. To remove safely use iterator.remove() or, simpler, list.removeIf(x -> x.isExpired()). Concurrent collections like CopyOnWriteArrayList and ConcurrentHashMap have weakly consistent iterators that never throw it.

What they are really testing: Whether they know CME usually happens in single-threaded code, and know removeIf.

Generics are checked at compile time and then erased: at run time a List<String> and a List<Integer> are both just List. Consequences: no new T(), no new T[n], no instanceof List<String>, no overloading m(List<String>) with m(List<Integer>), and no primitives as type arguments. The usual workaround is passing a Class<T> or a Supplier<T>.

What they are really testing: Understanding generics as a compile-time feature, which explains most of their odd restrictions.

Producer Extends, Consumer Super. A parameter you only read from should be List<? extends Number> — it accepts a List<Integer> or List<Double>, but you cannot add to it. A parameter you only write into should be List<? super Integer> — it accepts a List<Number> or List<Object>. Collections.copy(List<? super T> dest, List<? extends T> src) is the textbook signature.

What they are really testing: Whether they can design a flexible generic API rather than only consume one.

Intermediate operations (filter, map, sorted, limit) return a new stream and are lazy — nothing runs until a terminal operation (collect, toList, forEach, count, findFirst) pulls elements through. Laziness lets limit and findFirst short-circuit. A stream can be consumed once; a second terminal call throws IllegalStateException.

What they are really testing: That streams are a pipeline, not a collection — and the single-use rule.

map turns each element into exactly one element: Stream<Order> to Stream<Customer>. flatMap turns each element into a stream of zero or more elements and concatenates them: orders.stream().flatMap(o -> o.lines().stream()) gives every line of every order as one flat stream. The same idea exists on Optional, where it avoids Optional<Optional<T>>.

What they are really testing: A concrete one-to-many example, which shows real stream use.

Collectors.groupingBy(Employee::dept, Collectors.counting()) gives a Map<String, Long>; the downstream collector can be summingInt, mapping, toSet and so on. toMap(k, v) throws IllegalStateException: Duplicate key the moment two elements produce the same key — pass a merge function, toMap(k, v, Integer::sum), and a map supplier such as TreeMap::new if order matters.

What they are really testing: Real-world stream use plus the duplicate-key exception that hits everyone once in production.

Make the class final (or use a record), all fields private final, no setters, and defensive copies of any mutable input and output: this.tags = List.copyOf(tags) in the constructor. Return new objects from "modifying" methods (withPrice(...)). A record with a List component is not deeply immutable unless you copy the list in a compact constructor.

What they are really testing: The defensive-copy step. "final fields" alone leaves a mutable list exposed.

It is a return type for "there may be no result": Optional<User> findByEmail(...). Callers use map, orElse, orElseThrow, ifPresent. Misuses: calling get() without checking (a slower NullPointerException), using it as a field or method parameter, putting it in collections, and returning null from a method declared to return Optional. For primitives use OptionalInt.

What they are really testing: Whether they treat Optional as API design, not as a null replacement sprinkled everywhere.

Catch only what you can handle; let the rest propagate to one place (a controller advice, the top of a job). Never swallow an exception with an empty catch. When translating, keep the cause: throw new OrderException("order " + id, e). Catch specific types, not Exception. Log once, at the place that handles it — not at every layer. Do not use exceptions for normal control flow; they are expensive because they capture a stack trace.

What they are really testing: Production maturity. Lost causes and log-and-rethrow at every layer are what reviewers flag.

sealed interface Shape permits Circle, Square, Rect {} (Java 17) restricts which classes may implement it. Combined with records and a pattern-matching switch (Java 21), the compiler knows every case, so no default is needed and adding a new subtype turns every incomplete switch into a compile error:

double area(Shape s) {
    return switch (s) {
        case Circle c -> Math.PI * c.r() * c.r();
        case Square q -> q.side() * q.side();
        case Rect r   -> r.w() * r.h();
    };
}

What they are really testing: Whether they are writing Java 21 or Java 8. Exhaustiveness checking is the point to mention.

It wins. A return in finally overrides the value returned by try and silently discards any exception thrown in try or catch. That is why it is a warning in every linter: never return or throw from finally. Use it only for cleanup, or better, use try-with-resources.

What they are really testing: A classic trick question; the real test is knowing the exception disappears.

An interface with exactly one abstract method (Runnable, Function<T,R>, Predicate<T>, Supplier<T>); a lambda or method reference can implement it. @FunctionalInterface makes the compiler enforce the single method. A lambda captures the value of a local variable, not the variable, and it may run later or on another thread; allowing the local to change afterwards would make that copy silently stale, so Java requires it to be effectively final.

What they are really testing: Understanding lambdas as objects implementing an interface, and the reason behind the capture rule.

Both give mutual exclusion and memory visibility, and both are reentrant. synchronized is a language keyword: the lock is released automatically, even on an exception. ReentrantLock is a class with extra features — tryLock() with a timeout, interruptible waits, an optional fairness policy and multiple Conditions — but you must unlock() in a finally. Default to synchronized or a higher-level utility; use a lock when you need one of those features.

What they are really testing: That they know the trade-off, and the unlock-in-finally discipline.

A volatile field guarantees visibility and ordering: a write by one thread is seen by every later read in another thread, and it is never cached in a register. It does not make compound operations atomic — count++ on a volatile int is still a read, an add and a write, and updates are lost under contention. Use it for a stop flag; use AtomicInteger/LongAdder or a lock for counters.

What they are really testing: The visibility vs atomicity distinction — the core of the Java memory model at interview depth.

A platform thread is expensive to create and unbounded creation can exhaust memory. An executor reuses a pool of threads, queues tasks, returns Futures for results and exceptions, and has a lifecycle (shutdown, awaitTermination, or try-with-resources since Java 19). For I/O-bound work in Java 21+, Executors.newVirtualThreadPerTaskExecutor() gives one cheap virtual thread per task. For composition, CompletableFuture builds pipelines on top of an executor.

What they are really testing: Knowing why pooling exists and that uncaught exceptions in a Future are only seen when you call get().

synchronizedMap wraps every method in one lock, so all threads queue behind each other. ConcurrentHashMap locks per bucket on writes and does not lock for reads, so it scales. It also offers atomic compound operations — computeIfAbsent, merge, putIfAbsent — which matter because if (!map.containsKey(k)) map.put(k, v) is a race on any map. It does not allow null keys or values.

What they are really testing: That thread-safe individual methods do not make check-then-act sequences safe.

Virtual threads (final in Java 21) are threads managed by the JVM rather than the OS. They are cheap enough to create one per request — millions if needed. When a virtual thread blocks on I/O it unmounts from its carrier OS thread, which picks up other work. They help I/O-bound code written in plain blocking style (HTTP calls, JDBC). They do not make CPU-bound work faster, and you should not pool them. Pinning inside synchronized blocks was a known limitation, largely removed in Java 24.

What they are really testing: Whether they know the one thing virtual threads are for, and do not oversell them.

Each thread has its own stack of frames: local primitives, references and return addresses for method calls in progress; it is freed automatically when a method returns. Objects live on the shared heap and are reclaimed by the garbage collector when unreachable. Deep recursion overflows the stack (StackOverflowError); too many live objects exhaust the heap (OutOfMemoryError: Java heap space). The JIT’s escape analysis can avoid heap allocation for objects that never leave a method.

What they are really testing: Mapping the two errors to the two memory areas is what they want.

The GC finds objects reachable from roots (thread stacks, static fields, JNI handles); everything else is garbage, cycles included. Heaps are generational because most objects die young: new objects go to the young generation, which is collected often and cheaply; survivors are promoted to the old generation. G1 (the default) splits the heap into regions and aims for a pause-time target; ZGC does almost all work concurrently for very short pauses. You tune with heap size (-Xmx) first and GC flags last.

What they are really testing: Reachability (not reference counting), the generational hypothesis, and knowing the default collector.

The GC only frees unreachable objects; a leak is objects that are still reachable but no longer needed. Common causes: a static Map used as a cache with no eviction, listeners registered and never removed, ThreadLocal values in pooled threads that are never cleared, and keys whose hashCode changes so entries can never be removed. You find them with a heap dump (jcmd <pid> GC.heap_dump) and a dominator-tree view in a tool such as Eclipse MAT.

What they are really testing: Whether they understand "reachable but useless", and know how to get a heap dump.

Classes are loaded lazily, on first use, by a hierarchy of class loaders: bootstrap (core java.*), platform, then the application class loader for your classpath. Loaders delegate to the parent first, so your code cannot replace java.lang.String. Loading is followed by linking (verification, preparation) and initialisation, when static initialisers run — exactly once. ClassNotFoundException means a class looked up by name was missing; NoClassDefFoundError means it was present at compile time but missing or failed to initialise at run time.

What they are really testing: Parent delegation, and the CNFE vs NCDFE distinction that shows up in real dependency conflicts.

The JVM starts by interpreting bytecode while counting how often each method and loop runs. Hot code is compiled to native machine code — first quickly by C1, then aggressively by C2 using real profiling data: inlining, escape analysis, removing bounds checks, speculative optimisations it can undo if an assumption breaks. That is why a service is slower for its first seconds (warm-up) and why micro-benchmarks need a harness like JMH rather than a timing loop.

What they are really testing: Whether they understand warm-up, and why naive benchmarks of Java code lie.