Hard Runtime Diagnostics interview problem
Missed signal in a handoff queue
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
An ingestion pipeline processes its records but never finishes shutting down. Consumers remain parked on a condition variable, and some schedules let workers leave while the queue is still logically open.
This is a hard production-debugging exercise because condition variables do not remember notifications; correctness comes from rechecking shared state under the lock across many possible schedules. 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
Producers hand records to consumers through a bounded queue with an explicit close operation. Consumers must wait while no work is available, resume when state changes, and terminate only when the queue is both closed and drained.
The predicate and notification are not coordinated under one synchronization protocol. A signal can occur before a waiter is enrolled, shutdown may not wake every consumer, and a consumer may test stale state.
What you’ll practice
- Reading parked condition-variable frames in a thread dump
- Defining the queue’s wait predicate precisely
- Changing state and signaling under one lock protocol
- Handling spurious wakeups with a loop
- Waking all consumers during close while draining queued work
How to approach it
Write the consumer predicate in terms of queue state, independent of any notification: work is available, or no future work can arrive. Then audit where that state changes and which waiters are notified.
Exercise close-before-wait, close-while-waiting, and work-arrives-during-wait schedules repeatedly. Progress must follow the predicate even if timing changes, because a notification itself is not durable state.
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 Missed signal in a handoff queue?
Begin with parked consumer stacks, queue open and empty state, producer and shutdown ordering, and completion counts across repeated schedules. 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 condition variables do not remember notifications; correctness comes from rechecking shared state under the lock across many possible schedules. 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.