Prompt and use cases
A dataset having values does not mean it is fresh. The answer should turn a business availability deadline into measurable indicators and locate delay in ingestion, transport, processing, or publication.
What the interviewer evaluates
- Whether event, arrival, processing-complete, and serving times are distinct.
- Whether datasets, partitions, and business uses get appropriate SLOs.
- Whether lineage, run, quality, and freshness evidence are retained.
- Whether a successful job is separated from usable data.
- Whether alert suppression, escalation, backfill, and replay paths exist.
- Whether a freshness breach is connected to downstream user impact.
Clarifications before answering
- What are the business deadline, update cadence, and time zone?
- Does freshness start at event creation, landing, or query availability?
- Which partitions, fields, and reports are on the critical path?
- What delay, gap, and backfill window is acceptable?
- Can upstream provide event time, batch ID, and retry metadata?
- On a breach, should reports freeze, show a data-status label, or continue?
30-second answer framework
“I would define queryable freshness against the business deadline and record event, landing, and serving times separately. For each critical dataset, I would calculate a partition-level freshness SLI and combine lineage, run state, row counts, and quality assertions to locate delay. Alerts would separate warning from breach so a successful job cannot hide a gap. Recovery would use retries, backfill, replay, and downstream labeling, with user impact and SLO budget guiding improvement.”
Step-by-step deep dive
Step 1: Define time semantics. State event time versus queryable time and handle late events, time zones, and daylight saving rather than relying only on job end time.
Step 2: Define SLI and SLO. For example, measure the fraction of partitions queryable before the deadline, with different targets for critical reports and exploratory data.
Step 3: Collect run evidence. Store run metadata, input and output partitions, lineage, row counts, null checks, and quality assertions linked to a dataset version.
Step 4: Localize delay. Break end-to-end delay into ingestion, transport, queueing, computation, and publication; distinguish upstream absence from downstream failure.
Step 5: Design alerts. Warnings use remaining time and trend, while breaches use actual impact. Deduplicate by dataset and partition and assign silence, escalation, and ownership.
Step 6: Recover and replay. Use idempotent batches, checkpoints, and bounded backfills, then rerun affected partitions and publish data status and update time.
Step 7: Improve the system. Track budget consumption, root-cause share, and false alerts, then change scheduling, capacity, partitioning, or product commitments.
Model high-quality answer
“The revenue report has an 08:00 local business deadline. I define fresh as the daily partition being queryable by 08:15 and separately measure event-to-landing delay. Monitoring reads input and output partitions, lineage, row counts, and quality assertions from run metadata; a successful run with a missing partition is still a freshness risk. Before 08:00 we warn on remaining time, and after 08:15 we escalate by report impact. Recovery backfills idempotently by batch ID and labels report status. Reviews break budget use down by ingestion, transport, and compute causes.”
Common mistakes
- Monitor job success only → partition gaps stay hidden → check queryable partitions and the business deadline.
- Use processing end time only → late events are misread → retain event, landing, and serving times.
- Give every dataset one threshold → priorities disappear → tier by use and critical path.
- Alert without owner or escalation → nobody acts → bind a window, owner, and recovery action.
- Overwrite during backfill → duplicates or versions are unclear → record idempotent batch, range, and version.
Follow-up questions and responses
Follow-up 1: What if upstream has no event time?
Use landing time as a temporary, clearly limited metric and require upstream to add event time and batch metadata.
Follow-up 2: What if late data has no current user impact?
Track technical SLI and user impact together, and decide budget consumption against the business commitment.
Follow-up 3: How do you prevent alert storms?
Aggregate root causes through lineage, then apply warning windows, deduplication, silencing, and escalation.
Follow-up 4: What should downstream do during backfill?
Publish data status and update time, freeze or label critical reports, and prevent incomplete results from being treated as final.
Follow-up 5: How do you validate that the SLO reflects business needs?
Interview report users, compare breaches with decision delay or customer impact, and recalibrate the window regularly.
Follow-up 6: What if late data changes historical partitions?
Define a backfill window and version semantics, record the recomputation range, and notify downstream caches and incremental models.
Follow-up 7: What improvement matters most?
Fix the root cause consuming the most budget on critical user paths before adding more dashboards.