Hard Runtime Diagnostics interview problem
Thread pool starvation from nested task submission
Written and reviewed by Sahil Srivastav
This problem is available as the same repository challenge in Python, Java, Node.js, and C++. Open the full problem and choose a language
What this interview round tests
A telemetry enrichment service handles a few batches but produces nothing once the batch count reaches the fixed pool size. CPU drops to zero, the work queue grows, and widening the pool only moves the threshold.
This is a hard production-debugging exercise because the system resembles deadlock without a lock cycle, and the nearby throttle is a convincing but incorrect suspect. It tests whether you can move from operational evidence to a narrow invariant, then make a repair that survives concurrency, retries, failures, or workload growth instead of merely passing one happy-path example.
The scenario
Each batch is split into independent shards for parallel enrichment, and reference lookups are guarded by a separate throttle. Every input record must produce one ordered result under a fixed caller-selected pool size.
Outer batch tasks occupy every executor worker, submit inner shard tasks to the same executor, and synchronously wait for them. The queued inner tasks cannot start because the workers that could run them are blocked.
What you’ll practice
- Recognizing executor starvation in thread dumps
- Reasoning about nested submission to a bounded pool
- Separating orchestration from worker execution
- Preserving result order under parallel work
- Testing liveness beyond the pool-size threshold
How to approach it
Compare what each worker is waiting for with what remains in the executor queue. If every running task waits for queued work that requires the same workers, changing timeout or pool size cannot establish progress.
Restructure task decomposition so executor workers perform runnable work rather than synchronously waiting on descendants in the same saturated resource. Verify small, threshold, and much-larger cycles.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
Try it in a real repository
LeetCode teaches algorithms. Gronex teaches backend coding rounds with real repositories, failing tests, service logic, and production-style constraints. Read the diagnostic brief on this page, then open the challenge workspace when you are ready to investigate the repository.
FAQ
What should I inspect first in Thread pool starvation from nested task submission?
Begin with the stalled thread dump, executor worker and queue counts, completed-batch counters, and reference-lookup activity. The supplied evidence narrows the failure mode before you touch the implementation, which is the same evidence-first habit expected during a production incident or senior backend interview.
What makes this a hard runtime diagnostics problem?
It is hard because the system resembles deadlock without a lock cycle, and the nearby throttle is a convincing but incorrect suspect. The test suite checks the underlying invariant and adverse execution paths, so a local patch or a larger resource limit will not satisfy the challenge.
Which languages can I use for this repository challenge?
The same scenario is implemented in Python, Java, Node.js, and C++. Each language directory includes its own source, evidence or database setup, tests, and verify.sh entry point while preserving the same production invariant.