Java Developer Interview Questions

A reporting service had 900ms p99 and intermittent pauses. I profiled it, found frequent full GC pauses from short-lived large allocations plus an N+1 Hibernate problem. I tuned the heap and GC, fixed the query with a fetch join, and added caching. p99 dropped to 180ms even under 3x load. I let profiling data, not intuition, drive the changes.

We moved a monolith to Spring Boot services. I carved off bounded contexts one at a time using the strangler pattern, keeping the monolith running while routing slices of traffic to new services. This avoided a risky big-bang rewrite. Release cadence went from monthly to weekly with far fewer incidents because each step was small and reversible.

A reviewer wanted me to add an abstraction layer I felt was premature. Rather than argue, I asked what future change it was protecting against and we found there was no concrete one yet. We agreed to keep it simple and revisit if the need arose. Grounding the debate in a real requirement, not preference, resolved it cleanly.

Our service had thin tests and frequent regressions. I introduced Testcontainers for realistic integration tests and made coverage on changed code part of the pipeline. Coverage rose from 41% to 86% and escaped bugs roughly halved. I focused on tests that caught real regressions rather than chasing a coverage number for its own sake.

We had a week to ship a payment integration. I scoped ruthlessly to the must-have path, reused an existing client library, and wrote tests for the money-handling logic first. We shipped on time with the critical paths well-covered and deferred the nice-to-haves explicitly. Cutting scope, not corners, kept both the deadline and quality intact.

A junior kept writing tightly-coupled classes that were hard to test. I paired with them on applying dependency injection and showed how it made unit tests trivial. Within a few sprints they were designing testable code unprompted. I measured success by their independence, reviewing less of their work over time.

Checked exceptions are part of the method signature and force the caller to handle or declare them, suited to recoverable conditions the caller can act on. Unchecked (runtime) exceptions signal programming errors or unrecoverable states and don't require declaration. In practice I prefer unchecked exceptions for most code to avoid signature clutter, reserving checked ones for genuinely recoverable, caller-actionable failures.

The JVM splits the heap into young and old generations; most objects die young and are collected cheaply, while long-lived ones get promoted to the old gen. A leak shows as old-gen usage that keeps climbing and full GCs that reclaim little. I'd capture a heap dump, analyze dominators in a tool like Eclipse MAT, and usually find an unbounded cache or a static collection holding references.

Virtual threads, stable since Java 21, are lightweight threads managed by the JVM rather than mapped one-to-one to OS threads, so you can have millions of them cheaply. They let you write simple blocking-style code that scales like asynchronous code for I/O-bound workloads. For a service making many concurrent downstream calls, they remove the need for complex reactive plumbing while keeping high throughput.

I'd implement a token-bucket algorithm keyed by client/API key, storing counters in Redis so the limit holds across multiple instances. A filter or interceptor checks and decrements the bucket before the request proceeds, returning 429 with a Retry-After header when exhausted. Redis gives atomic operations via Lua scripts to avoid race conditions, and I'd make limits configurable per tier.