1. Question and Context
This question tests data-platform, data-engineering, and analytics-engineering judgment. The focus is the health and impact of the data itself, not only whether an orchestration task finished. A strong answer covers dimensions, baselines, ownership, alert severity, and recovery.
2. What the Interviewer Is Evaluating
- Whether you decompose observability into freshness, volume, schema, completeness, distribution, uniqueness, and relational integrity.
- Whether rules vary with dataset use, lineage, and business impact instead of sharing one threshold.
- Whether observations retain rule versions and run evidence, separating blocking failures, warnings, and unknown state.
- Whether alerts lead to quarantine, backfill, reconciliation, and review rather than a message with no owner.
MentorCruise's public data-engineering interview guide asks directly what data observability means and lists freshness, volume, schema drift, nulls, duplicates, distribution, and lineage. Great Expectations documents distribution, freshness, integrity, missingness, schema, uniqueness, and volume as data-quality use cases, and defines an Expectation as a verifiable assertion about data.
3. Clarifying Questions Before You Answer
- Does the dataset serve reporting, settlement, recommendations, or training? What are the latency and error impacts?
- Is the source batch, streaming, or hybrid? How are event time and arrival time defined?
- Which failures block publication, and which only warn? Is a trusted snapshot available for degradation?
- Who owns the asset, lineage, and alert? Which partitions need backfill and which consumers need notification?
4. A 30-Second Answer Framework
I would tier datasets by business impact, then define freshness, volume, schema, completeness, distribution, and relationship checks for each critical asset. Every run records rule version, batch, observations, lineage, and owner; results route as block, warning, or information. Downstream readers consume the quality state, with quarantine or a timestamped trusted snapshot when appropriate. After repair, I rerun the same check version, reconcile input, output, rejected, and consumed records, and tune thresholds during review.
5. Step-by-Step Deep Dive
Step 1: Define Assets and Criticality
Give tables, topics, files, and model inputs stable identities, with owners, consumers, sensitivity, and lineage. Cover high-impact assets such as settlement and customer-facing metrics first; otherwise check cost and alert volume grow without control.
Step 2: Choose Complementary Signals
Freshness checks business and arrival timestamps; volume checks rows, files, or bytes; schema checks fields, types, and compatibility; completeness checks required values, duplicates, and references; distribution checks ranges, quantiles, or category frequencies. Retain sample size, window, threshold, and rule version for every metric so one score cannot hide the failure dimension.
Step 3: Make Checks Actionable and Explainable
Keep declarative assertions and custom queries in code review and deployment. Give critical rules a severity, failure action, and owner; use baselines and consecutive windows for low-volume or seasonal assets. Write results to a quality ledger linked to the partition, run, upstream change, and downstream impact.
Step 4: Connect Alerts, Quarantine, and Recovery
Block publication when bad data would contaminate finance or a model. Quarantine a local gap and retain a timestamped trusted snapshot when a broader block is unnecessary. Alerts include asset, dimension, observation, threshold, lineage, and suggested action. After an upstream fix, backfill by business time and use idempotent writes plus input/output reconciliation to prove there is no loss or duplication.
6. High-Quality Sample Answer
I would tier assets by business impact and register owners, consumers, and lineage for critical ones. Each load checks arrival and business time, row or byte volume, schema, required fields, duplicates, relationships, and key-value distributions. Results retain the rule version, batch, sample size, observation, and downstream impact; severity determines whether publication is blocked, warned, or merely recorded.
If a settlement table fails completeness, I quarantine the batch and block publication. An independent dashboard may use the previous trusted snapshot with its timestamp. The alert names the failed dimension and likely upstream change instead of exposing one opaque score. After repair, I backfill partitions, rerun the same checks, reconcile input, output, rejected, and consumed records, and close the incident only after the metrics recover. Finally, I use false alarms, misses, and handling time to tune thresholds and coverage.
7. Common Failure Modes
- Checking only whether the DAG succeeded, not whether data is fresh, complete, and usable.
- Applying one threshold to every asset while ignoring consumers, seasonality, and sample size.
- Omitting rule versions, batches, or lineage so an alert cannot be reproduced.
- Blocking the whole platform for every failure, or automatically retrying bad data into downstream systems.
- Overwriting history after repair without recording backfill, reconciliation, and duplicate-write protection.
8. Follow-Up Questions and Responses
Follow-up 1: How is data quality different from data observability?
Quality checks verify an assertion. Observability also connects health signals with run context, lineage, ownership, impact, and action. Quality is one signal in the operating loop, not the whole loop.
Follow-up 2: How do you reduce false alarms?
Use historical baselines by asset and segment, retain sample size, require consecutive windows, and apply severity levels. Observe new rules in shadow mode and preserve old versions while reviewing the cost of false alarms.
Follow-up 3: Should every failed check block publication?
Decide from impact and lineage. A failure that can contaminate settlement, customer commitments, or training should block the related publication; low-risk consumers may read a warned trusted snapshot. Scope, escalation timeout, and release conditions must be auditable.