Why Do “Average” Candidates Struggle in Java Interviews? Real Stories and Tips

Interview Findings – Technical Depth

During a recent campus‑recruitment round I interviewed 15 computer‑science graduates (class of 2020) from top universities in Sichuan. The candidates were asked a set of core Java and system‑level questions to assess whether their knowledge was superficial or deep enough for production work.

Java Collections – HashMap

Question: Why should an initial capacity be specified when creating a HashMap ? Answer: If no capacity is supplied the map starts with 16 buckets. When the number of entries exceeds capacity × loadFactor (default load factor 0.75, i.e., 12 entries), the map resizes to the next power of two (16 → 32). Each resize allocates a new array and re‑hashes all existing entries, which is a costly operation. In a multithreaded environment a concurrent resize can corrupt the bucket chain and even create a circular linked list, leading to dead loops.

Follow‑up questions clarified the resize mechanics:

When does a resize occur? – During insertion, once the entry count passes the threshold.

To what size does it grow? – The next power of two (e.g., 16 → 32, 32 → 64).

How is the resize performed? – A new array of the larger size is allocated and all entries are re‑hashed into it.

Concurrency – Thread Pools

Question: How does a Java thread pool handle a worker thread that throws an exception? Answer: The pool discards the faulty thread and creates a replacement thread, unless a custom RejectedExecutionHandler or other error‑handling policy is configured.

Most candidates could name the default Executors implementations ( ThreadPoolExecutor, ScheduledThreadPoolExecutor, etc.) but could not explain internal details such as core vs. maximum pool size, keep‑alive time, or the impact of different RejectedExecutionHandler strategies.

Redis – Caching Concepts

Question: What are cache‑penetration, cache‑snowball (cache avalanche), and the two persistence mechanisms in Redis? Answer: Cache‑penetration occurs when requests for non‑existent keys bypass the cache and hit the backing store repeatedly. Cache‑snowball (or avalanche) happens when many keys expire simultaneously, causing a sudden surge of load on the database. Redis persistence options are AOF (Append‑Only File) which logs every write operation, and RDB snapshots that periodically dump the dataset to disk. Both can be configured for asynchronous flushing.

Several candidates only mentioned using Redis as a simple cache without understanding these failure modes or persistence trade‑offs.

JVM Garbage Collection – Stop‑The‑World

Question: Under what conditions does a Stop‑The‑World (STW) pause occur? Answer: A Full GC of the old generation triggers an STW pause. The CMS (Concurrent Mark‑Sweep) collector is commonly used for the old generation; when it performs a Full GC, all application threads are stopped.

Only a few interviewees could cite the specific collector and explain why Full GC is more disruptive than minor GCs.

Key Technical Takeaways

Superficial familiarity (e.g., knowing default HashMap size = 16) is insufficient; interviewers should probe the underlying algorithms, thresholds, and concurrency implications.

Understanding the lifecycle of thread‑pool workers, especially error handling and rejection policies, distinguishes experienced engineers from those who have only used defaults.

Cache‑layer design requires awareness of penetration, avalanche, and persistence strategies; merely “using Redis” does not demonstrate competence.

JVM performance tuning demands knowledge of which GC phases cause STW pauses and how specific collectors (CMS, G1, ZGC) behave.