Java Interview Questions for 3 Years Experience

Why interviewers ask deeper questions at 3 years

Three years of experience is where companies expect you to work without supervision — and the interview is calibrated to test exactly that. The questions shift from "what is X?" to "when did X bite you, and what did you do about it?"

There is also a market reality: 3 years is the most crowded experience band in Hyderabad hiring. Interviewers use concurrency and streams internals as the separator because these topics cannot be faked with one weekend of preparation. A candidate who can explain why a parallelStream made an endpoint slower, or why their entity's equals() uses a business key, stands out immediately.

The themes: stream execution mechanics, the multithreading toolbox (ExecutorService, volatile, locks, ConcurrentHashMap, CompletableFuture), Java features that interact with persistence frameworks, and design judgment.

How to answer in an interview

At this level, structure your answers as claim → mechanism → decision:

1. State the direct answer in one or two sentences.
2. Explain the mechanism underneath (what the JVM or library actually does).
3. Close with a decision you made: "in our service we chose X over Y because...".

The third step is non-negotiable at 3 years. Interviewers are pattern-matching for ownership. Also: when you genuinely have not used something (say, StampedLock), say so and pivot to the nearest thing you have used. Confident scoping beats bluffing every time.

Q1. Explain intermediate vs terminal operations and lazy evaluation in streams.

Intermediate operations (filter, map, sorted) return a stream and do nothing when called — they only build the pipeline. A terminal operation (collect, count, findFirst) triggers execution, and elements flow through the entire pipeline one at a time.

Laziness enables short-circuiting: with findFirst(), the stream stops the moment one element survives all stages — it may process 3 elements out of a million.

Optional<String> first = names.stream()
    .peek(n -> System.out.println("checking " + n))  // proves laziness
    .filter(n -> n.startsWith("A"))
    .findFirst();   // stops at the first match

Run this and you will see peek print only until the first "A" name — clear evidence that streams are pull-based, not stage-by-stage. Stateful operations like sorted() are the exception: they must buffer every element before emitting any.

Interview note: Trap: "how many times is the list traversed in a 5-stage pipeline?" Once. Candidates who say five times have never reasoned about execution order.

Q2. How do you use Collectors.groupingBy for real reporting tasks?

groupingBy builds a Map from a classifier function, and its second "downstream collector" argument aggregates each group — counting, summing, mapping, or grouping again for multi-level reports.

Map<String, Double> revenueByCity = orders.stream()
    .collect(Collectors.groupingBy(
        Order::getCity,
        Collectors.summingDouble(Order::getAmount)));

Map<String, Long> countByStatus = orders.stream()
    .collect(Collectors.groupingBy(Order::getStatus, Collectors.counting()));

The downstream collector is what interviewers are checking for — most candidates only know the single-argument form that collects into Lists. Also know Collectors.toMap and its trap: it throws IllegalStateException on duplicate keys unless you pass a merge function.

Interview note: Follow-up: "how do you get a sorted map out of groupingBy?" Pass a map factory: groupingBy(classifier, TreeMap::new, downstream).

Q3. When would you not use parallelStream()?

Avoid parallelStream() for small datasets, I/O-bound work, ordered or stateful operations, and anywhere in a servlet/request thread — because all parallel streams in the JVM share the common ForkJoinPool by default.

Parallelization has a fixed cost: splitting the source, scheduling tasks, merging results. For a few thousand in-memory elements with cheap operations, the overhead exceeds the gain. Worse, if a stream stage blocks on I/O, it starves the shared pool, and unrelated parallel streams across your whole application stall — a genuinely nasty production failure mode.

The honest 3-year answer: "I benchmark first; almost all my stream code is sequential, and where we needed real parallelism we used an explicit ExecutorService so the pool was isolated and sized deliberately."

Interview note: Trap: "does parallelStream preserve order in forEach?" No — use forEachOrdered if order matters, and accept the throughput cost.

Q4. Runnable vs Callable, and how does ExecutorService fit in?

Runnable.run() returns nothing and cannot throw checked exceptions; Callable.call() returns a value and can throw. You submit either to an ExecutorService, which runs them on a managed thread pool and hands you back a Future.

Creating raw Thread objects per task does not scale — thread creation is expensive and unbounded threads can exhaust memory. A pool reuses a fixed set of workers and queues the rest.

ExecutorService pool = Executors.newFixedThreadPool(4);
Future<Integer> result = pool.submit(() -> priceService.compute(itemId));
Integer price = result.get(2, TimeUnit.SECONDS); // bounded wait
pool.shutdown();

Mention that Future.get() blocks, and that you always use the timeout overload in service code — unbounded waits turn one slow dependency into a full thread-pool stall.

Interview note: Follow-up: "what happens to an exception thrown inside a submitted task?" It is captured and rethrown wrapped in ExecutionException when you call get() — it does not appear in logs on its own, a common silent-failure bug.

Q5. synchronized vs ReentrantLock — when is the explicit lock worth it?

Both provide mutual exclusion and the same memory-visibility guarantees. ReentrantLock adds capabilities synchronized lacks: tryLock() with timeout, interruptible waits, fairness policy, and multiple Condition queues. Use synchronized by default; upgrade only when you need those features.

synchronized is simpler and impossible to forget to unlock. ReentrantLock demands the try/finally discipline:

private final ReentrantLock lock = new ReentrantLock();

public boolean transfer(Account to, long amount) {
    if (!lock.tryLock(500, TimeUnit.MILLISECONDS)) {
        return false;              // back off instead of deadlocking
    }
    try { /* move money */ } finally { lock.unlock(); }
}

tryLock with a timeout is the classic deadlock-avoidance tool — a thread that cannot acquire the second lock backs off and retries instead of waiting forever. More depth in synchronization in Java.

Interview note: Trap: "is synchronized reentrant?" Yes — a thread holding a monitor can re-enter it. Candidates often think reentrancy is unique to ReentrantLock; the name just makes the property explicit.

Q6. What does volatile actually guarantee — and what does it not?

volatile guarantees visibility (a write by one thread is immediately visible to reads by others) and ordering (no reordering across the volatile access), but not atomicity. count++ on a volatile is still a race condition.

Without volatile, a thread may cache a flag in a register or CPU cache and never see another thread's update — the infamous infinite loop on while (!stopped). volatile fixes that. But count++ is three operations (read, add, write); two threads can interleave and lose updates regardless of volatile.

The decision rule: volatile for single-writer flags and safely-published references; AtomicInteger/LongAdder for counters; locks for compound invariants spanning multiple fields.

Interview note: Follow-up: "would you fix a race condition on a counter with volatile?" No — that is the trap. Say AtomicInteger.incrementAndGet() and explain why volatile alone loses increments.

Q7. Why does ConcurrentHashMap exist, and how does it differ from Collections.synchronizedMap?

synchronizedMap wraps every method in a single lock — one thread at a time, and iteration still requires manual synchronization. ConcurrentHashMap allows fully concurrent reads and fine-grained (per-bin) locked writes, plus atomic compound operations like computeIfAbsent.

The compound-operation point is what earns marks. With a synchronized map, "check then put" is two operations and a race:

// Broken on synchronizedMap: check and put are separate operations
if (!map.containsKey(key)) { map.put(key, expensive(key)); }

// Atomic and computes only once per key:
cache.computeIfAbsent(key, k -> expensive(k));

ConcurrentHashMap iterators are weakly consistent — they never throw ConcurrentModificationException and may or may not reflect concurrent updates. It also rejects null keys and values, precisely because a null get() would be ambiguous under concurrency.

Interview note: Trap: "is ConcurrentHashMap fully lock-free?" No — reads are lock-free; writes lock the affected bin. "It has no locks" is a red-flag answer.

Q8. How should equals() and hashCode() be implemented on a JPA entity?

Do not use the database-generated ID naively, and do not use all fields. The safe pattern is a business/natural key if one exists; otherwise implement equals() on the ID with a null-check (unsaved entities are only equal to themselves) and return a constant-ish hashCode() so the hash never changes across the persist boundary.

The core problem: a generated ID is null before persist() and set after. If hashCode() derives from it, an entity added to a HashSet before saving is unfindable after saving — its hash changed while sitting in the bucket. This shows up as "contains returns false for an object I just added."

This question is popular because it sits at the junction of core Java contracts and real persistence behavior — exactly the intersection a 3-year developer lives in. Proxy objects add another wrinkle: compare classes with instanceof (or getEffectiveClass), never getClass() ==, because a lazy-loading proxy is a runtime subclass.

Interview note: Follow-up: "why not just not override equals?" Identity equality breaks Set semantics in detached scenarios — two objects representing the same row compare unequal after a merge.

Q9. What causes the N+1 query problem, and how do you detect it from the Java side?

N+1 happens when loading a list of N parent objects triggers one query for the list plus N lazy-initialization queries — one per child association touched in a loop. You detect it by enabling SQL logging and watching one logical operation emit dozens of near-identical queries.

From the Java side, the trigger is innocent-looking code: orders.forEach(o -> total += o.getItems().size()). Each getItems() on a lazy association fires its own query. Fixes are fetch-side, not loop-side: a fetch join, an entity graph, or batch fetching — chosen per use case, because making everything eager just moves the problem.

The related trap is LazyInitializationException: touching a lazy association after the persistence session closed (typically in a controller or during JSON serialization). The clean fix is loading what the use case needs inside the transaction and mapping to a DTO — not the notorious open-session-in-view band-aid.

Interview note: Follow-up: "would you make the association EAGER to fix it?" No — eager fetching is a global decision that penalizes every other query path. Fetch strategy belongs to the query, not the mapping.

Q10. Why use records for DTOs, and what are their limits?

A record declares immutable data in one line — final fields, constructor, accessors, equals, hashCode, toString all generated. It is ideal for DTOs, API responses and map keys. Limits: records cannot extend a class, all fields are final, and JPA entities cannot be records (entities need a no-arg constructor and mutable state).

public record OrderSummary(String orderId, double amount, String status) {
    public OrderSummary {                     // compact constructor = validation
        if (amount < 0) throw new IllegalArgumentException("amount < 0");
    }
}

The compact constructor is the detail worth mentioning — it centralizes validation without restating the field assignments. Records also pair naturally with streams: mapping entities to OrderSummary inside the transaction kills both over-fetching and lazy-loading surprises from Q9.

Interview note: Trap: "are records fully immutable?" Shallow only — a record holding a List still exposes mutable state unless you copy defensively in the compact constructor.

Q11. Why is composition preferred over inheritance in application code?

Inheritance hard-wires a compile-time is-a relationship and inherits the parent's entire contract, including its bugs and future changes. Composition (has-a plus delegation) couples you only to a small interface, can be swapped at runtime, and survives parent refactors. Default to composition; reserve inheritance for genuine, stable is-a hierarchies.

The classic failure: extending a class to tweak one behavior, then a parent upgrade silently changes a method your override depended on — the fragile base class problem. With composition you would have delegated one method through an interface, and the upgrade could not reach you.

Concrete decision to cite: implementing a NotificationSender interface with EmailSender and SmsSender injected where needed, instead of a BaseNotificationService superclass that every team then fights over.

Interview note: Follow-up: "so is inheritance bad?" No — frameworks and true taxonomies use it well. The senior answer is a decision rule, not a slogan: inherit for polymorphic is-a with a stable base, compose for reuse.

Q12. How do you design exception handling across the layers of a service?

Translate exceptions at layer boundaries, throw unchecked domain exceptions from business code, and catch-and-map to HTTP responses in exactly one place at the edge. Never catch-log-rethrow at every layer — one failure should produce one log entry and one clear response.

The pattern: repositories let infrastructure exceptions bubble; the service layer wraps them into domain exceptions (PaymentFailedException) carrying context; a single edge handler maps domain exceptions to status codes and a consistent error body. Swallowed exceptions (catch (Exception e) {}) and double-logging are the two smells interviewers want you to condemn unprompted.

public class PaymentFailedException extends RuntimeException {
    private final String orderId;
    public PaymentFailedException(String orderId, Throwable cause) {
        super("Payment failed for order " + orderId, cause);
        this.orderId = orderId;
    }
}

Always keep the cause — a translated exception without the original stack trace makes production debugging archaeology.

Interview note: Trap: "checked or unchecked for domain exceptions?" Unchecked, in most modern codebases — checked exceptions leak through every intermediate signature and get wrapped anyway. Be ready to defend either, but have a position.

Q13. What problem does CompletableFuture solve over Future?

Future can only be polled or blocked on with get(). CompletableFuture lets you compose async steps — chain transformations, combine independent calls, and handle errors — without blocking a thread between steps.

CompletableFuture<Quote> best =
    CompletableFuture.supplyAsync(() -> vendorA.quote(item), pool)
        .thenCombine(
            CompletableFuture.supplyAsync(() -> vendorB.quote(item), pool),
            Quote::cheaper)
        .orTimeout(2, TimeUnit.SECONDS)
        .exceptionally(ex -> Quote.fallback(item));

Two independent vendor calls run in parallel, results merge, and there is a timeout and a fallback — that is a realistic aggregation endpoint in five lines. Mention that you pass an explicit executor: the default is the common ForkJoinPool, which takes you back to the Q3 problem.

Interview note: Follow-up: "difference between thenApply and thenCompose?" thenApply maps a value; thenCompose flattens a nested CompletableFuture — the map vs flatMap distinction. Mixing them up produces CompletableFuture<CompletableFuture<T>>.

How to prepare

Prioritize concurrency: it has the highest rejection rate and the smallest honest-preparation pool. Write and run the classic failure demos — a non-volatile stop flag that loops forever, a lost-update counter, a computeIfAbsent cache — because at 3 years you will be asked "have you seen this happen?", and the truthful answer should be yes.

Then rehearse your project narrative: one endpoint traced end to end, one design decision you owned (Q11/Q12 material), one production issue you debugged. Compare your answers against the 2-year question set to confirm the fundamentals are still sharp, and skim the 5-year set — interviewers frequently reach one level up to find your ceiling. For collections-heavy rounds, the dedicated Java collections interview questions page goes deeper on the data-structure internals this page assumes.