Java for Testers Interview Questions for 4 Years Experience (2026)

Short answer: Collectors.groupingBy with Collectors.counting(). Interviewers at this level want to see you can read and write this without a loop.

record Result(String name, String status) {}

List<Result> results = List.of(
    new Result("login", "PASS"), new Result("search", "FAIL"),
    new Result("cart", "PASS"), new Result("pay", "SKIP"));

Map<String, Long> byStatus = results.stream()
    .collect(Collectors.groupingBy(Result::status, TreeMap::new, Collectors.counting()));

System.out.println(byStatus); // {FAIL=1, PASS=2, SKIP=1}

The TreeMap::new argument sorts the keys so the output is stable - useful when you assert on it.

Short answer: Optional is a return type that says "this may be empty". Do not call get() without a check, and do not use Optional for fields or method parameters.

Optional<String> token = findTokenFor("qa_user");

String value = token.orElseThrow(
    () -> new IllegalStateException("No token for qa_user - check test data setup"));

A clear error message like this saves debugging time in CI compared with a bare NoSuchElementException.

Short answer: records (Java 16+) are immutable data carriers that generate equals, hashCode and toString. That makes them good for expected-vs-actual comparisons.

For normal classes, if you override equals you must also override hashCode. Otherwise two equal objects can both be stored in a HashSet:

record User(String email, String role) {}

Set<User> users = new HashSet<>();
users.add(new User("a@x.com", "admin"));
users.add(new User("a@x.com", "admin"));
System.out.println(users.size()); // 1 - records implement both methods

Short answer: a builder gives sensible defaults and lets each test change only the fields it cares about, so the test shows its intent.

public final class OrderBuilder {
    private String country = "IN";
    private int quantity = 1;
    private String coupon = null;

    public OrderBuilder country(String c) { this.country = c; return this; }
    public OrderBuilder quantity(int q)   { this.quantity = q; return this; }
    public OrderBuilder coupon(String c)  { this.coupon = c; return this; }
    public Order build() { return new Order(country, quantity, coupon); }
}

Order order = new OrderBuilder().quantity(0).build(); // the test is clearly about quantity 0

Short answer: store one driver per thread in a ThreadLocal, create it in setup and call remove() in teardown. Forgetting remove() on pooled threads can leave a stale, quit driver for the next test.

public final class DriverManager {
    private static final ThreadLocal<WebDriver> DRIVER = new ThreadLocal<>();

    public static void start() { DRIVER.set(new ChromeDriver()); }
    public static WebDriver get() { return DRIVER.get(); }

    public static void stop() {
        WebDriver d = DRIVER.get();
        if (d != null) d.quit();
        DRIVER.remove();
    }
}

Common failure: creating the driver in @BeforeClass while TestNG runs parallel="methods" - methods of one class then share a thread's driver unexpectedly.

Short answer: use CompletableFuture (or an ExecutorService) and always set a timeout so a hung call fails the test instead of blocking the run.

try (ExecutorService pool = Executors.newFixedThreadPool(4)) {   // ExecutorService is AutoCloseable since Java 19
    List<CompletableFuture<String>> calls = List.of("u1", "u2", "u3").stream()
        .map(id -> CompletableFuture.supplyAsync(() -> api.createUser(id), pool)
                                    .orTimeout(10, TimeUnit.SECONDS))
        .toList();
    List<String> ids = calls.stream().map(CompletableFuture::join).toList();
}

If any call times out, join() throws a CompletionException wrapping a TimeoutException.

Short answer: virtual threads (JEP 444, final in Java 21) are lightweight threads managed by the JVM. They help with many concurrent blocking I/O calls, such as seeding data through hundreds of HTTP requests. They do not make browser tests faster - the limit there is browsers and CPU, not threads.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 500; i++) {
        int n = i;
        executor.submit(() -> api.createUser("load_user_" + n));
    }
} // waits for all tasks to finish

Pitfall in Java 21: blocking inside a synchronized block can pin the virtual thread to its carrier thread. Mention this as a known limitation.

Short answer: look for shared state first. In order:

1. Static or shared fields - drivers, page objects, counters.
2. Shared test data - two tests updating the same user or cart. Give each test unique data.
3. Order dependence - run the failing test alone and in random order.
4. Environment limits - too many browsers for the machine or Grid.

Reproduce with a fixed thread count, collect logs with the thread name in each line, and fix the cause rather than adding retries.