Where it comes from

How to answer

One candidate reported, in August 2026, that their interviews for an L5 role in Google’s Cloud AI division had no LeetCode and included a real-scenario question about streaming. Source 1Google FDE vs Remain Amazon SDEPublisherBlind (teamblind.com)Source typecandidate report on BlindSource 2Google L5 FDE vs Remain Amazon L5 SDEPublisherBlind (teamblind.com)Source typecandidate report on Blind The poster did not describe the question. This prompt is a streaming problem of that kind: the parsing is easy, and the grade is in what “when trips end” means once events arrive out of order.

  1. Ask who reads the summaries. A dashboard can take a provisional number and a later correction. Billing may need one final number. That answer decides whether you emit at the end event or wait, so get it before you design.
  2. Define time and lateness out loud. Use event time, with a watermark at the newest timestamp seen. Pick an allowed lateness: how long after a trip ends it still accepts events. Say the trade: a longer lateness means more correct summaries, more memory and a later final.
  3. Know which aggregates depend on order. Earliest start, latest end and counts don’t. Distance from GPS points does: a late point belongs between two you’ve already joined. Keep each open trip’s points sorted by time, and when point x lands between p and q, change the distance by d(p,x) + d(x,q) - d(p,q). Delivery is at least once, so deduplicate by event ID.
  4. Emit versions. A provisional summary at the end event, a correction when a late event changes it, and a final one when the watermark passes the trip’s deadline. Downstream keeps the highest version per trip.
  5. Bound the state. Hold only open trips. Close a trip with no end after an idle timeout, remember closed trip IDs for far longer than the lateness, so a straggler can never open a second trip under the same ID, and send anything too late to a counted side output.
  6. Test against a batch oracle on shuffled, redelivered input whose disorder stays within the lateness.

The trap is emitting at the end event and deleting the state. The first late ping then disappears, or opens a second trip under the same ID.

GlossaryForward deployed engineerA software engineer who builds and ships production systems inside a customer’s problem and environment, accountable to that customer’s outcome.More on Forward deployed engineer

Follow-ups

What the interviewer may ask next, once your first answer is on the table.

  • A phone loses signal and uploads a whole trip an hour later. What does your code do with it, and what should it do?
  • One device’s clock is a day ahead. What happens to every other trip in flight?
  • The stream goes quiet overnight. Which trips never get a final summary, and how do you fix that?
  • The processor crashes and restarts. What state has to survive, and how do you avoid sending a trip’s final summary twice?
  • Billing wants exactly one number per trip and cannot take corrections. What do you give up to deliver that?
  • One GPS point jumps a kilometer off the route and back. What does your distance do, and where do you filter it?

Where answers go wrong

  • Emits the summary when the end event arrives and deletes the trip’s state, so a late ping either vanishes or opens a second, partial trip under the same ID.
  • Keeps state for every trip ever seen, including trips whose end never arrives, so memory grows until the process dies.
  • Measures lateness with the machine’s clock instead of event time, so a backlog or a replay produces different summaries from the same events.

Answer this in two minutes

Write the answer you would say out loud. The clock starts with your first word.

Two minutes

Model answer

“Two questions first. Who reads the summaries?

Learn this in Module 5: Practical coding for FDE rounds, part of the curriculum.