Hard Runtime Diagnostics interview problem
Premature promotion and survivor overflow in a batch rollup
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 nightly aggregation job computes correct per-series summaries but holds every intermediate value until a final reduce. Temporary batch state survives young collections, overflows survivor capacity, and is promoted unnecessarily.
This is a hard production-debugging exercise because the collector is behaving as designed; the application accidentally gives short-lived data a long lifetime, so runtime-flag tuning treats the symptom. 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
The job folds hundreds of thousands of raw records into a small fixed set of counts, totals, minima, and maxima. Only those summaries need to outlive each input record.
The starter first accumulates the complete intermediate dataset and reduces later. Object lifetime follows total batch duration instead of the few instructions needed to update one summary.
What you’ll practice
- Reading survivor overflow and promotion signals
- Relating object lifetime to batch pipeline shape
- Reducing records incrementally into fixed summaries
- Bounding peak intermediate state
- Preserving aggregate counts and digest exactly
How to approach it
Identify which objects appear in old-generation growth but have no role in final output. Trace why references to them remain alive across multiple young collections.
Fold each record into its series summary as it arrives and release batch-local state promptly. Compare peak intermediates and long-lived growth at multiple workload sizes while keeping the pinned digest identical.
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 Premature promotion and survivor overflow in a batch rollup?
Begin with the promotion and survivor-space report, peak intermediate-state ledger, old-generation growth, and pinned aggregate digest. 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 collector is behaving as designed; the application accidentally gives short-lived data a long lifetime, so runtime-flag tuning treats the symptom. 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.