Core Java

Tests whether you can adapt binary search to an array with one pivot break -- deciding which half is sorted at each step -- and separately handle the degenerate single-element and duplicate-boundary edge cases.

Tests whether you know the max-path-sum recursion must track two different values per node -- the best downward path to return to the parent, and the best path-through-node to update a global max.

Tests whether you recognize this as binary search over the answer space (eating speed), not over the array, using a feasibility check (hours needed at speed k) to drive the search.

Tests whether you can implement the partition step correctly (pivot placement, pointer movement) and explain why worst-case O(n^2) happens on already-sorted input with a naive pivot choice.

Tests whether you reach for a frequency-count array/map instead of sorting each string, and can extend the same idea to grouping anagrams or finding anagram substrings in a larger string.

Tests whether you can maintain four shrinking boundaries (top, bottom, left, right) and traverse them in order without off-by-one errors when rows or columns run out mid-cycle.

Tests whether you know a plain HashMap frequency count loses insertion order, and reach for a LinkedHashMap (or a second pass over the original array) to preserve it while still finding all count-1 elements.

Tests whether you merge from the back (using the trailing empty space in nums1) instead of the front, since merging forward would overwrite elements you still need to compare.

Tests whether you know trailing zeroes come from factors of 10, which are always bottlenecked by the scarcer factor of 5, so you count multiples of 5, 25, 125... in n! rather than naively computing the full factorial, which overflows for even moderately sized n.

Tests whether you map each letter to its keyboard row up front (via a lookup table), then check each word's letters all belong to the same row set, rather than doing a nested per-character row scan.

Tests whether you reach for a character-frequency count (array or HashMap) compared between both strings in O(n), rather than sorting both strings and comparing, which works but costs an unnecessary O(n log n).

Tests whether you check primality with trial division up to sqrt(n) per element rather than the full range, and handle the 0/1/negative edge cases correctly.

Tests whether you reduce 'some permutation is a palindrome' to a character-parity bitmask per string, then count pairs whose masks are equal or differ by exactly one bit, instead of generating permutations.

Tests whether you know plain Dijkstra fails here because it ignores the stop-count constraint, and reach for Bellman-Ford-style relaxation bounded to K+1 edges (or BFS layer by layer) instead.

Tests whether you can implement backtracking with constant-time constraint checks (row/column/box bitmasks) rather than rescanning the board on every placement, since a naive solver times out on harder boards.

Tests whether you can derive character-ordering edges from adjacent word comparisons (first differing character only) and run Kahn's algorithm or DFS-based topological sort, including detecting an invalid/cyclic ordering.

Tests whether you know the exact solution needs two balanced heaps (max-heap for the lower half, min-heap for the upper half), then can trade exactness for O(1) space using a streaming approximation like the P-square algorithm or reservoir sampling.

Tests whether you use a sliding window with two monotonic deques (one tracking the window max, one the window min) to maintain both in amortized O(1) per step, instead of recomputing max/min on every window change.

Tests whether you can translate the standard flood-fill (DFS/BFS from each unvisited land cell, marking visited) into working Java under time pressure, including correct grid bounds checking.

Tests whether you use the slow/fast pointer technique (fast moves two nodes per step) to find the middle in a single traversal, instead of counting length first and doing a second pass.

Tests whether you do a level-order (BFS) traversal and take the first node seen at each depth, or a depth-first traversal that only records a node the first time its depth is reached.

Tests whether you know cycle detection differs for directed graphs (track a recursion-stack/gray-node set, not just visited) versus undirected graphs (track the parent to avoid flagging the edge you just came from).

Tests whether you notice the small n bound makes naive exponential recursion acceptable, but still know to mention memoization or iteration as the production-grade fix for larger n.

Tests whether you sort intervals by start time first, then merge in a single pass by comparing each interval's start against the current merged interval's end -- the sort is what makes the merge linear.

Tests whether you can reverse each k-sized chunk in place while correctly re-linking the reversed chunk's tail to the next chunk's head, and handle a trailing group shorter than k per the stated rule.

Tests whether you can build the 2D DP table where dp[i][j] extends by one on a character match or takes the max of dropping one character from either string on a mismatch.

Tests whether you compute height and balance in a single bottom-up pass (returning -1 as an early-exit imbalance signal), instead of a naive solution that recomputes height from scratch at every node.

Tests whether you reach for a min-heap of size k or Quickselect (average O(n)) instead of fully sorting the array when only the kth largest value is needed.

Tests whether you use a single-pass two-pointer swap (tracking the next non-zero insertion position) to move zeroes to the end in-place and O(n), instead of shifting elements repeatedly or allocating a new array.

Tests whether you compare characters column-by-column across all strings (or incrementally shrink a prefix candidate against each string) and stop at the first mismatch or shortest string, rather than comparing every pair of strings.

Tests whether you use the arithmetic-sum formula (or XOR of indices and values) to find the missing number in O(n) time and O(1) space, instead of sorting or using a hash set.

Tests whether you know the digital root has a constant-time formula (1 + (n-1) mod 9) and can derive it from modular arithmetic, instead of only offering the repeated-summation loop.

Tests whether you achieve O(n) time and O(1) extra space by using the array itself as a hash table -- placing each value v at index v-1 via in-place swaps, then scanning for the first index that doesn't hold its expected value.

Tests whether you use a sliding window with a character-index map, jumping the window's left edge directly past the previous occurrence of a repeated character instead of shrinking it one step at a time.

Tests whether you build a single frequency map in one pass and then filter for counts greater than one, rather than comparing every character against every other character.

Tests whether you reach for a sliding window (shrinking from the left once the sum meets or exceeds target) for O(n) time on non-negative values, rather than the brute-force O(n^2) check of every subarray.

Tests whether you know to convert to a char array and swap from both ends inward (two-pointer, in-place), demonstrating you understand String's immutability means you can't reverse it in place directly.

Tests whether you reach for a HashSet to track seen elements in a single O(n) pass, rather than a nested-loop O(n^2) comparison -- and whether you'd mention the in-place XOR/marking trick if the constraints demand no extra space.

Tests whether you use a two-pointer comparison from both ends toward the middle for O(n) time and O(1) extra space, rather than reversing the string and comparing, which costs an unnecessary extra allocation.

Tests whether you combine a HashMap (O(1) key lookup) with a doubly linked list (O(1) move-to-front/eviction) rather than a single data structure -- this is exactly what LinkedHashMap does internally, and knowing that shows you understand why the combination is necessary for true O(1) get/put.

Tests whether you reach for a BlockingQueue (which handles wait/notify internally) as the production-grade answer, while also being able to implement the classic wait()/notify() version manually to show you understand what the queue abstracts away.

Tests whether you use a LinkedHashMap (or two passes with a frequency array) to track both counts and original order in O(n), rather than an O(n^2) approach that re-scans for each character.

Tests whether you reach for Floyd's cycle detection (slow/fast pointer) for O(n) time and O(1) space, rather than a HashSet of visited nodes, which works but costs O(n) extra space.

Tests whether you combine a frequency HashMap with a min-heap of size K for O(n log k) time, rather than sorting all elements by frequency (O(n log n)), which does unnecessary extra work when k is much smaller than n.

Tests whether you know all four flavors and what specifically distinguishes each one's scope and use case.

Tests whether you know a static nested class doesn't hold an implicit reference to an instance of the outer class, unlike a regular inner class.

Tests whether you know a local inner class can only capture effectively final local variables from its enclosing scope.

Tests whether you know when this one-off, no-name class syntax is appropriate versus when a lambda or named class fits better.

Tests whether you know exactly which memory regions each GC type actually sweeps.

Tests whether you know these are triggered by two completely different memory regions filling up.

Tests whether you know the pause-time and throughput tradeoffs across modern collectors, not just their names.

Tests whether you recognize this as the classic memory-leak signature and know the heap-dump workflow to isolate it.

Tests whether you know Metaspace exhaustion usually points to classloader leaks, not regular object allocation.

Tests whether you know to look past the heap entirely — direct ByteBuffers, Netty off-heap memory, or JNI leaks.

Tests whether you know JVM safepoints (biased lock revocation, deoptimization) can freeze threads independently of GC.

Tests whether you know the JIT can allocate objects on the stack instead of the heap when it proves they never escape a method.

Tests whether you know why a class request always goes up the classloader hierarchy first, and what that prevents.

Tests whether you know the practical workflow: dominator tree, retained size, and finding the actual leak suspect.

Tests whether you know how the JVM avoids lock contention on every single object allocation.

Tests whether you know the JVM picks sensible defaults based on hardware and heap size without any flags at all.

Tests whether you can name and roughly characterize the collectors -- Serial, Parallel, CMS (deprecated/removed), G1 (default since Java 9), ZGC, and Shenandoah -- and place them on the throughput-vs-pause-time spectrum rather than treating 'garbage collector' as one fixed algorithm.

Tests whether you know the heap, stack, metaspace, and PC register layout and what lives where.

Tests whether you understand generational GC, reachability, and why Java doesn't need manual memory management.

Tests whether you know why a class request is always delegated upward first, and what that prevents.

Tests whether you know these three reference types and how each affects when the GC is allowed to reclaim an object.

Tests whether you understand how the JVM detects hot code paths and compiles them to native machine code at runtime.

Tests whether you can name concrete GC advances landing around Java 17 -- G1 becoming the stable default with steadily reduced pause times, and ZGC maturing toward production readiness -- rather than a vague 'garbage collection got faster' without specifics.

The Code Cache stores JIT-compiled native code and has a fixed max size. Once full, the JVM stops compiling new methods and falls back to interpretation, gradually degrading performance until you raise -XX:ReservedCodeCacheSize.

It prints every method as it gets JIT compiled — timestamp, compilation ID, tier level (1-4), and class/method name — useful for diagnosing which methods are hot and when deoptimization happens.

32-bit has smaller pointers (less CPU cache pressure, faster for small short-lived apps) but caps heap around 3GB and only supports C1. 64-bit scales to available RAM and gets both C1+C2, but pointer overhead makes it not automatically faster for small apps.

Returning a live reference to an internal collection/object lets callers mutate your class's private state directly. Fix with: returning an iterator, a defensive copy, an immutable wrapper, a deep copy, a read-only interface, or hiding the implementation behind a Java Module boundary.

The String Pool is a fixed-bucket hash table (65,536 buckets by default in Java 11+); millions of unique strings cause hash collisions and degrade lookup performance. Fix with -XX:StringTableSize=<prime number> sized for your actual string volume.

String Deduplication (-XX:+UseStringDeduplication with G1) finds identical strings already on the heap and makes them share one underlying char[] array, reducing memory — unlike the String Pool, which only applies to literals and doesn't touch strings created at runtime.

If they differ, the JVM requests memory from the OS incrementally as needed, and G1 GC can even return unused heap to the OS — causing repeated OS-level allocation calls ("yo-yo" behavior). Setting them equal claims all memory upfront once.

-Xms/-Xmx (heap sizing), -XX:ReservedCodeCacheSize, -XX:+UseG1GC + -XX:MaxGCPauseMillis, -XX:+HeapDumpOnOutOfMemoryError, -XX:StringTableSize, -XX:NewRatio, -XX:SurvivorRatio, -XX:MaxTenuringThreshold — each controls a distinct part of JVM behavior worth knowing by name.

It's only a suggestion the JVM is free to ignore — there's no guarantee it actually runs a collection. Meanwhile, if it does run, it pauses the application at a time you don't control, which can hurt response time unpredictably.

finalize() runs only when the GC decides to, with no guaranteed timing — a hung finalizer on one object can stall the GC for the whole JVM. It's deprecated since Java 9; use try-with-resources (AutoCloseable) for guaranteed, deterministic cleanup instead.

JFR continuously records JVM events (allocations, GC, thread state, I/O) with typically under 1% overhead, giving you a timeline of behavior leading up to a problem — a heap dump is only a single point-in-time snapshot of live objects, with no history of how you got there.

It measures code before JIT warm-up completes (so you're timing the slow interpreted version), can be skewed by a GC pause landing inside the measurement window, and the JIT can eliminate 'dead' code that computes a result nobody uses — all of which produce numbers that don't reflect real steady-state performance.

JMH (Java Microbenchmark Harness) automatically handles JIT warm-up iterations, runs multiple JVM forks for fresh state, computes statistical variance, and uses a Blackhole to prevent the JIT from eliminating your benchmarked code as dead code — all things a naive timing loop gets wrong.

ByteBuffer.allocateDirect() allocates off-heap, native OS memory — invisible to normal heap monitoring tools. Exhausting it throws 'Direct buffer memory' OOM even with plenty of heap free; tune with -XX:MaxDirectMemorySize and check with jcmd VM.native_memory.

Use `top -H -p <pid>` to find the hot native thread ID, convert it to hex (`printf "%x"`), take a `jstack <pid>` dump, and search for that hex ID as `nid=0x...` in the dump — its stack trace shows the exact method spinning the CPU.

Tests whether you know the Heap holds all objects (shared, GC-managed), the Stack holds per-thread method frames and local primitives/references (private, auto-reclaimed on return), and the Method Area/Metaspace stores class metadata -- not just that 'objects go on the heap'.

Tests whether you describe GC as reachability analysis from GC roots (not simple reference counting, which can't handle cycles), and whether you flag finalize() as deprecated and unreliable -- it runs on no guaranteed schedule and modern code uses try-with-resources or Cleaner instead.

A heap dump only shows Java heap contents. `jcmd <pid> VM.native_memory summary` (with -XX:NativeMemoryTracking=summary enabled) shows the FULL JVM memory picture — heap, Metaspace, thread stacks, Code Cache, and GC structures — useful when a process uses far more OS memory than -Xmx suggests.

Tests whether you know class metadata (method tables, field layouts, constant pool, runtime type info) is stored in Metaspace after the classloader parses the .class file -- separate from instance data on the heap -- and that too many dynamically generated classes can exhaust Metaspace.

By default the JVM may size its heap off the host's total RAM, not the container's cgroup limit, causing it to exceed the pod's memory limit. Fix with explicit -Xmx, or -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 (Java 10+), and remember total footprint = heap + Metaspace + Code Cache + thread stacks, not just -Xmx.

'Java heap space' (heap full), 'GC overhead limit exceeded' (GC running constantly but barely reclaiming memory), 'Direct buffer memory' (off-heap exhausted), 'Metaspace' (class metadata space full), 'Unable to create new native thread' (OS thread limit hit) — each points to a genuinely different root cause and fix.

Tests whether you know a Java 'leak' is really unintended reachability -- static collections that only grow, unclosed resources, listener/callback registrations never removed, or ThreadLocal values left behind in pooled threads -- not literal unmanaged memory like in C.

VisualVM and JMC/Flight Recorder for deep profiling, jcmd/jstat/jstack/jmap for quick command-line diagnostics, Eclipse MAT for heap dump analysis, and Prometheus+Grafana (or Datadog/Dynatrace) for continuous production metrics and alerting.

Tests whether you know GC can only reclaim unreachable objects -- if live references still exist (a growing cache, a leaking listener list), the GC runs successfully every time but frees nothing useful, and the heap fills regardless.

GraalVM is an alternative JVM with its own JIT compiler (written in Java) and a Native Image tool that Ahead-of-Time compiles your whole app into a standalone executable — near-instant startup and low memory, but no runtime JIT profiling means lower peak throughput, and reflection/dynamic class loading need to be declared upfront.

Tests whether you'd pull GC logs (-Xlog:gc*) to check for full GCs vs young-gen collections, correlate pause growth with a recent change in allocation rate or object retention, and consider whether the collector (G1 vs ZGC) matches the new workload's latency profile.

Tests whether you pick ZGC -- G1's pause times scale with heap size and live-set complexity, typically landing in tens-to-hundreds of ms on a 30GB heap, while ZGC's concurrent, region-based collection keeps pauses sub-millisecond regardless of heap size, which is the only way to reliably hit a 10ms budget.

Tests whether you understand the three nested layers of the Java platform and what each one is actually responsible for.

Checks whether you can explain encapsulation, abstraction, inheritance, and polymorphism with concrete examples, not just definitions.

Tests your understanding of reference equality versus logical equality, and where each one silently trips people up.

Tests whether you know compile-time vs runtime polymorphism and the rules that govern each.

Tests whether you know when to use each, especially after Java 8 added default and static methods to interfaces.

Tests whether you understand what 'belongs to the class, not the instance' actually means in memory and execution order.

A classic trick question — tests whether you know Java is always pass-by-value, even for objects, and why that still confuses people.

Tests whether you know how Java silently converts between primitives and wrapper classes, and where that costs performance.

Tests whether you understand multiple inheritance ambiguity and the specific resolution rules Java applies for default methods.

Tests whether you know the classic instanceof check plus the newer syntax that eliminates the redundant cast afterward.

No — final only prevents reassigning the reference itself; the object's internal state can still be mutated through its setters. True immutability requires the class itself to have no mutating methods.

Binary floating point can't represent most decimal fractions exactly — `0.1 + 0.2` prints `0.30000000000000004`. Use BigDecimal with the String constructor (`new BigDecimal("0.1")`, never the double constructor) for exact decimal arithmetic; it's 5-10x slower but correctness matters more for money.

Java has 8 primitive types (int, char, boolean, etc.) that are not objects — a truly pure OO language (like Smalltalk) treats everything, including numbers, as an object. Java also supports static members and methods that belong to a class rather than an instance, which is another departure from pure OO design.

The .java source is compiled by javac into platform-independent .class bytecode; the JVM's class loader loads that bytecode, the bytecode verifier checks it for safety, and the execution engine (interpreter + JIT compiler) then runs it, translating hot bytecode into native machine code on the fly.

Java source code compiles to bytecode, not native machine code — that bytecode runs unchanged on any device with a compatible JVM, since the JVM (not the OS) is what actually translates it into native instructions. "Write once, run anywhere" refers to the bytecode being portable, not the JVM itself, which is platform-specific.

Java uses references instead of raw pointers — a reference lets you access an object but never lets you perform pointer arithmetic or directly manipulate a memory address. This removes an entire class of bugs (dangling pointers, buffer overruns, memory corruption) and is what makes automatic garbage collection safe, since the JVM can always track exactly which references point to which objects.

Tests whether you connect runtime polymorphism to dynamic method dispatch via the vtable -- the JVM resolves the overridden method based on the actual object type at runtime, not the reference type at compile time.

Tests whether you know overload resolution is based solely on the method signature (name + parameter types), so return type alone causes a compile error -- not ambiguity, because the compiler can't distinguish the two methods at all.

Tests whether you know main() can be overloaded like any static method, but the JVM launcher only ever invokes the exact signature public static void main(String[] args) by reflection -- the others are just ordinary overloads you'd have to call yourself.

Tests whether you know this refers to the current object instance (used for disambiguating fields/constructor chaining within the class), while super refers to the immediate parent class (used to access parent members or invoke the parent constructor) -- and that both must be the first statement when chaining constructors.

Tests whether you know to extend Exception (checked, forces callers to handle or declare) vs RuntimeException (unchecked), and whether you preserve the original cause via the constructor that takes a Throwable instead of swallowing the stack trace.

Tests whether you know BufferedInputStream wraps a raw input stream to reduce the number of actual read() system calls by pulling larger chunks into an internal buffer, while BufferedOutputStream batches writes into its buffer and only flushes to the underlying stream when full or explicitly flushed.

Tests whether you know == compares references (or primitive values) while .equals() compares logical/content equality as defined by the class -- and that unboxed Integer caching (-128 to 127) is the classic trap that makes == appear to 'work' until it doesn't.

Tests whether you know the containment hierarchy: JVM executes bytecode, JRE wraps the JVM plus core libraries to run programs, and JDK wraps the JRE plus the compiler and dev tools needed to build programs -- not just three interchangeable acronyms.

Tests whether you know FilterInputStream/FilterOutputStream are the decorator-pattern base classes that wrap another stream to add behavior (buffering, data type conversion, checksums) without changing the underlying stream's interface -- the mechanism behind classes like BufferedInputStream and DataInputStream.

Tests whether you know the String Pool is a special heap region (part of the heap since Java 7, not PermGen) that interns string literals so identical literals share one object -- and that new String("x") deliberately bypasses it unless you call intern().

Tests whether you understand serialization converts an object graph into a byte stream for storage or transmission (via implementing Serializable), and whether you can name a real use case -- caching, session replication, or message passing between JVMs -- instead of only reciting the mechanism.

Tests whether you know passwords must be hashed with a slow, salted algorithm designed for this purpose (bcrypt, scrypt, or Argon2) rather than encrypted (which is reversible) or hashed with a fast general-purpose function like plain SHA-256, which is vulnerable to brute-force and rainbow-table attacks.

Tests whether you connect immutability to String Pool safety (sharing literals would break if one reference could mutate another), hashcode caching for fast HashMap lookups, and thread-safety without synchronization -- not just 'because it's final'.

Tests whether you know hash-based collections rely on the contract that equal objects must produce equal hash codes -- break it and a HashMap/HashSet will silently fail to find an object you just inserted because it lands in the wrong bucket.

Tests whether you know Java enums are full classes with a fixed set of singleton instances, so comparing them with == is always safe and preferred over equals() -- since each enum constant is guaranteed to be a single shared instance, unlike ordinary objects.

Tests whether you know Lombok generates boilerplate (getters, setters, constructors, equals/hashCode, builders) at compile time via annotation processing, and whether you're aware of its trade-off -- less code to maintain versus 'magic' that can obscure what's actually being generated for newcomers reading the class.

Tests whether you separate the concept from the construct -- abstraction is the design principle of hiding implementation details behind a simpler contract, while an interface is one specific Java language mechanism for achieving it, alongside abstract classes.

Tests whether you know static methods aren't polymorphic -- redeclaring a static method with the same signature in a subclass hides the parent's version rather than overriding it, so which one runs is resolved by the reference's compile-time type, not the object's runtime type.

Tests whether you can justify an abstract class choice concretely -- when you want to share common state or partial implementation across subtypes while still forcing them to fill in specific behavior -- rather than defaulting to abstract classes out of habit when a normal class with composition would do.

Tests whether you know a static nested class doesn't hold an implicit reference to its enclosing instance, which is why utility/helper classes are made static -- they don't need outer-instance state, and keeping that reference would just waste memory and allow accidental coupling.

Tests whether you keep the three apart despite the similar spelling -- final is a modifier preventing reassignment/overriding/subclassing, finally is the block that always runs after try/catch regardless of outcome, and finalize() is a deprecated Object method the GC used to call before reclaiming an object, with no execution guarantee.

Tests whether you default to 'favor composition over inheritance' for the right reason -- composition keeps classes loosely coupled and avoids the fragile base class problem, while inheritance is justified only for genuine is-a relationships where subtypes must be substitutable for the base.

Tests whether you know both describe a has-a relationship, but aggregation is a weak association where the contained object can outlive the container (a Department holding Employees that exist independently), while composition is a strong ownership relationship where the contained object's lifecycle is bound to the container's.

Tests whether you know a non-final immutable class can be subclassed, and that subclass can override methods to introduce mutable state or behavior that breaks the immutability contract callers rely on -- sealing the class with final is what actually guarantees every instance behaves immutably.

Tests whether you know returning or storing a direct reference to a mutable field (like a Date or array) lets external code mutate your object's internal state without going through its API -- a defensive copy on the way in or out closes that hole and is essential for genuinely immutable classes.

Tests whether you know transient marks a field to be skipped during default Java serialization, used for fields that are derived, sensitive, or simply not serializable (like a Thread or Socket reference) -- the field survives in memory but comes back as its default value after deserialization.

Tests whether you connect the right structure to the right access pattern -- ArrayList's contiguous array gives O(1) random access but O(n) middle inserts, while LinkedList's node chain gives O(1) inserts/removes at known positions but O(n) indexed access, with the node overhead usually making ArrayList the better default anyway.

Tests whether you know Comparable defines a class's single natural ordering via compareTo() implemented on the class itself, while Comparator defines an external, pluggable ordering you can swap at call time -- and that you need Comparator the moment you want more than one sort order for the same type.

Tests whether you connect HashMap's O(1) average lookup to collapsing an O(n^2) nested-loop comparison into an O(n) single pass -- trading a bit of memory for hash-bucket lookups instead of re-scanning the second collection for every element of the first.

Tests whether you know Java 8 introduced bucket treeification (converting a long collision chain into a red-black tree once it crosses a threshold, dropping worst-case lookup from O(n) to O(log n)) and changed the hash spreading function, rather than assuming HashMap's internals stayed the same across versions.

Tests whether you know beyond simple data corruption, concurrent resizing on a plain HashMap can create a circular reference in a bucket's linked list, putting a later get() into an infinite loop that pegs CPU -- the classic reason HashMap is explicitly documented as not thread-safe.

Tests whether you reach for Collections.synchronizedList(new LinkedList<>()) to get a thread-safe wrapper, and whether you know you still need to manually synchronize on the returned list when iterating, since the wrapper only synchronizes individual method calls.

Tests whether you know the exact thresholds -- a bucket treeifies once its chain hits 8 entries AND the table has at least 64 buckets (otherwise it resizes instead), and untreeifies back to a linked list once it drops to 6 -- not just the vague idea that 'long chains become trees.'

Tests whether you know HashMap computes and caches the bucket index at insertion time, so a mutated key's new hashCode won't match where it's actually stored -- get() with the mutated key returns null because it looks in the wrong bucket entirely.

Tests whether you know IdentityHashMap uses reference equality (==) instead of .equals()/hashCode() for key comparison, so two distinct-but-equal objects are treated as different keys -- a niche tool for identity-based caching, not a general-purpose map.

Tests whether you know a TreeSet throws NullPointerException on adding null because its ordering relies on compareTo()/Comparator, which can't compare against null -- unless you supply a custom Comparator that explicitly defines null's position.

Tests whether you connect this to LinkedHashMap's removeEldestEntry() hook (the classic DIY LRU building block) rather than treating 'cache map' as a built-in JDK type -- Java has no first-class cache collection out of the box.

Tests whether you articulate the core contract distinctions -- List is ordered and allows duplicates, Set enforces uniqueness via equals()/hashCode(), and Map stores key-value pairs with unique keys -- not just 'they're all collections'.

Tests whether you check the initial capacity/load factor first -- an undersized initial capacity forces repeated resize-and-rehash cycles as the map grows to a million entries, and the fix is pre-sizing the map to its expected final size instead of letting it grow incrementally from the default 16.

Tests whether you know Collection is the root interface of the collections hierarchy, while Collections is a utility class of static helper methods (sort, synchronizedList, unmodifiableList) -- a naming trap interviewers use to check real familiarity vs memorized terms.

Tests whether you know HashSet is a thin wrapper around a HashMap<E, Object> where your element becomes the key and a constant dummy object is the value -- add() computes hashCode(), finds the bucket, and uses equals() to check for an existing duplicate before inserting.

Tests whether you map each to its ordering guarantee and backing structure: HashMap gives no order (bucket array + hashing), LinkedHashMap preserves insertion (or access) order via an internal doubly-linked list, and TreeMap keeps sorted order via a red-black tree, trading O(1) for O(log n).

Tests whether you know HashMap special-cases the null key by always placing it in bucket 0 (since hashCode() can't be called on null), and that only one null key can exist because a Map's keys must be unique -- a deliberate design choice, not an accident of the hashing algorithm.

Tests whether you connect each Set variant to the Map it's built on underneath -- HashSet/HashMap, LinkedHashSet/LinkedHashMap, TreeSet/TreeMap -- so the same ordering and performance trade-offs apply directly.

Tests whether you know the reason is concurrency-specific ambiguity -- in a map accessed by multiple threads, get(key) returning null could mean either 'the key isn't present' or 'the key maps to null,' and that ambiguity is unresolvable without external locking, which defeats the point of a concurrent collection.

Tests whether you connect it to resize cost (growing by 50% and copying the whole backing array), O(n) insert/remove in the middle, and memory overhead from over-allocated capacity -- not just 'arrays are slow'.

Tests whether you know Vector is a legacy class that synchronizes every method (making it thread-safe but slower even when uncontended), while ArrayList is unsynchronized by default -- and that Vector's per-method locking still doesn't make compound operations like check-then-add atomic, so it's rarely the right choice over ArrayList plus explicit synchronization or a concurrent collection.

Tests whether you correctly implement Iterable/Iterator's hasNext()/next() contract (including throwing NoSuchElementException when exhausted) and can design a custom exception that extends the right base class for its intended checked/unchecked handling.

Tests whether you know ConcurrentHashMap's iterators are weakly consistent, not fail-fast -- they never throw ConcurrentModificationException and may or may not reflect modifications made during iteration, a deliberate trade-off for safe concurrent access instead of the strict fail-fast guarantee HashMap's iterator gives.

Tests whether you know wrapping a collection with Collections.synchronizedX() locks the whole structure on every operation (and still needs external synchronization for iteration), while java.util.concurrent collections use finer-grained or lock-free techniques internally -- so you default to concurrent collections for throughput under real contention, not synchronized wrappers.

Tests whether you understand virtual threads are cheap, JVM-scheduled, and unmount from the carrier thread on blocking I/O, versus platform threads which map 1:1 to OS threads and are expensive to spawn.

Tests whether you distinguish async (non-blocking, often single-threaded via an event loop or continuation) from multithreading (actual parallel execution), and that calling an async API returns a handle/promise immediately rather than blocking the caller.

Tests whether you know synchronized blocks and native calls can pin a virtual thread to its carrier thread.

Tests whether you know how it ties a group of subtasks' lifetimes together for cleaner cancellation and error handling.

Tests whether you know an unhandled exception in a chain just completes the future exceptionally, with nothing logged unless you check.

Tests whether you know thread-safety of individual operations doesn't make compound check-then-act sequences atomic.

Tests whether you know excessive threads can increase context-switching overhead and contention beyond a certain point.

Tests whether you know the tradeoffs in fairness, interruptibility, and read/write optimization across the three.

Tests whether you know these three synchronization tools solve genuinely different coordination problems.

Tests whether you know work-stealing is what makes ForkJoinPool efficient for divide-and-conquer tasks specifically.

Tests whether you know the four built-in RejectedExecutionHandler strategies and when each is appropriate.

Tests whether you know these overlapping-sounding terms actually describe two distinct classes of concurrency bug.

Tests whether you know pooled threads never die, so a ThreadLocal never cleared keeps leaking across every reused thread.

Tests whether you separate the two correctly -- multithreading is about using multiple threads of execution (often blocking), while asynchronous programming is about non-blocking composition of work that may run on far fewer threads (e.g. an event loop) -- so 'async' doesn't automatically mean 'multithreaded.'

Tests whether you know a synchronized method locks on the entire object (or the Class object for static methods) for its whole duration, while a synchronized block lets you lock on a specific object and scope the critical section as narrowly as possible, reducing contention by not holding the lock over unrelated code.

Tests whether you know sleep() holds any locks the thread owns for its entire duration, so sleeping while holding a lock another thread needs can create a deadlock-like stall, while wait() correctly releases the monitor -- and whether you know an improperly guarded wait() (missing the notify, or checking the condition outside a loop) can leave a thread waiting forever.

Tests whether you understand shared vs isolated memory space and why threads are cheaper to create.

Tests whether you understand Java's low-level thread coordination primitives and the monitor lock they require.

Tests whether you know Future only supports blocking get() with no way to chain or compose callbacks, while CompletableFuture supports non-blocking composition (thenApply, thenCombine) -- e.g. fanning out calls to multiple downstream services and combining results without blocking a thread on each.

Tests whether you know the four necessary conditions for deadlock and practical strategies to avoid them.

Tests whether you know calling .get() or .join() defeats the async design by blocking the calling thread, and that blocking calls inside callback stages (thenApply/thenCompose) without specifying an executor can starve the shared ForkJoinPool.commonPool().

Tests whether you know ForkJoinPool is a work-stealing ExecutorService variant built for divide-and-conquer recursive tasks, distinct from a general-purpose ExecutorService's fixed task queue and from manually managing raw Thread objects.

Tests whether you know volatile guarantees visibility, not atomicity — one of the most commonly misunderstood keywords.

Tests whether you know why managed thread pools beat manually creating and managing Thread objects in production code.

Tests whether you know Collections.synchronizedMap() wraps every operation in a single lock (coarser and slower than ConcurrentHashMap's striped locking) and that manual external synchronization is also required around iteration.

Tests whether you know Runnable.run() returns nothing and can't throw checked exceptions, while Callable<V>.call() returns a value and can throw checked exceptions -- which is exactly why ExecutorService.submit() with a Callable gives you a Future you can inspect for both result and failure.

Tests whether you can correctly write the volatile + double-checked-locking pattern, a classic concurrency coding question.

Tests whether you know start() allocates a new OS/native thread and the JVM eventually calls run() on it, while calling run() directly just executes the code synchronously on the current thread -- a classic 'runs but doesn't actually thread' bug.

Tests whether you know @Async is a proxy-based abstraction that still delegates to an underlying Executor (often the default SimpleAsyncTaskExecutor, which doesn't pool), so misconfiguring it can silently spawn an unbounded thread per call unlike an explicitly sized pool.

Tests whether you know wait() releases the object's monitor and must be called inside synchronized code (used for inter-thread signaling), sleep() holds any locks it has and just pauses the current thread, and join() blocks the calling thread until the target thread finishes.

Tests whether you know the first 8 tasks run immediately while the rest queue up to the work queue's capacity, and that further submissions trigger the configured RejectedExecutionHandler once both the pool and queue are full.

Tests whether you understand the formal rules that govern visibility and ordering across threads — deep concurrency territory.

Tests whether you know how to chain and combine async operations rather than blocking with Future.get().

Tests whether you know volatile only guarantees visibility of single reads/writes, not atomicity of compound operations like increment, while AtomicInteger uses CAS to make read-modify-write atomic.

Tests whether you describe it as mutual exclusion via a monitor lock on an object, enforcing that only one thread executes a critical section at a time -- and that it also establishes a happens-before relationship for visibility, not just atomicity.

Tests whether you know the compiler, JIT, and CPU are all free to reorder instructions that have no data dependency on each other for performance, and that memory barriers (which volatile and synchronized insert) are the explicit fences that prevent specific reorderings across a thread-visibility boundary.

Tests whether you know a process has its own isolated memory space and is heavier to create/switch, while threads within a process share the same heap and address space, making communication cheap but requiring explicit synchronization.

Tests whether you can decompose count++ into its actual three steps (read, increment, write) and explain that two threads interleaving between those steps can both read the same value and both write back the same increment, silently losing an update -- the canonical read-modify-write race.

Tests whether you know volatile only guarantees visibility (reads always see the latest write) and prevents instruction reordering around it, but gives no atomicity for compound operations -- so it's right for simple flags/status fields, not for counters or anything needing read-modify-write.

Tests whether you know the monitor model precisely -- one thread owns the lock at a time, other lock-seekers queue in the entry set, threads that called wait() move to the wait set until notified, and the owning thread can re-acquire its own lock without blocking, which is what makes nested synchronized calls on the same object safe.

Tests whether you place each on the right trade-off curve: synchronized is simple JVM-managed mutual exclusion, Lock (ReentrantLock) adds tryLock/fairness/interruptibility at the cost of manual unlock discipline, and Atomic classes use lock-free CAS for the fastest path when only a single variable's atomicity matters.

Tests whether you know an object whose state can't change after construction is inherently thread-safe -- no synchronization is needed because there's no mutation for threads to race on.

Tests whether you'd pull a thread dump and look for the 'Found one Java-level deadlock' block showing the circular lock-wait chain, and whether you know prevention means consistent lock ordering across the codebase rather than retry-and-hope.

Tests whether you describe it as the thread-pool abstraction that decouples task submission from thread lifecycle management, letting you reuse a bounded pool of threads instead of paying the cost of creating a new OS thread per task.

Tests whether you know AtomicInteger's lock-free CAS loop outperforms synchronized under high contention for simple single-variable updates, while synchronized is still needed when multiple related fields must change together atomically.

Tests whether you define it precisely as the outcome depending on the unpredictable timing/interleaving of concurrent thread execution on shared mutable state -- not just 'two threads running at the same time'.

Tests whether you know implementing Runnable (and passing it to a Thread) decouples the task from Java's single-inheritance limit and lets the same task be reused across executors, unlike extending Thread directly.

Tests whether you know submit() swallows the exception into the returned Future until you call get() (which rethrows it wrapped in ExecutionException), while execute() with a Runnable sends it straight to the thread's uncaught exception handler -- a silent-failure trap if you never check the Future.

Tests whether you know a synchronized instance method locks on 'this' (so different instances don't block each other), while a synchronized static method locks on the Class object (shared across every instance) -- mixing the two in a scenario means an instance-method call and a static-method call can run concurrently on the same data without ever actually excluding each other.

Tests whether you know an exception from a void @Async method is swallowed by the default AsyncUncaughtExceptionHandler and logged, not propagated to the caller, so you need a custom handler or a Future-returning method to observe it.

Tests whether you know new tasks queue up (if a bounded queue has room) or get rejected via the RejectedExecutionHandler once both the pool and queue are full -- and that an unbounded queue just defers the problem into an OOM instead of solving it.

Tests whether you connect it to context-switching overhead and cache thrashing once thread count exceeds available cores by a wide margin, plus the memory cost of each thread's stack -- more threads than the workload can parallelize just adds scheduling overhead.

Tests whether you know MDC is backed by a ThreadLocal, so context set on the request thread doesn't automatically appear on a worker thread -- it must be explicitly copied (or propagated via a TaskDecorator) when handing off work.

Tests whether you reach for non-blocking I/O (WebFlux/Netty) or Java 21 virtual threads to decouple concurrent requests from a 1:1 OS-thread cost, rather than assuming you can just size a traditional thread pool to 10,000.

Tests whether you'd take a thread dump and look for the thread holding the monitor that the BLOCKED thread is waiting on, then trace why that holder never releases it (often a lock held across a slow I/O or network call).

Tests whether you default to avoiding shared mutable state first (stateless beans, immutable DTOs, request-scoped data) before reaching for synchronization primitives, since the cheapest thread-safety is state you never had to protect.

Tests whether you know Spring's TaskExecutor abstraction lets you swap thread-pool implementations via configuration and integrates with Spring's lifecycle/context propagation, which a manually created ExecutorService doesn't get for free.

Tests whether you know an unbounded queue never triggers rejection or backpressure -- tasks just keep piling up in memory, so the system looks fine until the queue itself exhausts the heap, far later than when it actually became overloaded.

Tests whether you suspect threads blocked waiting -- on I/O, lock contention, GC pauses, or a slow downstream dependency -- since low CPU with high latency almost always points to waiting, not computing, and a thread dump confirms where.

Tests whether you know CPU-bound pools should be sized near the core count (more threads just add context-switch overhead), while I/O-bound pools can be sized much larger since threads spend most of their time blocked, not competing for CPU.

Tests whether you know a second thread can see a partially-constructed object -- without volatile, the JIT/JVM can reorder the reference assignment ahead of the constructor finishing, so the null-check passes but the fields aren't initialized yet.

Tests whether you know pooled threads are reused across tasks, so a ThreadLocal set by one task silently leaks into the next task on that same thread unless you call threadLocal.remove() in a finally block when the task finishes.

Tests whether you name both the read-modify-write race (lost updates from interleaved increments) and the separate non-atomicity of a 64-bit long/double read-write on a 32-bit JVM, which can produce a torn value made of two different writes' halves.

Tests whether you know count++ is actually read-modify-write (three separate steps), and volatile only makes each individual read or write visible across threads -- it does nothing to stop two threads interleaving between those steps.

Tests whether you know an un-released ReentrantLock permanently starves every other thread waiting on it, since unlike synchronized blocks, it is never auto-released on exception -- so unlock() must be in finally to guarantee release regardless of how the critical section exits.

Tests whether you know lock() blocks indefinitely and ignores interrupts, tryLock() returns immediately (or after a timeout) with a boolean instead of blocking, and lockInterruptibly() blocks but responds to thread interruption -- each suited to a different deadlock-avoidance strategy.

Tests whether you know new ReentrantLock(true) enforces strict FIFO ordering to prevent thread starvation, at the cost of throughput -- fair locks have higher overhead and lower overall throughput than the default barging (unfair) mode under contention.

Tests whether you know ReentrantReadWriteLock's default non-fair mode lets new readers keep acquiring the shared lock as long as any reader holds it, so a steady stream of incoming readers can indefinitely delay a writer waiting for exclusive access.

Tests whether you know Java monitor locks are reentrant -- the same thread already holding the lock on that object can re-acquire it without deadlocking itself, with an internal hold count tracking nested acquisitions.

Tests whether you know independent variables written by different threads can still cause cache-line ping-ponging if they happen to share a CPU cache line, and that padding or @Contended is the fix even though there's no actual data race.

Tests whether you know a slow or hung network call turns a short critical section into an unbounded one, blocking every other thread waiting on that lock for as long as the network call takes -- effectively letting an external dependency's latency become your application's lock contention.

Tests whether you reach for tryLock(timeout) to fail fast and free the thread instead of waiting forever, bounding the blast radius of one stuck operation so it can't starve the rest of the application's threads.

Tests whether you understand volatile forces a write to flush from the writing CPU's cache (store barrier) and forces a read to invalidate and re-fetch from main memory (load barrier), rather than just treating it as a vague 'makes it thread-safe' keyword.

Tests whether you know lock escalation (common in DBs, but conceptually similar in-app) is the shift from fine-grained to coarser-grained locking to reduce overhead, and that over-applying it serializes work that could otherwise run concurrently, directly capping throughput.

Tests whether you can explain the CAS retry loop (read, compute, compare-and-swap, retry on failure) and know LongAdder outperforms AtomicInteger under heavy contention by striping the counter across cells and summing them only on read.

Tests whether you know deadlock risk isn't limited to one obvious method -- if class A locks X then Y while class B locks Y then X, in completely different call paths, you get a circular wait that only shows up under specific timing, invisible from reading either class alone.

Tests whether you know a sequential stream over a non-thread-safe collection is safe as long as the source isn't mutated during the stream, but a parallelStream() on the same collection needs a concurrent or externally synchronized source, or you'll get ConcurrentModificationException or corrupted results.

Tests whether you reach for DB-level guarantees (unique constraints, optimistic locking with a version column, idempotency keys) rather than in-JVM synchronization, since payment correctness must hold across multiple instances, not just one process.

Tests whether you know the trade-offs behind each Executors factory method -- fixed (bounded, steady load), cached (unbounded, bursty short tasks), single-threaded (serialized execution), and scheduled (delayed/periodic tasks) -- rather than treating them as interchangeable.

Tests whether you know synchronized only coordinates threads within a single JVM -- it has zero effect across 3 separate instances, each with its own lock, and it never protects database state since a second process can mutate the same row through a completely different lock.

Tests whether you know in-JVM locks only coordinate threads sharing the same memory, so multiple instances need an external coordination point (Redis, ZooKeeper, DB row lock) -- and that you should reach for one only when true cross-instance mutual exclusion is required, not as a default.

Tests whether you know the lock needs a TTL so a crashed holder's lock expires instead of deadlocking everyone forever, and whether you're aware of the clock-drift/failover edge cases (the motivation behind algorithms like Redlock) that make naive SETNX locking unsafe at scale.

Tests whether you systematically check layer by layer -- in-JVM synchronization (useless across instances), DB isolation level (read uncommitted/committed allows double-reads), missing unique constraints, and absent idempotency keys -- instead of assuming the bug is a classic in-memory race.

Tests whether you know BlockingQueue handles producer-consumer coordination internally (put() blocks when full, take() blocks when empty) so you don't hand-roll wait/notify, and can name a real use like a bounded work queue feeding a thread pool.

Tests whether you know ThreadLocal gives each thread its own isolated copy of a variable (common for per-request context like a DB connection or user session in a servlet thread), distinct from a shared field that would need synchronization.

volatile ensures every thread reads the latest written value (no stale caching) but does nothing to make a compound operation like count++ (read-modify-write) atomic — two threads can still both read the same value before either writes back, losing an update.

It partitions the map internally (historically into segments, now into per-bin locks in Java 8+) so different threads can operate on different parts of the map concurrently — only the specific bin being modified is locked, not the whole structure.

Tests whether you know a heap dump is a snapshot of live objects for diagnosing memory issues, while a thread dump is a snapshot of every thread's stack and state (RUNNABLE/BLOCKED/WAITING) for diagnosing deadlocks, contention, or hangs -- and that they're captured and analyzed differently.

Under high contention with many threads incrementing the same counter, AtomicInteger's single compare-and-swap variable becomes a bottleneck. LongAdder internally spreads updates across multiple cells and sums them only when you read the total, trading a slightly more expensive read for much cheaper concurrent writes.

CPU-bound: pool size ≈ number of CPU cores (more threads than cores just adds context-switching overhead). I/O-bound: pool size can be much larger than core count, since threads spend most of their time blocked waiting on I/O rather than actually using the CPU.

Tests whether you know CompletableFuture's async methods without an explicit Executor fall back to ForkJoinPool.commonPool() by default, which is shared process-wide and easily starved by blocking work -- a key reason to always pass a dedicated Executor in production code.

thenApply() transforms the result with a plain function. thenCompose() chains to ANOTHER CompletableFuture-returning function (flattens nested futures, like flatMap). thenCombine() waits for two independent futures and combines both results together.

Look for the small number of threads actually holding the contested lock (state RUNNABLE or waiting on I/O) versus the many threads BLOCKED waiting for it — that lock holder, and what it's doing (a slow query, an external call), is almost always the actual bottleneck, not the blocked threads themselves.

Tests whether you can place each by its signature shape -- Predicate<T> takes a value and returns boolean, Function<T,R> takes a value and returns a different type, Consumer<T> takes a value and returns nothing, Supplier<T> takes nothing and returns a value -- the four shapes that cover almost every functional-interface use case in the JDK.

Tests whether you can name the features that actually changed how Java code is written -- lambdas, the Stream API, default/static interface methods, Optional, and the new java.time package -- rather than a vague 'it added functional programming'.

Tests whether you reach for Collectors.groupingBy(Employee::getDepartment, Collectors.maxBy(Comparator.comparing(Employee::getSalary))) -- a downstream collector nested inside groupingBy -- rather than grouping first and then iterating each group manually to find the max.

Tests whether you know map() transforms each element 1:1 (possibly producing a stream of streams), while flatMap() transforms and then flattens nested structures into a single stream -- the mechanism you need whenever each input maps to zero or more outputs.

Tests whether you understand intermediate operations (filter, map) are lazy and just build a pipeline description, while a terminal operation (collect, forEach) is what actually triggers execution -- nothing runs until a terminal op is called.

Tests whether you can nest a per-group sort/distinct/skip pipeline inside groupingBy's downstream collector to get the second value within each group, rather than only knowing how to find the second-highest across a flat list.

Tests whether you know a functional interface has exactly one abstract method (a lambda target, e.g. Runnable), while a marker interface has no methods at all and exists purely to tag a class for reflective or runtime checks (e.g. Serializable).

Tests whether you know a Java Stream is single-use -- once a terminal operation consumes it, calling another operation on the same stream throws IllegalStateException, because streams model a one-time traversal, not a reusable collection.

Tests whether you go beyond 'cleaner code' to name declarative pipeline composition, built-in laziness that avoids unnecessary work, and easy parallelization via parallelStream() without manually managing threads.

Tests whether you know records are compiler-generated immutable data carriers that automatically get equals(), hashCode(), and toString() derived from their components -- so two records with identical component values are equal, unlike a plain class where you'd have to write that logic yourself.

Tests whether you can explain lambdas as syntactic sugar for implementing a functional interface inline, and Streams as the API built on top of lambdas to express data processing as a declarative pipeline instead of imperative loops.

Tests whether you know a Collection is an in-memory data structure you store elements in, while a Stream is a view over a data source that computes elements on demand and doesn't store anything itself -- it describes a computation, not storage.

Tests whether you know intermediate operations only build up a pipeline of transformations without executing, and the entire chain runs element-by-element only when a terminal operation pulls a result -- which is why short-circuiting ops like findFirst() can skip most of the data entirely.

Tests whether you can place each in the pipeline correctly: filter() selects elements by a predicate, map() transforms each element's value, and reduce() is the terminal fold that combines all elements into a single accumulated result.

Tests whether you can chain filter().sorted(Comparator.comparingInt(String::length)).limit(3) correctly in one readable pipeline, understanding that limit() after sorted() is what actually bounds the result to the top N.

Tests whether you know findFirst() guarantees the encounter-order element even in a parallel stream (at the cost of synchronization), while findAny() makes no ordering guarantee and can return as soon as any thread finds a match, making it faster in parallel.

Tests whether you know distinct() relies on equals()/hashCode() to filter duplicates (using a HashSet-like mechanism internally), so it only works correctly if those methods are implemented consistently on the element type.

Tests whether you reach for sorted(Comparator.comparing(...)) and chain .thenComparing() for multi-field sorts, rather than writing a manual Comparator class for something the Stream API already composes declaratively.

Tests whether you know groupingBy() produces an arbitrary-keyed Map (often with a downstream collector for counting/aggregating per group), while partitioningBy() is the special case that always produces exactly two buckets keyed by a boolean predicate.

Tests whether you know Stream.toList() (Java 16+) returns an unmodifiable list with less boilerplate, while Collectors.toList() makes no guarantee about mutability or the exact List implementation -- a subtle API contract difference, not just a shorthand.

Tests whether you know parallelStream() splits work across ForkJoinPool.commonPool() threads using the Spliterator abstraction, and that this only pays off for large datasets with CPU-bound, stateless, non-ordered work -- not for small collections or I/O-bound tasks.

Tests whether you reach for a self-join on the matching columns with a row-identity inequality (or a window function like ROW_NUMBER() OVER (PARTITION BY ...)) to flag duplicates, showing you know more than one way to express 'duplicate' in SQL beyond the obvious GROUP BY + HAVING COUNT(*) > 1.

Tests whether you know to avoid it for small collections (splitting/merging overhead exceeds the gain), I/O-bound work (it shares the same commonPool as other parallel streams app-wide, so one blocking call starves everyone), and operations needing strict ordering or mutable shared state.

Tests whether you reach for Collectors.groupingBy(Function.identity(), Collectors.counting()) for frequency/duplicates, and sorted().distinct().skip(n-1).findFirst() (or a bounded approach) for the nth-highest, rather than sorting the whole dataset unnecessarily.

Tests whether you profile before guessing -- checking for accidental boxing/unboxing, unnecessary intermediate collection materialization, misuse of parallelStream() on I/O-bound work, and whether a plain loop would actually be faster for the data size involved.

Tests whether you reach for entrySet().stream().sorted(Map.Entry.comparingByValue()) and collect into a LinkedHashMap to preserve the sorted order, since a Map itself has no inherent sort-by-value operation and a regular HashMap wouldn't retain any ordering you impose on it.

Tests whether you look for the specific shape records demand -- immutable data carriers with only a constructor, getters, and generated equals/hashCode/toString, and no additional mutable state or inheritance from another class -- since classes with business logic, mutability, or an existing class hierarchy aren't good candidates.

Tests whether you weigh the real trade-off -- records cut boilerplate and guarantee immutability for DTOs/value objects, but their immutability and inability to extend another class make them a poor fit for entities with mutable state, JPA proxying needs, or evolving inheritance hierarchies.

Tests whether you know Java 7's ConcurrentHashMap used segment-level locking (a fixed array of locks, each guarding a slice of the table), while Java 8 moved to per-bucket synchronization combined with CAS operations on individual bins -- finer-grained locking that improves concurrency, plus the same bucket-treeification HashMap gained.

Tests whether you can name what actually changed between the two LTS releases -- virtual threads (Project Loom) for cheap massive concurrency, sequenced collections giving a consistent first()/last() API across ordered types, and expanded pattern matching for switch -- rather than treating 17 and 21 as interchangeable 'modern Java.'

Tests whether you know a stream pipeline is built from a source Spliterator plus a chain of stateless operation wrappers, and that it only actually iterates once a terminal operation pulls elements through the whole chain one at a time -- it's not a series of independent passes over intermediate collections.

Tests whether you chain groupingBy (to aggregate per client) with a downstream summing collector, then sort the resulting map's entries by value and limit(3) -- a two-stage pipeline (aggregate, then rank) rather than trying to do both in a single pass.

Tests whether you know the single-abstract-method rule only counts methods that aren't already implementations of java.lang.Object's public methods -- redeclaring equals()/toString() as abstract doesn't add a second SAM, and default methods never count as abstract, so the interface is still a valid functional interface.

Tests whether you reach for Map.merge(account, amount, Integer::sum) to fold transactions into running balances in a single O(n) pass, rather than grouping transactions first and summing each group separately in a second pass.

Tests whether you know binary data needs byte streams while text data is better handled by character-aware Reader/Writer classes.

Tests whether you know buffering reduces the number of expensive underlying I/O calls by reading in larger chunks.

Tests whether you know NIO's channel/buffer model and selectors enable non-blocking I/O that classic java.io can't do.

Tests whether you know try-with-resources guarantees close() is called correctly even when multiple exceptions occur, which manual finally blocks often get wrong.

A List is an ordered collection that allows duplicate elements and lets you access items by index (get(i)); a Set is an unordered collection (except LinkedHashSet/TreeSet) that does not allow duplicates, enforced via equals()/hashCode(). Choose List when order and duplicates matter, Set when uniqueness is the requirement.

HashSet offers O(1) average add/contains but no ordering guarantee; LinkedHashSet preserves insertion order at a small extra memory cost (a backing linked list); TreeSet keeps elements sorted (natural order or a Comparator) at O(log n) per operation, backed by a red-black tree. Pick based on whether you need speed, insertion order, or sorted order.

CopyOnWriteArraySet is a thread-safe Set backed by a CopyOnWriteArrayList — every mutation copies the entire underlying array, so reads never block and never throw ConcurrentModificationException, but writes are expensive and it scales poorly for write-heavy or large collections. A plain HashSet is not thread-safe at all and needs external synchronization (or Collections.synchronizedSet) for concurrent access.

Comparable is implemented by the class itself via compareTo(), defining one single 'natural' ordering (e.g., a Product sorting by its own ID); Comparator is a separate object implementing compare(a, b), letting you define multiple, external, interchangeable orderings for the same class (e.g., sort Products by price, then by name) without modifying the class itself.

Collection (singular) is the root interface of the collections hierarchy — List, Set, and Queue all extend it, and it defines the core contract (add, remove, size, iterator). Collections (plural) is a utility class full of static helper methods that operate ON collections — sort(), reverse(), unmodifiableList(), synchronizedList(), and so on.

The Collections Framework is about storing and organizing data in memory (List, Set, Map and their implementations); the Streams API is about processing that data declaratively — filtering, transforming, and aggregating a sequence of elements without manually writing loops. A Stream isn't a data structure at all; it's a pipeline computed lazily over a source, most commonly a Collection.

Tests whether you have a clear mental map of Java's core collection interfaces and how they relate to each other.

One of the most-asked Java questions — tests whether you actually understand hashing, bucket placement, and collision resolution, not just usage.

Tests whether you know the thread-safety, null-key, and performance differences between these two legacy-adjacent classes.

Tests whether you know to check hashCode() quality, load factor, and whether entries are treeifying due to collisions.

Tests whether you understand segment/bucket-level locking and why it beats simply synchronizing a whole HashMap.

Tests whether you know a changed hashCode() after insertion makes the entry effectively unfindable at its original bucket.

Tests whether you know why ConcurrentModificationException happens and which collections avoid it, and how.

A very common coding-round question testing whether you know LinkedHashMap's access-order mode and removeEldestEntry hook.

Tests whether you know every single write copies the entire underlying array, which is brutal for write-heavy or large lists.

Tests whether you understand the resize trigger, the doubling behavior, and why rehashing is expensive.

Tests whether you know this exception is about structural modification during iteration, not literally about concurrent threads.

Tests whether you can weigh whole-map locking against ConcurrentHashMap's finer-grained concurrency for the actual access pattern.

Tests whether you know a constant or low-quality hashCode collapses lookups from O(1) toward O(n) by funneling everything into one bucket.

Tests whether you know ConcurrentHashMap guarantees the mapping function runs atomically per key, avoiding duplicate computation.

Tests whether you know EnumMap uses ordinal-based array indexing instead of general-purpose hashing.

Tests whether you know to pair a frequency HashMap with a bounded PriorityQueue instead of sorting everything.

Tests whether you know WeakHashMap lets the garbage collector reclaim entries whose keys have become otherwise unreachable.

Almost always ArrayList — get(index) is O(1) vs O(n) for LinkedList, and contiguous memory gives far better CPU cache locality (a real benchmark: getting a middle element from 10 million items takes ~1ms on ArrayList vs ~125ms on LinkedList). LinkedList only wins for frequent inserts/removals at the head.

Equal objects (per equals()) must have equal hash codes, and a hash code must stay consistent within one JVM run. If you override equals() without hashCode(), logically equal objects can land in different HashMap buckets, making get() fail to find entries that should match.

TreeMap when you need keys in sorted order (O(log n), definitely slower than HashMap); LinkedHashMap when you need to preserve insertion order while keeping HashMap's O(1) average lookup, just with a small extra pointer-overhead per entry.

Tests whether you can parallelize a reduction correctly -- splitting rows across threads, computing partial maxima independently, then combining results without a shared mutable variable causing races.

Tests whether you pick the right concurrent structure for scheduling (a DelayQueue or PriorityBlockingQueue plus a worker thread) and avoid busy-waiting by blocking on the next task's due time.

Tests whether you can justify an algorithm choice (token bucket vs sliding window log vs sliding window counter) on accuracy-vs-memory trade-offs, then design the shared-state coordination (Redis + Lua script for atomicity) across nodes.

Tests whether you can implement producer/consumer blocking correctly with wait()/notifyAll() (or a Condition) on a fixed-capacity buffer, then wire worker threads to pull from it without using any java.util.concurrent executor.

Tests whether you recognize this as a bounded-resource admission problem needing fairness (e.g., a semaphore plus a FIFO wait queue) so that a steady stream of new arrivals can't indefinitely starve players already waiting.

Tests whether you can design tiered locking (a ReadWriteLock-like scheme) where searches share a read lock, inserts take an exclusive insert lock, and deletes escalate to block every other operation -- matching each operation's actual conflict requirements.

Tests whether you know RandomAccessFile (or FileChannel.read/write with an explicit position) lets multiple threads operate on disjoint byte ranges of the same file concurrently without a shared file pointer causing interference.

Tests whether you can design clean object boundaries (User, Tweet, a follow graph) and implement getNewsFeed as a k-way merge of each followee's tweets by timestamp, rather than sorting the full combined list each call.

Tests whether you can model trains and platforms as an interval-scheduling/allocation problem and produce a complete, compiling solution under real time pressure rather than a half-finished sketch.

Tests whether you can design a pull model (consumers poll/claim messages) with correct offset or claim tracking per consumer, avoiding the same message being delivered twice under concurrent pulls.

Tests whether you model the filesystem as an in-memory tree of directory nodes with parent pointers (for cd .. and pwd), and implement wildcard matching for cd as pattern matching over sibling directory names.

Tests whether you know the main thread must join() both worker threads (or get() both Futures) before reading their results, since reading shared variables without that happens-before edge risks seeing stale or partial values.

Tests whether you can design the Player/MatchResult relationship so a single MatchResult correctly reports WIN for one player and LOSS for the other from each player's perspective, and can root-cause a failing test against that symmetry rather than just patching the assertion.

Tests whether you know an enum is really a special class with a fixed set of singleton instances, not just a list of named integers.

Tests whether you know enums are full classes that can carry state and even constant-specific method bodies.

Tests whether you know enums give you type safety and namespace clarity that plain int or String constants don't.

Tests whether you know the actual design reasons (security, caching, thread safety) behind one of Java's most quoted facts.

Tests whether you understand where string literals actually live in memory and why that affects == comparisons.

Tests whether you know the mutability and thread-safety tradeoffs behind these three near-identical-looking classes.

A classic string DSA problem testing whether you can move from brute force to an efficient expand-around-center or DP approach.

Tests whether you can apply the sliding-window technique correctly to a genuinely tricky two-pointer problem.

Strings are immutable, so `result = result + i` in a loop creates a brand-new String object every iteration — use StringBuilder instead. Java 9+ does optimize a single-expression concatenation like `"Hello " + name` via invokedynamic to be nearly as fast as StringBuilder, but this doesn't help multi-statement loops.

private restricts access to within the same class; default (no modifier) allows access within the same package; protected allows access within the package plus subclasses in other packages; public allows access from anywhere. Choosing the narrowest modifier that still works is the standard encapsulation practice.

this refers to the current object instance — used to disambiguate a field from a same-named constructor parameter, or to call another constructor in the same class (this(...)). super refers to the immediate parent class — used to call the parent's constructor (super(...)) or to access a parent's overridden method/field explicitly.

No — final prevents a method from being overridden, but constructors are never inherited or overridden in the first place, so final on a constructor is meaningless and won't compile. static implies belonging to the class rather than an instance, but a constructor's entire job is to initialize a specific instance, so static is equally disallowed.

No. Private methods aren't inherited at all, so a same-named method in a subclass is a completely new, unrelated method, not an override. Static methods belong to the class, not an instance, so a same-named static method in a subclass hides the parent's version (resolved at compile time based on the reference type) rather than overriding it (which is resolved at runtime based on the actual object type).

A marker interface has no methods or fields at all — its only purpose is to 'tag' a class so that other code (often via instanceof or reflection) can check for that tag and change behavior accordingly. Serializable and Cloneable are classic examples — implementing them signals intent to the JVM without requiring any method implementation (annotations have largely replaced this pattern in modern Java).

Yes, using multi-catch syntax introduced in Java 7: catch (IOException | SQLException e) { ... } — this avoids duplicating the same handling logic across multiple catch blocks. The caveat: the exception types in a multi-catch can't be related by inheritance (you can't combine a class and its own subclass), and the resulting variable e is implicitly final.

Only if the functional interface's abstract method itself declares that checked exception in its throws clause — most built-in interfaces like Function or Consumer don't, so a lambda implementing them can't throw a checked exception directly and must either catch it internally, wrap it in an unchecked exception, or use a custom functional interface that declares the checked exception.

No — calling start() a second time on the same Thread instance throws IllegalThreadStateException. Once a thread has run and terminated, that Thread object is permanently done; to run the same task again you need to create a brand-new Thread instance (or, better, resubmit the task to an ExecutorService, which reuses pooled threads under the hood).

Tests whether you know the fixed-size-vs-dynamic and primitive-vs-object tradeoffs between the two.

Tests whether you know the classic O(n) dynamic programming trick, not just a brute-force O(n²) scan.

Tests whether you can sort in a single O(n) pass with three pointers instead of a generic sort or two passes.

A well-known hard array problem testing two-pointer or prefix-max/suffix-max thinking under a tricky constraint.

Tests whether you know both the O(n²) DP solution and the O(n log n) patience-sorting-based approach.

Extend the Thread class and override run(), or implement the Runnable interface and pass it to a Thread constructor (preferred, since Java doesn't support multiple inheritance and implementing Runnable keeps the class free to extend something else). A third, more modern approach is submitting a Runnable/Callable to an ExecutorService, which manages the thread lifecycle for you.

NEW (created but not started), RUNNABLE (executing or ready to execute — the JVM doesn't distinguish 'running' from 'ready' as a separate state), BLOCKED (waiting to acquire a lock), WAITING (waiting indefinitely for another thread's signal, e.g. via join() or wait()), TIMED_WAITING (waiting with a timeout, e.g. sleep(ms)), and TERMINATED (finished execution). Thread.getState() returns exactly one of these six values at any point.

Runnable's run() method returns nothing and can't throw a checked exception; Callable's call() method returns a value of a generic type V and CAN throw a checked exception. Callable is submitted to an ExecutorService and returns a Future<V> that lets the caller retrieve the result (or exception) once the task completes.

A method reference is shorthand for a lambda that just calls an existing method — written as Class::method. The 4 types are: a static method (String::valueOf), an instance method on a particular object (someList::add), an instance method on an arbitrary object of a type (String::toUpperCase, where the object becomes the first parameter), and a constructor reference (ArrayList::new).

groupingBy() collects stream elements into a Map, where a classifier function you supply determines the key for each element and all elements mapping to the same key are collected into a List under that key by default. For example, employees.stream().collect(Collectors.groupingBy(Employee::getDepartment)) produces a Map<String, List<Employee>> grouping employees by department; a second argument (a downstream collector) can further reduce each group, e.g. to a count or an average.

Function<T, R> represents a function that takes one argument of type T and returns a result of type R, via its single abstract method R apply(T t). It's the go-to interface for transformation logic — e.g. Function<String, Integer> length = String::length — and is what Stream.map() expects as its argument.

Predicate<T> represents a boolean-valued test on a single argument, via its abstract method boolean test(T t). It's the interface Stream.filter() and List.removeIf() expect, and it exposes default methods and(), or(), and negate() for composing multiple conditions, e.g. isAdult.and(isVerified).

Supplier<T> takes no arguments and returns a value of type T, via its abstract method T get(). It's used for lazy or deferred value generation — e.g. Optional.orElseGet(supplier), where the supplier is only invoked if the Optional is actually empty, avoiding unnecessary work compared to orElse(), which always evaluates its argument eagerly.

Consumer<T> takes one argument and returns nothing, via its abstract method void accept(T t) — it's for operations performed purely for their side effects, like printing or saving. It's the interface Stream.forEach() and List.forEach() expect, and its andThen() default method lets you chain multiple consumers to run in sequence on the same input.

They are the two-argument counterparts of Function, Predicate, and Consumer: BiFunction<T, U, R> takes two arguments and returns a result, BiPredicate<T, U> takes two arguments and returns a boolean, and BiConsumer<T, U> takes two arguments and returns nothing. A common use is Map.forEach(BiConsumer<K, V>), which receives both the key and value of each entry.

UnaryOperator<T> is a specialization of Function<T, T> where the input and output types are the same — used for operations like String::toUpperCase that transform a value into the same type. BinaryOperator<T> is a specialization of BiFunction<T, T, T> for combining two values of the same type into one, which is exactly the shape Stream.reduce() expects (e.g. Integer::sum).

Primitive functional interfaces — IntPredicate, IntFunction, IntConsumer, IntSupplier, and their long/double equivalents — are specialized versions of the generic functional interfaces built specifically for int, long, and double. They exist purely for performance: using a generic Function<Integer, R> would autobox every int into an Integer object, creating unnecessary object overhead in hot loops, whereas IntFunction<R> operates directly on the primitive with no boxing.

filter() takes a Predicate and returns a new stream containing only the elements that satisfy it — it never changes the number of elements' TYPE, only how many pass through. map() takes a Function and transforms every element into something else, keeping the same count but potentially changing the type — the two are commonly chained, e.g. filter then map to select and transform in one pipeline.

collect() is a terminal operation that gathers the stream's elements into a final result — a List, Set, Map, or a custom accumulation — using a Collector like Collectors.toList() or Collectors.joining(). forEach() is also terminal but performs a side-effecting action (like printing) per element and returns nothing; use collect() when you need a data structure back, forEach() when you just need to act on each element.

distinct() returns a stream with duplicate elements removed, determining uniqueness via each element's equals() (and, for hashing efficiency, hashCode()) method. For custom objects, this means distinct() only works correctly if equals()/hashCode() are properly overridden — otherwise it falls back to default object-identity comparison and won't remove logically-equal-but-distinct-instance duplicates.

limit(n) truncates the stream to at most the first n elements, useful for pagination or top-N results. skip(n) discards the first n elements and returns the rest — combining skip(offset).limit(pageSize) is a common pattern for implementing simple in-memory pagination over a stream.

count() is a terminal operation that returns the number of elements in the stream as a long. Chained after filter(), e.g. list.stream().filter(p).count(), it's an efficient way to count how many elements satisfy a condition — Java's Stream implementation can even skip actually materializing elements in some cases, computing the count more efficiently than a full iteration when the pipeline allows it.

All three are short-circuiting terminal operations that take a Predicate and return a boolean: anyMatch() returns true if AT LEAST ONE element satisfies it, allMatch() returns true only if EVERY element satisfies it, and noneMatch() returns true if NO element satisfies it. Being short-circuiting means they stop processing the stream the instant the answer is determined, rather than always scanning every element.

Tests whether you can name and briefly explain lambdas, streams, Optional, and the new Date/Time API.

Tests whether you understand the single-abstract-method rule that makes lambda expressions possible.

Tests whether you understand when a stream operation needs to flatten nested structures, not just transform elements.

Tests whether you know how to use Optional correctly, and the common anti-patterns that misuse it.

Tests whether you understand that intermediate operations don't execute until a terminal operation triggers the pipeline.

For small collections or complex multi-step transformations, Stream's pipeline setup overhead can exceed a simple loop's cost — one real benchmark showed a complex stream at 174ms versus a plain loop's baseline, while a parallelStream() version was actually the fastest at 23ms when CPU cores were available.

Tests whether you know which exceptions the compiler forces you to handle and why that distinction exists.

Tests whether you know how AutoCloseable resources get closed automatically, and in what order during suppressed exceptions.

Tests whether you can design exception classes correctly and know when each type is the right choice.

Tests whether you know how to preserve the original cause when wrapping and rethrowing a different exception type.

Tests whether you know these are thrown at different times for different reasons, despite sounding like the same problem.

Tests whether you know records give you shallow immutability for their own fields, not deep immutability of referenced objects.

Tests whether you know sealed types let you declare an exhaustive, closed set of permitted subtypes at compile time.

Tests whether you know how it eliminates the manual instanceof-and-cast boilerplate switch statements used to require.

Tests whether you know this new interface finally gives a consistent way to access first/last elements across ordered collection types.

Tests whether you understand the mechanism that lets thousands of virtual threads share a small pool of OS carrier threads.

Tests whether you know var is fine when the type is obvious from context, but can obscure intent when it isn't.

Tests whether you're current on recent JVM changes and know what shrinking object headers actually saves in practice.

Tests whether you can recognize when a shrinking/growing window beats a brute-force nested loop.

Tests whether you know how converging pointers from both ends of a sorted structure eliminate redundant comparisons.

Tests whether you know Floyd's algorithm and why two pointers moving at different speeds must eventually meet in a cycle.

Tests whether you know to sort by start time first, then merge in a single linear pass.

Tests whether you know a bounded heap gets you the top K in O(n log k) instead of paying for a full O(n log n) sort.

Tests whether you can recognize the include-or-exclude decision structure that generalizes to many DP problems.

Tests whether you know how to order nodes in a DAG so every dependency is processed before what depends on it.

Tests whether you know to maintain a fixed-size min-heap instead of re-sorting on every new element.

Tests whether you can design a harder variant of LRU that also tracks access frequency, not just recency.

Tests whether you know the two-heap technique (a max-heap and a min-heap balanced against each other) for this classic problem.

Tests whether you know to model this as a graph shortest-path problem and solve it with BFS.

One of the most common coding-round openers — tests whether you can manipulate pointers correctly without losing the list.

Tests whether you know Floyd's cycle detection (slow/fast pointer) technique.

Tests whether you can combine a hash map and a doubly linked list to get O(1) get/put with eviction.

Tests whether you can implement preorder, inorder, postorder, and level-order traversal, iteratively and recursively.

Tests whether you know the common mistake of only checking immediate children instead of the full valid range.

Tests whether you can implement the classic priority-queue-based shortest path algorithm and explain its greedy correctness.

Tests whether you know how to order a DAG's nodes using DFS-based or Kahn's BFS-based approach.

Tests whether you know Enterprise JavaBeans is a server-managed component model for building distributed, transactional business logic inside a Java EE application server, which handled concerns like transactions, security, and pooling declaratively before frameworks like Spring largely replaced it for new development.

Tests whether you can distinguish Session Beans (stateless or stateful, for business logic), Entity Beans (legacy persistence representation, since replaced by JPA), and Message-Driven Beans (asynchronous JMS message consumers) -- the three component categories the spec defined, each solving a different kind of server-side concern.

Tests whether you connect degrading query performance to missing indexes on filtered/joined columns, and whether you can explain the mechanism -- a B-tree structure that lets the engine binary-search down to matching rows instead of scanning the whole table -- rather than just asserting 'add an index' without knowing why it helps.

Tests whether you can implement Singleton correctly and know the ways it can accidentally be broken.

Tests whether you know when a growing list of constructor parameters should become a Builder instead.

Tests whether you can name and briefly explain all 5 SOLID principles with a one-line example each.

Tests whether you stream the upload in fixed-size chunks (via InputStream/NIO channels straight to disk or object storage) instead of buffering the whole file into a byte array, which would blow the heap regardless of its size.

Tests whether you know every Java object's header carries a mark word (hash code, GC age, and lock state bits) plus a class pointer to its Klass metadata, and that this fixed overhead is why tiny objects are surprisingly expensive in bulk.

Tests whether you know each thread gets a Thread-Local Allocation Buffer carved out of Eden so most object allocation is a lock-free bump-the-pointer operation, avoiding contention on the shared heap for the common case.

Tests whether you know the generational hypothesis (most objects die young) drives this split -- Young Gen is collected frequently and cheaply with a copying collector, while Old Gen holds long-lived survivors and is collected less often but more expensively.

Tests whether you know the JIT can prove an object never escapes its allocating method/thread and then replace it with its individual fields as scalars -- eliminating the heap allocation entirely rather than just optimizing around it.

Tests whether you know GC roots (local variables on the stack, static fields, active JNI references) are the starting points for reachability, and that anything unreachable from a GC root -- even in a cycle -- becomes eligible for collection.

Tests whether you know a Java 'leak' isn't about forgetting to free memory -- it's an object staying reachable from a GC root (a static collection, a forgotten listener, an unclosed resource) long after it's logically done, so GC correctly refuses to collect it.

Tests whether you know a cache with no eviction policy or size bound is functionally a memory leak -- every entry stays reachable forever -- and that the fix is a bounded cache with an eviction strategy (LRU, TTL, or a weak-reference-based cache).

Tests whether you know a long-lived publisher holding a strong reference to a listener keeps the listener's owning object (and everything it references) alive even after that object should be discarded, unless the listener is explicitly unregistered or held weakly.

Tests whether you know high memory usage can be legitimate (large but bounded working set) while a leak is memory that keeps growing over time without bound -- distinguishing them requires watching the trend across GC cycles, not a single snapshot.

Tests whether you know OutOfMemoryError means the heap (or metaspace) is exhausted by live objects, while StackOverflowError means a single thread's call stack exceeded its fixed size -- almost always from unbounded or runaway recursion.

Tests whether you know to start from the biggest objects by retained size, walk their dominator tree to find what's holding them alive, and trace that chain back to a GC root rather than just eyeballing the largest individual object.

Tests whether you know a dominator tree restructures the object graph so each object's parent is the single object that, if removed, would make it unreachable -- which is what lets a heap analyzer attribute retained memory to one true owner instead of double-counting shared references.

Tests whether you know retained size is the memory that would actually be freed if an object were garbage collected (itself plus everything only it keeps alive), which is why it's the number to sort by, not shallow size.

Tests whether you know line coverage (which lines executed) is only one coverage metric, and can push back on using it alone as a quality signal since it says nothing about branch or condition coverage within those lines.

Tests whether you'd identify the specific untested branches the coverage gate is flagging and write targeted tests for them, rather than padding coverage with low-value tests just to clear the threshold.

Tests whether you know verify(mock, times(2)).method(...) is the right API, and that plain verify() without times() only asserts exactly one invocation.

Tests whether you know PowerMock exists specifically to mock what standard Mockito can't -- static methods, final classes, constructors, and private methods -- and that its need often signals code that's hard to unit test and could be refactored instead.

Tests whether you'd separate correctness/design concerns (logic bugs, missing tests, API shape) from style nits, and review for intent against the ticket rather than just scanning the diff line by line.

Tests whether you know integration tests verify multiple components working together against real infrastructure (often a test container DB), and whether you'd wrap each test in a transaction that rolls back afterward so tests stay isolated and repeatable without manual cleanup.

Tests whether you know TestNG's edge for automation comes from built-in parallel execution, flexible test grouping/dependencies, and native data-provider support for parameterized suites -- features JUnit historically needed extensions to match.

Tests whether you can describe a concrete structure -- Page Object Model to decouple test logic from locators, TestNG groups/dependencies for execution order, and data providers for data-driven scenarios -- rather than a vague 'we used Selenium with TestNG.'

Tests whether you know @ParameterizedTest lets one test method run multiple times with different inputs (via @ValueSource, @CsvSource, or a custom provider), avoiding near-duplicate test methods that differ only in input data.

Tests whether you know @Mock creates a fully fake object with no real behavior unless stubbed, while @Spy wraps a real object so unstubbed methods execute their actual implementation -- useful when you want to verify interactions on mostly-real behavior.