Core Java

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 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 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.

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.

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.

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.

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.

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 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.

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.

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 understand segment/bucket-level locking and why it beats simply synchronizing a whole HashMap.

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

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.

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

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

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

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

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 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.

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 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 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 the four necessary conditions for deadlock and practical strategies to avoid them.

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 can correctly write the volatile + double-checked-locking pattern, a classic concurrency coding question.

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().

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.

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.

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 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 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.