How the interviewer opens it
“Design a platform that detects missing, stale, malformed, or unusual data across analytical datasets. Keep its cost to production systems within agreed limits.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Dataset scale
- Check scale and frequency
- Source access and snapshots
- Check meaning
- Latency
- Source cost limits
- Read and write mix
- Consistency, availability, and durability
- Anomalies and alerts
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Define checks and expected arrival times for datasets.
- Evaluate checks within source cost limits.
- Track results, coverage, and metric history.
- Send alerts for data failures and check failures.
Usually out of scope
- Repair data or change source pipelines.
- Execute arbitrary user code.
- Scan transactional databases.
- Provide a general data catalog.
What interviewers ask about
- Cost on source systems
- Checks share data, but their combined source work must remain below a hard limit despite wrong estimates, failures, and concurrent tenants.
- Data state and time
- Late data, source failures, and corrections have different meanings. A version identifier does not prove that an evaluation read one consistent state.
- Unusual data and alerts
- Normal data varies by time and dataset. Weak baselines create false alerts, while one source failure can affect many datasets.
- Check completion and failures
- Shared due times create bursts. External queries can outlive workers, and retries can repeat costly reads or publish results in the wrong order.
Common mistakes
- The design assigns a separate full scan to every check.
- The design treats source errors, partial scans, or skipped checks as successful data checks.
- The design assumes that version identifiers guarantee consistent snapshot reads.
- The design claims a hard global scan limit from estimates, cancellation, or independent tenant budgets.
- The design ignores expected arrival schedules and reuses metrics after data corrections.
- The design starts with complex anomaly models before it defines coverage, baseline readiness, and incident behavior.
The bar by level
- Senior (L5/E5)
- Estimates query cost and capacity. Reuses valid metrics, handles corrections, and ties results to verified snapshots. Defines baseline readiness and retries. Enforces source caps through global reservations.
- Staff (L6+/E6+)
- Proves the scan limit during uncertain submissions, retries, day changes, and failover. Defines exact-result guarantees for each source capability. Resolves fairness and recovery costs.