Java Interview Questions and Answers — Part 2

Part two is where most experienced loops spend their time—after part one confirms you understand the JVM and OOP foundation.

Topics on this page:

How to use both parts:

• Rusty on JVM/OOP? Read part one first, then return here.
• Shipping production Java? Skim part one for gaps; drill part two daily.

Interviewers still expect solid collections and exception fundamentals, but senior loops increasingly add modern language features.

Prep balance for experienced roles:

• ~50% collections, strings, exceptions (still the bulk of coding rounds)
• ~30% concurrency basics + modern Java (lambdas, streams, virtual threads)
• ~20% serialization, reflection, GC (architecture and framework follow-ups)

A static import lets you use static members of a class without qualifying them with the class name—similar to how a normal import lets you use a class without the package prefix.

Common in tests and utilities:

import static java.lang.Math.max;
import static java.util.Collections.emptyList;

double bigger = max(3.0, 7.0);
List<String> none = emptyList();

Caution: Overusing static imports hurts readability—reserve them for well-known constants (PI) or test assertions.

A strong answer is:

Static import brings static members into scope without the class prefix. I use it sparingly—mostly in tests or for obvious constants like Math.PI.

These are two different import mechanisms:

Example:

import com.test.FooClass;
import static com.test.FooClass.bar;

FooClass.foo();   // instance or static via type name
bar();            // static method without FooClass prefix

You still need the normal import (or FQCN) to reference the class as a type. Static import only affects static fields and methods.

A strong answer is:

Normal import is for the class type; static import is for static members only. I can call bar() directly after static import, but I still import the class if I need to declare variables of that type.

A Locale represents a specific geographical, political, or cultural region. Java uses it for locale-sensitive formatting and parsing—not for translating your UI strings by itself.

Common uses:

Example:

Locale us = Locale.US;
Locale france = Locale.FRANCE;

NumberFormat currency = NumberFormat.getCurrencyInstance(us);
// formats as $1,234.56

Interview note: Locale is about formatting conventions, not automatic translation. i18n still requires message bundles and explicit locale selection (user preference, Accept-Language, etc.).

A strong answer is:

Locale tells Java how to format dates, numbers, and currency for a region. It works with formatters and resource bundles—I do not confuse it with automatic translation.

Serialization is the process of converting a Java object into a byte stream that captures the object's class, version, and internal state. The JVM (or another process) can deserialize those bytes back into a live object—often across network boundaries or after storage.

What gets captured (by default):

• Class metadata and field values
• Object graph reachable from the root (references followed recursively)

public class User implements Serializable {
    private static final long serialVersionUID = 1L;
    private String name;
    private int age;
}

Not magic persistence: Both ends need compatible class definitions and compatible serialVersionUID strategy.

A strong answer is:

Serialization converts an object graph to bytes for transmission or storage. I mention serialVersionUID because version mismatches are a common production deserialization failure.

Serialization solves moving object state between JVMs, processes, or storage layers without hand-rolling a custom binary format.

Modern interview framing:

• Many greenfield APIs prefer JSON/Protobuf over Java serialization (security and compatibility).
• Java serialization still appears in legacy enterprise, session replication, and some framework internals.

A strong answer is:

Serialization moves object state as bytes—for caching, replication, or legacy integration. In new systems I often prefer JSON or Protobuf, but I still understand Java serialization for maintaining older codebases.

The transient keyword marks a field that must not be included in the default serialization snapshot.

Why you would mark a field transient:

During serialization, the JVM skips transient fields. On deserialization they get default values (null, 0, false) unless you restore them in readObject() or a constructor.

A strong answer is:

transient excludes a field from the serialized byte stream—typically for secrets, non-serializable resources, or derived data I can rebuild after load.

If class ABC implements Serializable but contains a field of type XYZ that does not implement Serializable, default serialization fails with NotSerializableException.

Problem:

public class ABC implements Serializable {
    private XYZ helper;  // XYZ is not Serializable → serialization fails
}

Fix: Mark the non-serializable field transient and restore it after deserialization:

public class ABC implements Serializable {
    private transient XYZ helper;

    private void readObject(ObjectInputStream in)
            throws IOException, ClassNotFoundException {
        in.defaultReadObject();
        this.helper = new XYZ();  // re-create or look up from context
    }
}

Interview point: transient is a workaround for one non-serializable member—the real state you care about must still be serializable or reconstructed explicitly.

A strong answer is:

When a member type is not Serializable, marking it transient lets the enclosing class serialize. I must rebuild that field in readObject or accept it being null after load.

Externalizable extends Serializable but gives the class full control over what bytes are written and read—via writeExternal() and readExternal().

public class Order implements Externalizable {
    private String id;
    private double total;

    @Override
    public void writeExternal(ObjectOutput out) throws IOException {
        out.writeUTF(id);
        out.writeDouble(total);
    }

    @Override
    public void readExternal(ObjectInput in)
            throws IOException, ClassNotFoundException {
        id = in.readUTF();
        total = in.readDouble();
    }

    public Order() { }  // public no-arg constructor required
}

When teams choose it: Tight control over format, smaller payloads, or avoiding default reflection-based serialization.

A strong answer is:

Externalizable lets the class own the byte format through writeExternal and readExternal. I mention the required public no-arg constructor—that is a common follow-up trap.

Both move object state to bytes, but the default mechanism and control level differ.

Rule of thumb:

• Serializable — convenience, legacy, frameworks that expect it
• Externalizable — explicit format, performance tuning, minimal payload

A strong answer is:

Serializable is marker-based with optional hooks; Externalizable forces me to implement the byte format and requires a public no-arg constructor. I pick Externalizable only when I need explicit control.

Reflection is the ability to inspect and manipulate classes, methods, fields, and constructors at runtime—even when you did not know the types at compile time.

What you can do:

Where you see it: Spring DI, JUnit, Jackson/Gson, Hibernate, annotation processors, test utilities.

Trade-off: Reflection is slower, bypasses compile-time checks, and can break encapsulation—use deliberately, not for everyday business logic.

A strong answer is:

Reflection inspects and invokes classes at runtime. Frameworks use it heavily; in application code I avoid it unless I am building infrastructure or test utilities.

Reflection powers frameworks and tools that must work with unknown types at compile time.

Interview framing: Reflection trades compile-time safety for runtime flexibility. Production app code rarely calls it directly; you benefit from frameworks that do.

A strong answer is:

Reflection lets frameworks wire objects, run tests, and map data without hard-coding every class. I name Spring and JUnit as examples rather than suggesting reflection for everyday business logic.

Use reflection to obtain a Method, call setAccessible(true), then invoke. This bypasses normal access checks—common in tests and some framework code, not recommended for production business logic.

Foo.java:

public class Foo {
    private void message() {
        System.out.println("hello java");
    }
}

FooMethodCall.java:

import java.lang.reflect.Method;

public class FooMethodCall {
    public static void main(String[] args) throws Exception {
        Class<?> c = Class.forName("Foo");
        Object o = c.getDeclaredConstructor().newInstance();
        Method m = c.getDeclaredMethod("message");
        m.setAccessible(true);
        m.invoke(o);
    }
}

Important corrections for interviews:

• Use getDeclaredConstructor().newInstance() — Class.newInstance() is deprecated
• Use getDeclaredMethod("message") — no null parameter array needed for zero-arg methods

Java 9+ module note: Strong encapsulation may block deep reflection on JDK internals unless --add-opens is used.

A strong answer is:

I use getDeclaredMethod, setAccessible(true), and invoke. I also mention getDeclaredConstructor().newInstance() instead of the deprecated Class.newInstance—and that this pattern belongs in tests or frameworks, not normal app code.

Garbage collection (GC) is the JVM's automatic process for reclaiming heap memory occupied by objects that are no longer reachable. Developers do not free() objects manually as in C/C++.

High-level model:

1. Your code creates objects on the heap.
2. GC identifies unreachable object graphs.
3. Memory is reclaimed and may be compacted (collector-dependent).

GC is also called automatic memory management—the JVM owns allocation and reclamation policy.

Interview follow-ups: Generational collectors (young/old), STW pauses, tuning for latency vs throughput.

A strong answer is:

GC reclaims heap memory from unreachable objects automatically. I connect it to reachability—not reference counting—and mention that pause behavior matters in latency-sensitive services.

Java hides raw pointers and expects the JVM to manage memory. As your application allocates objects, the heap fills; without reclamation, you would hit OutOfMemoryError.

When memory pressure rises, the GC runs (or is triggered) to free objects that are no longer reachable—see also process memory on Linux for OS-level visibility.

A strong answer is:

Java has no manual memory free—the JVM allocates on the heap and GC reclaims unreachable objects so developers avoid pointer lifetime bugs common in native code.

System.gc() and Runtime.getRuntime().gc() are hints asking the JVM to run garbage collection. They do not guarantee immediate collection.

Interview points:

• The JVM may ignore or delay the request.
• Forcing GC in application code is usually a code smell—trust the collector unless you have measured evidence (rare).
• Modern low-latency apps tune GC flags and heap size, not scatter gc() calls.

A strong answer is:

gc() is only a suggestion to the JVM. I do not call it in production code—the collector knows better when to run based on heap pressure.

An object is eligible for GC when it is unreachable from GC roots—not merely when you null a local variable (that is one way to drop reachability).

Common eligibility scenarios:

GC roots include: thread stacks, static fields, JNI references, synchronized monitor objects, and JVM internal tables.

Object o = new Object();
o = null;  // previous object may become eligible (if no other refs)

A strong answer is:

An object is collectible when no GC root path reaches it—isolated circular graphs count too. Nulling a reference is one way to drop reachability, not the definition itself.

finalize() in Object was intended as a last-chance cleanup hook before an object is reclaimed. The JVM may call it once after the object becomes unreachable.

Interview answer today: Mention finalize() history, then pivot to AutoCloseable and try-with-resources for files, sockets, and pools.

A strong answer is:

finalize was a pre-GC cleanup hook but is deprecated and unreliable. I use try-with-resources and explicit close methods instead of depending on finalize.

Beyond ordinary strong references, java.lang.ref provides reference types that interact differently with GC—useful for caches and lifecycle management.

WeakReference<User> weak = new WeakReference<>(user);
User u = weak.get();  // may be null if GC cleared the referent

A strong answer is:

Strong refs keep objects alive; soft refs suit caches; weak refs for canonicalizing keys; phantom refs for post-finalization cleanup. I pick the type based on how aggressively GC should reclaim memory.

Runtime exposes a singleton gateway to the JVM process: memory stats, GC hints, shutdown hooks, and exec of external processes.

Runtime rt = Runtime.getRuntime();
long max = rt.maxMemory();
long free = rt.freeMemory();

A strong answer is:

Runtime wraps JVM process services—memory metrics, shutdown hooks, and optional external process execution. I use maxMemory and freeMemory when discussing heap sizing or OOM investigations.

Practical uses of Runtime in applications and tooling:

For environment variables on Linux, deployment scripts and System.getenv() complement runtime introspection.

Security note: exec() with user input is dangerous—always validate and prefer ProcessBuilder with explicit arguments.

A strong answer is:

I use Runtime for memory stats and shutdown hooks. For spawning processes I prefer ProcessBuilder over exec, and I never pass unvalidated user input to either.

Java supports four kinds of nested types:

public class Outer {
    class MemberInner { }
    static class StaticNested { }

    void demo() {
        class LocalInner { }
        Runnable anon = new Runnable() { public void run() { } };
    }
}

A strong answer is:

Four nested types: member inner, local inner, anonymous inner, and static nested. The static vs non-static split is the first follow-up—inner classes need an outer instance; static nested classes do not.

Nested classes organize code that is logically part of one outer type but should not pollute the package namespace.

Example pattern: HashMap uses nested Node internally—you do not expose Node as a public top-level type.

A strong answer is:

Nested classes keep helpers close to the class that uses them and let inner types access private outer state without exposing implementation details to the whole package.

Terminology trap: "Nested class" is the umbrella; "inner class" means a non-static nested class.

Outer outer = new Outer();
Outer.MemberInner inner = outer.new MemberInner();
Outer.StaticNested nested = new Outer.StaticNested();

A strong answer is:

Every inner class is nested, but not every nested class is inner—static nested classes do not hold an implicit reference to the outer instance. That distinction matters for memory leaks in long-lived inner classes.

A static nested interface (interface declared inside a class) restricts visibility to code that can already access the enclosing class—useful for callback contracts tied to one API surface.

public class Abc {
    public interface Xyz {
        void callback();
    }

    public static void registerCallback(Xyz xyz) { /* ... */ }
}

// Client code
Abc.registerCallback(new Abc.Xyz() {
    public void callback() { /* ... */ }
});

Code that cannot reference Abc cannot reference Abc.Xyz either—tighter than a public top-level interface in the same package.

A strong answer is:

A static nested interface ties a callback contract to its enclosing class and limits how it is discovered. I use it when the callback type is part of one API, not a general-purpose interface.

Immutable means the object's state cannot change after creation. String in Java is immutable—you cannot modify characters in place.

String a = "Test";
String b = a;
a = a + "Data";  // b still "Test"

Why interviewers care: Immutability enables safe sharing, string pooling, and predictable behavior as HashMap keys.

A strong answer is:

Immutable means no in-place mutation—every transforming method returns a new String. Assigning a new value to a variable just points the reference elsewhere.

Java made String immutable for security, performance, and correctness across the platform.

Literal sharing example:

String a = "TestData";
String b = "TestData";  // may reference same pool entry
// If String were mutable, changing a would break b

When you "change" a String, Java creates a new object and retargets your variable—other references keep the old value.

A strong answer is:

String is immutable so literals can be pooled and shared safely, hash codes stay stable, and concurrent code does not need locks. Mutation is modeled as creating a new String.

Code:

String s1 = "HelloWorld";
String s2 = " HelloWorld ";
String s3 = " HelloWorld ";

Answer: two distinct string literals in the constant pool (not one).

s2 and s3 reference the same pooled literal " HelloWorld "—only one pool object for that exact sequence.

Count summary:

• 2 unique string literals in the pool: "HelloWorld" and " HelloWorld "
• 3 reference variables, all pointing at one of those two pool entries
• 0 extra heap String objects from new (all are literal references)

Common mistake: Treating "HelloWorld" and " HelloWorld " as the same literal—they differ by whitespace.

A strong answer is:

Two pool entries because the literals differ—s1 is HelloWorld without spaces, s2 and s3 share the spaced literal. Whitespace makes them distinct interned strings.

Code:

String s = new String("HelloWorld");

Classic interview answer: two objects (when "HelloWorld" is not already in the pool).

If "HelloWorld" already existed in the pool from earlier code, you still get the new heap String from new; the literal is not duplicated in the pool.

Contrast:

String a = "HelloWorld";           // pool only (typical)
String b = new String("HelloWorld"); // pool literal + heap object

A strong answer is:

new String("HelloWorld") creates a heap String plus the literal in the constant pool—two objects in the usual trace. I contrast it with String s = "HelloWorld" which typically uses only the pooled literal.

String interning ensures only one copy of each distinct literal sequence lives in the string constant pool (for a given class loader / JVM rules).

String a = new String("hello").intern();
String b = "hello";
System.out.println(a == b);  // true — both canonical pool refs

Caution in modern code: Prefer equals() for business logic; use intern() only with measured need.

A strong answer is:

Interning deduplicates identical character sequences in the pool. Literals are interned automatically; intern() forces dynamic strings into the pool—I warn against over-interning user input.

StringBuffer sb = new StringBuffer("Hello");
sb.append(" World");  // mutates same object
String s = sb.toString();  // new immutable String

A strong answer is:

String is immutable; StringBuffer is mutable and synchronized. For single-threaded concatenation I use StringBuilder instead of StringBuffer unless I need thread safety.

Immutability is more than final on the class—you must prevent mutation paths through fields, getters, and subclasses.

Checklist:

public final class ImmutableUser {
    private final String name;
    private final List<String> tags;

    public ImmutableUser(String name, List<String> tags) {
        this.name = name;
        this.tags = List.copyOf(tags);  // defensive copy
    }

    public List<String> tags() {
        return tags;  // unmodifiable list
    }
}

Modern helpers: List.copyOf, record for simple immutable carriers (Java 16+).

A strong answer is:

Final class, private final fields, no setters, and defensive copies for any mutable components—in constructor and getters. I mention records when the type is a simple data carrier.

Every class inherits toString() from Object. It returns a string representation for logging, debugging, and UI display.

public class User {
    private final String email;

    @Override
    public String toString() {
        return "User{email='" + email + "'}";
    }
}

Pair with equals/hashCode when objects are used in collections—consistent identity story.

A strong answer is:

toString gives a human-readable summary for logs and debugging. I override it with key fields instead of relying on the default Object identity string.

For repeated mutation (append in a loop), efficiency from fastest to slowest:

// Slow — many intermediate String objects
String s = "";
for (int i = 0; i < 1000; i++) s += i;

// Fast — single growing buffer
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) sb.append(i);

Order: StringBuilder → StringBuffer → String

A strong answer is:

StringBuilder first, then StringBuffer, then String for heavy mutation work. String concatenation in loops creates many throwaway objects—I use StringBuilder unless I need synchronization.

Exception handling is Java's structured model for dealing with runtime errors and exceptional conditions without crashing the whole process—using try, catch, finally, and throw.

try (BufferedReader reader = Files.newBufferedReader(path)) {
    return reader.readLine();
} catch (IOException e) {
    log.error("read failed", e);
    throw new ServiceException("unable to read config", e);
}

Interview angle: Distinguish recoverable errors (retry, fallback) from programming bugs (IllegalArgumentException, NPE) that should fail fast.

A strong answer is:

Exception handling separates normal flow from failure paths with try/catch/finally. I use specific catch blocks and preserve the cause when wrapping exceptions for APIs.

Java splits exceptions into checked (compile-time enforced) and unchecked (runtime hierarchy).

void readFile() throws IOException {  // checked — caller must deal
    Files.readAllBytes(Path.of("data.txt"));
}

void divide(int a, int b) {
    if (b == 0) throw new ArithmeticException();  // unchecked
}

Modern style: Prefer unchecked for non-recoverable API misuse; use checked for true I/O boundaries you expect callers to handle.

A strong answer is:

Checked exceptions must be caught or declared; unchecked extend RuntimeException and usually indicate bugs or bad input. I name IOException as checked and NullPointerException as unchecked.

public void save(User user) throws SQLException {
    if (user == null) {
        throw new IllegalArgumentException("user required");
    }
    repository.insert(user);  // may throw SQLException
}

Additional contrasts:

A strong answer is:

throw actually raises an exception; throws documents checked exceptions on the method signature. IllegalArgumentException via throw does not need throws; SQLException does.

Naming is confusing—Collection (singular) is an interface; Collections Framework is the whole library ecosystem.

Collection<String> names = new ArrayList<>();
names.add("Ada");

The framework provides interoperable APIs so algorithms work across ArrayList, HashSet, PriorityQueue, etc.

A strong answer is:

Collection is the root interface for groups of elements; the Collections Framework is the full library of interfaces, implementations, and utilities built around it.

Before generics and the unified framework, Java had Vector, Hashtable, arrays, and ad-hoc helpers—inconsistent APIs.

A strong answer is:

The framework gives consistent interfaces, proven implementations, and utility algorithms so I program to List or Map abstractions instead of reinventing data structures.

The Collections Framework root for single-element containers is Collection<E> in java.util.

Hierarchy nuance:

Some texts call Iterable the "root" because Collection extends it, but Oracle documents Collection as the Collections Framework member—Map is parallel, not a subtype of Collection.

A strong answer is:

Collection is the framework root for lists, sets, and queues. Map is a separate hierarchy—I do not say Map extends Collection.

Easy to confuse—one is an interface, the other a utility class.

List<Integer> list = new ArrayList<>();
Collections.sort(list);

A strong answer is:

Collection is the interface; Collections is a helper class with static methods like sort and synchronized wrappers. I never try to instantiate either name blindly.

Legacy synchronized collections and modern java.util.concurrent types serve concurrent code.

Interview guidance:

• Do not default to Vector/Hashtable in new code—use ConcurrentHashMap and proper queue types.
• "Thread-safe" ≠ "fast under all contention"—measure for your access pattern.

A strong answer is:

Vector, Hashtable, and Properties are legacy synchronized; for new concurrent code I prefer ConcurrentHashMap, CopyOnWriteArrayList, and blocking queues from java.util.concurrent.

List<Integer> is not assignable to int[]—you must unbox primitives.

Option 1 — Apache Commons Lang:

int[] intArray = ArrayUtils.toPrimitive(
    myList.toArray(new Integer[0])
);

Option 2 — Java 8+ streams:

int[] intArray = myList.stream().mapToInt(Integer::intValue).toArray();

Option 3 — Simple loop:

int[] intArray = new int[myList.size()];
for (int i = 0; i < myList.size(); i++) {
    intArray[i] = myList.get(i);
}

Trap: list.toArray() alone gives Object[] or Integer[], not int[].

A strong answer is:

I unbox via stream().mapToInt, a loop, or ArrayUtils.toPrimitive after toArray(new Integer[0]). List.toArray() alone does not produce int[].

Primitives cannot live in generic collections directly—you box to Integer.

Option 1 — Streams (Java 8+):

List<Integer> intList = Arrays.stream(intArray).boxed().collect(Collectors.toList());

Option 2 — Apache Commons:

List<Integer> intList = Arrays.asList(ArrayUtils.toObject(intArray));

Option 3 — Loop:

int[] intArray = {10, 20, 30};
List<Integer> intList = new ArrayList<>();
for (int i : intArray) {
    intList.add(i);
}

Note: Arrays.asList on Integer[] returns a fixed-size list backed by the array—not the same as mutable ArrayList.

A strong answer is:

I box primitives with streams boxed(), ArrayUtils.toObject, or a simple loop into ArrayList. I distinguish Arrays.asList from a mutable ArrayList when follow-ups ask about fixed-size lists.

Converting List → Set deduplicates (Set contract)—pick implementation based on ordering needs.

Option 1 — HashSet (unordered, O(1) average):

Set<MyType> mySet = new HashSet<>(myList);

Uses hashCode() / equals() for uniqueness.

Option 2 — LinkedHashSet (insertion order preserved):

Set<MyType> mySet = new LinkedHashSet<>(myList);

Option 3 — TreeSet (sorted, custom order):

Set<MyType> mySet = new TreeSet<>(myComparator);
mySet.addAll(myList);

A strong answer is:

new HashSet(list) for fast dedupe; LinkedHashSet if order matters; TreeSet with a Comparator for sorted or custom equality logic.

Use a Set to filter duplicates, then rebuild the list—order depends on set type.

Option 1 — HashSet (order not preserved):

ArrayList<MyType> myList = /* list with duplicates */;
Set<MyType> mySet = new HashSet<>(myList);
myList.clear();
myList.addAll(mySet);

Option 2 — LinkedHashSet (insertion order preserved):

Set<MyType> mySet = new LinkedHashSet<>(myList);
myList.clear();
myList.addAll(mySet);

List<MyType> unique = myList.stream().distinct().collect(Collectors.toList());

A strong answer is:

Put elements in a Set to drop duplicates, then addAll back—LinkedHashSet when insertion order matters, HashSet when it does not. Streams distinct() is a concise alternative.

Both are resizable arrays implementing List, but Vector is legacy synchronized; ArrayList is the default choice.

List<String> list = new ArrayList<>();  // preferred

A strong answer is:

Vector is synchronized and legacy; ArrayList is faster for normal single-threaded use. I only reach for Vector in maintaining old APIs—not new code.

(See also Q42—interviewers repeat this naming trap.)

A strong answer is:

Collection is the interface implemented by List and Set; Collections is a helper class with static algorithms. The names sound alike but roles are completely different.

List<String> list = List.of("a", "b", "a");   // [a, b, a]
Set<String> set = Set.of("a", "b", "a");       // compile-time or duplicate rejection

A strong answer is:

List is ordered and allows duplicates with index access; Set enforces uniqueness and usually has no positional index. I pick List for sequences and Set for unique membership.

Both implement Set, but hash table vs red-black tree drives behavior.

Set<Integer> fast = new HashSet<>();
Set<Integer> sorted = new TreeSet<>();

A strong answer is:

HashSet for fast uniqueness checks without order; TreeSet when I need sorted iteration or range views. I remember TreeSet rejects null and uses comparison, not just equals.

Choose by access pattern, not habit.

Map<String, User> byId = new HashMap<>();
List<Order> chronological = new ArrayList<>();
Set<String> uniqueTags = new HashSet<>();

A strong answer is:

List for sequences, Set for uniqueness, Map for key-based lookup. I add LinkedHash for order or Tree for sorting when requirements demand it.

Both order objects, but where the logic lives differs.

public class User implements Comparable<User> {
    public int compareTo(User other) {
        return this.name.compareTo(other.name);
    }
}

Comparator<User> byAge = Comparator.comparingInt(User::getAge);
users.sort(byAge);

A strong answer is:

Comparable defines natural order inside the class via compareTo; Comparator is external and supports multiple sort strategies. I use Comparator when the class should not own every possible order.

Core implementations interviewers expect:

Abstract bases: AbstractList, AbstractSequentialList

Specialized / JMX (rare in app interviews): AttributeList, RoleList, RoleUnresolvedList

List<String> items = new ArrayList<>();

A strong answer is:

ArrayList and LinkedList are the everyday answers; I mention CopyOnWriteArrayList for concurrent read-heavy lists and Vector/Stack only as legacy.

Abstract base: AbstractSet

A strong answer is:

HashSet, LinkedHashSet, and TreeSet cover most cases; EnumSet for enum domains; concurrent variants when threads share the set.

Legacy Enumeration (JDK 1.0) vs modern Iterator (Collections Framework).

Iterator<String> it = list.iterator();
while (it.hasNext()) {
    String s = it.next();
}

Modern code: Enhanced for-loop uses Iterator under the hood; use ListIterator for bidirectional traversal.

A strong answer is:

Iterator is the modern choice with optional remove and fail-fast behavior; Enumeration is legacy for old Vector/Hashtable APIs. I use Iterator or enhanced for-loops in new code.

Java threads let one JVM process run multiple threads of execution concurrently—sharing heap memory but with private stacks.

Thread t = Thread.ofVirtual().start(() -> fetchFromService());
t.join();

Key APIs: start() (not run() directly for new thread), sleep, interrupt, executors, virtual threads (Java 21+).

Link: Deeper JVM threading builds on part one fundamentals; modern I/O concurrency continues in Q62–63 below.

A strong answer is:

Threads share the heap but have their own stacks. I start work with start() or executors, protect shared mutable state with locks or concurrent collections, and use virtual threads for I/O-heavy workloads in modern Java.

A lambda is a concise way to implement a functional interface—an interface with exactly one abstract method (SAM).

list.sort((a, b) -> Integer.compare(a.length(), b.length()));

Runnable task = () -> System.out.println("running");
Predicate<String> nonEmpty = s -> !s.isBlank();

Common functional interfaces: Runnable, Callable, Comparator, Predicate, Function, Consumer

A strong answer is:

Lambdas implement functional interfaces—one abstract method. I use them with streams, comparators, and callbacks instead of anonymous inner classes for cleaner code.

Stream pipelines are lazy until a terminal operation runs.

List<String> result = names.stream()
    .filter(n -> !n.isBlank())   // intermediate
    .map(String::trim)           // intermediate
    .sorted()                    // intermediate
    .collect(Collectors.toList()); // terminal — runs pipeline

Interview notes:

• Streams do not mutate the source collection.
• Parallel streams help CPU-bound bulk in-memory work—not default for I/O or small lists.

A strong answer is:

Intermediate operations chain lazily; a terminal operation like collect or forEach executes the pipeline. I do not assume parallel streams help I/O-bound code.

Optional<T> models a value that may be absent—primarily as a return type to avoid returning null without documentation.

return findUser(id)
    .map(User::getEmail)
    .orElse("unknown@example.com");

Optional<User> found = repository.findById(id);
found.ifPresent(user -> audit.log("loaded " + user.id()));

A strong answer is:

Optional is for return types where a value might be missing—I chain map and orElse instead of null checks. I avoid Optional fields and parameters; they add noise.

Records (Java 16+, standardized) are compact immutable data carriers—the compiler generates constructor, accessors, equals, hashCode, and toString.

public record Point(int x, int y) { }

public record User(String email, Instant createdAt) {
    public User {
        Objects.requireNonNull(email);
    }
}

Related: See sealed classes in part one trends for controlled hierarchies.

A strong answer is:

Records are immutable data classes with generated boilerplate. I use them for DTOs and value types—not as drop-in replacements for entities with lifecycle and lazy loading.

Virtual threads (Java 21, Project Loom) are lightweight threads scheduled by the JVM on platform-thread carriers—ideal for massive I/O concurrency with blocking code style.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    List<Future<String>> futures = urls.stream()
        .map(url -> executor.submit(() -> fetch(url)))
        .toList();
}

Pinning caveat: Blocking inside synchronized may pin a carrier—ReentrantLock is often safer in hot paths.

A strong answer is:

Virtual threads give cheap concurrency for I/O-heavy blocking code. I do not use them for CPU-bound work, and I watch for synchronized pinning in tight loops.

They solve different shapes of async problems—often complementary.

CompletableFuture<User> user = fetchUserAsync(id)
    .thenCompose(u -> fetchOrdersAsync(u.id()))
    .exceptionally(ex -> User.guest());

Combined pattern: Virtual threads for request scope; CompletableFuture when one method fans out to several async dependencies and merges results.

A strong answer is:

CompletableFuture composes async stages and callbacks; virtual threads let me write blocking code at huge concurrency. Many services use virtual threads per request and CompletableFuture inside a method to join parallel calls.