An event arrives twenty minutes late. Which day's metric includes it?
Whether the candidate separates event time from processing time and can state a lateness policy rather than describing whatever their tool happens to do.
The situation behind the question
Interviewers ask this because it happened to them.
Mobile clients buffer events while offline. An event with an event time of 23:52 arrives at 00:12 the following day. The daily revenue figure for the first day was published at 02:00 and quoted in a morning report.
A strong answer
Flags
Green flags
- Expects duplicates and late data as normal conditions rather than as incidents.
- Separates event time, arrival time and publish time, and knows which one the consumer is actually asking about.
- Frames it as a policy decision with a stated lateness window, not as tool behaviour.
- Raises the consumer contract: provisional versus final periods, and revisions made visible.
Red flags
- Answers with a single confident day without asking how windows are assigned.
- Assumes the framework handles it, without being able to say what watermark or lateness setting is in effect.
- Treats a revised figure as a bug rather than as the consequence of a policy nobody published.
- Cannot distinguish a late event from a lost one, which is the same observation in an open period.
Follow-ups
Where the conversation goes if the first answer holds up.
- A regional outage delays a full day of events by eighteen hours. Does your answer change?
- The morning report has already been sent with the lower figure. What do you do?
- How would you monitor for lateness increasing, before it becomes a wrong number?