Hard Runtime Diagnostics interview problem
Finalizer and cleaner backlog in a scratch file service
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 thumbnail service delegates scratch-file cleanup to object finalization. Under load, completed jobs outpace the finalizer, so descriptors and files survive far beyond the operations that created them.
This is a hard production-debugging exercise because garbage collection controls managed reachability, not timely release of scarce native resources, and forcing collection only hides the ownership bug. 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 rendering job opens a scratch resource, writes and rereads payload bytes, computes a digest, and returns. Once the job returns, no normal execution path needs the resource again.
The wrapper’s destructor or cleaner is treated as the primary release mechanism and participates in delayed reclamation. Eventual collection may close the resource, but runtime scheduling cannot provide a prompt lifecycle guarantee.
What you’ll practice
- Reading finalizer backlog and handle evidence
- Separating managed memory from native resource lifetime
- Applying deterministic close semantics on every path
- Keeping a finalizer only as a safety net
- Testing cleanup before any forced collection
How to approach it
Locate the code that knows the job has finished with the scratch resource; that boundary, not the collector, owns normal release. Check success and failure paths for the same guarantee.
Measure immediately after the workload without calling the collector. Digests and bytes must remain pinned while open handles, remaining files, and finalizer-driven releases all fall to zero.
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 Finalizer and cleaner backlog in a scratch file service?
Begin with the handle-backlog capture, finalizer activity, open descriptor counts, scratch-directory contents, and job digest assertions. 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 garbage collection controls managed reachability, not timely release of scarce native resources, and forcing collection only hides the ownership bug. 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.