Merge K Drone Telemetry Streams Into a Running Altitude Timeline
CitadelSoftware Engineer · Technical ScreenLast updated
Interleave K drones' individually time-ordered altitude logs into a single replay and track the fleet's shared altitude total as each logged change is applied. Tests k-way merging with a heap, a deterministic tie-break across drones, and correct handling of negative deltas and drones with no events.
A fleet of K drones each logs altitude-change events locally: every event is [timestamp, delta], meaning the drone's altitude changed by delta at that timestamp. Each drone's own log is already sorted by timestamp (non-decreasing), but the K logs were recorded independently and have no ordering relationship with each other. A drone is identified purely by where its log sits in the logs list — the first entry is drone 0, and so on up to K - 1.
Replay every event from every drone as a single chronological stream, tracking one shared absolute altitude that starts at 0 and changes by each event's delta as it's processed. Return the altitude recorded immediately after each event, in the order the events were processed.
Function Signature
def running_altitude(logs: list[list[list[int]]]) -> list[int]:
Rules
- Processing order. Earlier timestamps always go before later ones. For a tie between two different drones, whichever drone appears earlier in
logsgoes first. For a tie within the very same drone's own log, its existing order wins (it's already sorted, so this is just its natural sequence). Put differently, sort the full key(timestamp, drone_index, position_within_that_drones_log)ascending. - Running altitude. Begins at
0before anything is processed. Each event, as it's handled, adjusts the running total by its owndelta, and that updated total becomes the next entry written to the result — so the result ends up exactly as long as the combined event count across every drone. - Negative deltas.
deltacan be negative, and altitude can go below zero; it is never floored at 0. - Empty logs. A drone that logged nothing simply never shows up in the merged stream. In the degenerate case where every drone (or the whole fleet) has nothing logged, the output is an empty list.
Example
logs = [
[[1, 10], [1, -3], [5, 2]],
[[1, 4], [3, -1]],
]
running_altitude(logs) -> [10, 7, 11, 10, 12]
Processing order: drone 0's two events at timestamp 1 (in their own log order: +10 then -3) come before drone 1's event at timestamp 1 (+4), since drone 0 has the lower index; then drone 1's event at timestamp 3 (-1); then drone 0's event at timestamp 5 (+2). Running altitude: 10, 7, 11, 10, 12.
Constraints
0 <= K == len(logs) <= 10^40 <= N <= 10^5;Ndenotes however many events the whole fleet logged once every drone's entries are counted together.- Every event is
[timestamp, delta]with0 <= timestamp <= 10^9and-10^6 <= delta <= 10^6. - Within a single drone's log, timestamps are non-decreasing (ties within one log are possible).
- The running altitude always stays within
[-10^11, 10^11], which exceeds a 32-bit signed range — use 64-bit accumulation in a fixed-width language (plainintin Python needs no special handling). - The output has exactly
Nentries and is uniquely determined by the rules above.
Hints
Hint 1
A full sort of all N events by the tie-break key works and is simple to reason about, but a K-way merge avoids ever materializing and sorting the full combined list.
Hint 2
A min-heap holding one 'current candidate' event per drone, keyed by (timestamp, drone_index, position), lets you always pop the globally next event in O(log K).
Hint 3
After popping a drone's event, the only thing that can replace it as that drone's new candidate is the very next event in that same drone's own log — push that one back in, if it exists.
Hint 4
The tie-break key needs to be part of what you compare in the heap, not just the timestamp, or events sharing a timestamp across drones could come out in the wrong order.
Follow-up questions
- How would you adapt this if each drone's log arrived as a live stream (not a fixed list), and you needed to emit altitude updates as events arrive rather than after collecting everything?
- If K could be as large as N (many drones, each with very few events), how does that change which approach — full sort versus heap-based merge — is actually faster in practice, despite both having similar asymptotic bounds?
- How would you extend this to report, at the end, which single drone contributed the event that produced the highest altitude ever recorded?
- Suppose two different drones could report conflicting deltas for what's actually the same physical event due to clock skew. How would you detect that this tie-break rule is masking a data quality problem rather than a true ordering?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.