Java Developer Interview Questions for AI Training Work

I favor composition when the relationship between classes is more about behavior reuse than a true is-a relationship, since inheritance creates tight coupling that makes future changes harder. Composition also avoids the fragile base class problem where a change in a parent class unexpectedly breaks subclasses.

I use synchronized blocks for simple, low-contention critical sections, but I move to java.util.concurrent utilities like ConcurrentHashMap or ExecutorService for anything involving thread pools or higher contention, since they're better tested and typically more performant than hand-rolled synchronization.

Streams can hurt readability and debuggability for complex logic with side effects or multiple exit conditions, where a traditional loop is clearer. I use streams for straightforward transformation and filtering pipelines, and fall back to loops when the logic involves complex branching or needs to break early.

I take a thread dump during the hang and look for threads blocked waiting on locks held by each other, which Java's thread dump tool usually flags directly as a detected deadlock. Once identified, I trace back to the lock acquisition order in the code to find where it diverges between threads.

Immutable objects are inherently thread-safe since their state can't change after construction, which eliminates a whole category of concurrency bugs, at the cost of creating new objects instead of modifying existing ones. I default to immutability for value objects and reserve mutability for cases where the performance cost of object creation is measurable and significant.

I'd take a heap dump close to the crash and analyze it with a tool like Eclipse MAT to find which object type is accumulating and what's holding references to it. Common causes include an unbounded cache, a listener that's never unregistered, or a collection that grows without any eviction policy.

I'd look for any code that iterates over a shared collection while another thread might be modifying it concurrently, since this only surfaces under real concurrent load that's hard to reproduce in a single-threaded test. I'd switch the collection to a concurrent-safe variant or add proper synchronization around the iteration.

I'd profile with a tool like async-profiler or JFR to find the actual hot methods rather than guessing, since CPU issues in Java are often caused by unexpected things like excessive object allocation triggering garbage collection pressure, not just inefficient algorithms.

I inherited a class with over a thousand lines mixing business logic, data access, and validation in one place. I refactored it incrementally, extracting one responsibility at a time behind interfaces, and kept the existing tests passing at each step rather than attempting a full rewrite that risked breaking production.

I added a cache without realizing multiple threads could initialize it simultaneously under load, causing duplicate expensive computations. I fixed it with a double-checked locking pattern and added a test that simulated concurrent access, which we hadn't had before, to catch similar issues earlier next time.