Truck Position Subscriber
Reported by candidates from Optiver's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Optiver reported this one in July 2023, and it looks like a trucking problem until you read the operations twice. It's a pub-sub design question in disguise. You keep the server state, track who subscribed to what, and hand each client only the deltas that landed after their subscription. If you've got an OA invite for this, expect to spend more time on the bookkeeping than on any clever algorithm. StealthCoder sits invisibly on your screen as a safety net if the event ordering gets tangled mid-assessment.
The problem
A central server tracks truck positions. Local clients subscribe through one subscriber service so they receive only the truck updates they need. Truck i starts at initialPositions[i] = [x, y]. Process these operations in order: U truckId deltaX deltaY moves that truck. The server position always changes, even when no client has subscribed yet. S clientId truckId subscribes the client and immediately returns the truck's current position. Later duplicate subscriptions are idempotent but still return the current position. R clientId returns every update to any truck that client subscribed to after that subscription and since the client's previous request. Preserve the original global update order, then clear those pending updates for that client. Return one string for every subscription result and every delivered update. Use S clientId truckId x y for a subscription and U clientId truckId deltaX deltaY for a delivered update. Function truckPositionUpdates(initialPositions: double[][], operations: String[]) → String[] Examples Example 1 initialPositions = [[2,3]] operations = ["U 0 1.5 2.5","S 0 0","U 0 1 2","U 0 -0.5 -0.5","S 1 0","R 0","U 0 1 1","R 1"] return = ["S 0 0 3.5 5.5","S 1 0 4 7","U 0 0 1 2","U 0 0 -0.5 -0.5","U 1 0 1 1"] The first update changes the server position before any subscription. Client 0 later receives two deltas, while client 1 receives only the delta that occurred after its own subscription. Constraints 1 <= initialPositions.length, operations.length <= 10^5 Every truck ID is a valid zero-based row index. Client IDs are nonnegative integers. Coordinates and deltas are finite decimal values. A request names a client that has subscribed at least once.
Reported by candidates. Source: FastPrep
Pattern and pitfall
What it really reduces to: an append-only global log of updates, plus a per-client cursor. Every U appends (truckId, dx, dy) to the log and mutates the truck's position. A subscription records the client's start index in the log, which is the current log length, and returns the current position. An R scans the log from that client's cursor to the end, emits only entries for trucks that client subscribed to, then moves the cursor to the end. That preserves global order for free. The pitfall is duplicate subscriptions. They must not reset the cursor or you'll drop pending updates, so store a subscribed-at index per client and truck pair and keep it on repeats. Another trap is delivering updates from before the subscription time. Compare each log index against that pair's subscribe index. Format doubles carefully, since 4 prints as 4 in the example. StealthCoder is your hedge if the cursor logic slips live.
If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.
You can drill Truck Position Subscriber cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Optiver's OA.
Optiver reuses patterns across OAs. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Truck Position Subscriber FAQ
What's the trick in the Truck Position Subscriber problem?+
Keep one global update log and a per-client cursor. Updates append to the log. A request walks the log from the cursor, filters by that client's subscribed trucks and subscribe time, then advances the cursor. Global order comes for free.
How do duplicate subscriptions work?+
They're idempotent. Return the current position again, but don't change the stored subscribe index for that client and truck pair. Resetting it would silently drop updates the client was still owed.
Do I need a per-client queue instead of a shared log?+
A per-client queue works but costs memory, since each update gets copied to every subscriber. The shared log with cursors is cleaner. Just make sure scanning stays bounded so 10^5 operations don't turn quadratic.
How should I handle the decimal output formatting?+
The example prints 4 and 7 rather than 4.0 and 7.0, and keeps 1.5 style values as is. Match that exactly. Test a case with a whole-number result and one with fractions before you submit.
How do I prepare for this Optiver OA in 48 hours?+
Practice design-style simulation problems with event logs and cursors. Write the operation parser first, then the subscription map, then the request scan. Test the example where an update happens before any subscription, since that case catches most bugs.