Java Interview Questions for AI Training Work

`ArrayList` is backed by a resizable array, giving O(1) indexed access but O(n) insertion or removal in the middle since elements have to shift. `LinkedList` is backed by nodes with pointers, giving O(1) insertion or removal once you have a reference to the position, but O(n) indexed access since it has to walk the list. For most use cases with frequent random access, `ArrayList` wins; `LinkedList` only pays off when insertions and removals in the middle genuinely dominate.

`==` compares object references, whether two variables point to the exact same object in memory, while `.equals()` compares logical equality as defined by the class, which for `String` means comparing character content. Because of string interning, two identical string literals often happen to share a reference and `==` appears to work, but a string built at runtime, like via concatenation, usually won't be interned, so the same comparison silently breaks.

Checked exceptions, subclasses of `Exception` but not `RuntimeException`, must be declared in a method's `throws` clause or caught, and the compiler enforces this. Unchecked exceptions, subclasses of `RuntimeException`, don't require declaration or catching. Checked exceptions are meant for recoverable conditions the caller should anticipate, like a file not found, while unchecked exceptions typically represent programming errors, like a null pointer dereference.

An object becomes eligible for garbage collection once it's unreachable, no live reference chain from a GC root, like a local variable on the stack or a static field, points to it anymore. Most JVM garbage collectors use a generational approach, since most objects die young, new objects are allocated in a young generation collected frequently and cheaply, while objects that survive multiple collections get promoted to an old generation collected less often.

`synchronized` is simpler and built into the language, automatically releasing the lock even if an exception is thrown, but it's inflexible: you can't try to acquire it with a timeout or interrupt a thread waiting on it. `ReentrantLock` offers more control, like `tryLock()` with a timeout or `lockInterruptibly()`, at the cost of requiring an explicit `unlock()` in a `finally` block, since forgetting that leaves the lock held indefinitely.

This means a collection is being modified, an add or remove, while something else is iterating over it, most standard collections aren't safe for that. I'd first confirm whether the collection genuinely needs concurrent access; if so, I'd switch to a concurrent-safe collection like `CopyOnWriteArrayList` for read-heavy workloads or wrap access with explicit synchronization, rather than just catching the exception and retrying, which doesn't fix the underlying race.

I'd take a heap dump at or near the failure, using `-XX:+HeapDumpOnOutOfMemoryError`, and analyze it with a tool like Eclipse MAT to find what's actually accumulating. Common causes are an unbounded cache with no eviction, a listener or callback registered repeatedly without being removed, or a genuine sizing problem, like heap limits set too low for the actual working set the application needs under peak load.

I'd first profile to confirm this method is actually the bottleneck rather than assuming, then look at the algorithmic complexity, a nested loop doing a linear search inside an outer loop is often an O(n²) pattern that a `HashMap` lookup can turn into O(n). Only after fixing an actual complexity problem would I consider parallelizing with streams, since parallelizing an inefficient algorithm just spreads the same wasted work across more threads.

A counter incremented from multiple threads without synchronization occasionally undercounted, but only under real production load, never in local testing with fewer concurrent requests. I reproduced it by writing a stress test that spun up many threads incrementing the counter simultaneously, which reliably surfaced the race. The fix was switching to `AtomicInteger`, and the bigger lesson was that concurrency bugs need load-proportional tests, not just functional ones, to catch reliably.

For a small internal tool needing basic dependency injection, I skipped pulling in a full framework like Spring and wrote a small manual wiring class instead, since the app had maybe a dozen components and Spring's startup time and configuration overhead weren't worth it at that scale. For a larger customer-facing service later, I did reach for Spring, since the ecosystem and conventions paid off once the component count and team size grew.