Data Quality and Contracts

TL;DR: Everything downstream, models, features, dashboards, inherits the quality of the data, and a silent upstream change (a renamed or retyped column, a units switch, a surge in nulls, a duplicated load) corrupts results with no error thrown. Data quality means automated checks (schema/types, value ranges, null rates, freshness, row-count/volume, uniqueness) running in the pipeline, plus data contracts between producers and consumers (an agreed schema and semantics, enforced in the producer's CI) so breaking changes cannot ship unannounced. "Garbage in, garbage out" is the most common, hardest-to-diagnose failure.

Why bad data is worse than a crash

A crash is obvious; bad data is silent. An upstream team renames a column, changes a unit (dollars to cents), or a load duplicates, and your model or dashboard keeps running, now wrong. These failures are insidious because nothing errors; you discover them when a metric looks off or a model degrades, often long after.

Worked example: a payments team ships a "cleanup" that changes amount from dollars to cents. Your fraud model's transaction_amount feature jumps 100x. The model still scores every transaction, but its threshold (tuned on dollars) now flags almost nothing as fraud. No exception, no failed job. You catch it three days later when chargebacks spike. A single range check (amount BETWEEN 0 AND 50000) on the feature would have halted the load the moment cents arrived.

Automated checks

Validate data as it flows, ideally before it reaches models or dashboards:

• Schema and types: columns exist with expected types; catch renames/retypes.
• Value ranges and validity: values within plausible bounds (no negative ages, no 100x spikes).
• Null rates: a jump in nulls signals an upstream break.
• Freshness and volume: data arrived on time and the row count is in the expected range (catch missing or duplicated loads).
• Uniqueness: primary keys are unique (catch duplicate loads).

Failing checks should halt the pipeline or alert, not silently propagate bad data. In practice this is a dbt test or a Great Expectations / Soda suite wired as a gate between staging and the published table:

# dbt schema test: blocks the run if any assertion fails
models:
  - name: fact_orders
    columns:
      - name: order_id
        tests: [unique, not_null]
      - name: amount_cents
        tests:
          - dbt_utils.accepted_range: {min_value: 0, max_value: 5000000}
    tests:
      - dbt_utils.recency: {datepart: hour, field: loaded_at, interval: 6}

Tier the severity: schema and uniqueness failures should be error (stop the pipeline), while a null-rate or volume drift can be a warn that pages a human without blocking. A check that always blocks gets disabled the first time it fires at 3am on a false alarm.

Data contracts

Many quality problems originate upstream, so the systemic fix is a data contract: an explicit agreement between the producer and consumers on the schema, types, and semantics, enforced in the producer's CI so a breaking change (a rename, a type change) cannot ship without coordination. This stops breakage at the source rather than discovering it downstream, and it pairs with feature-store consistency and schema evolution practices.

Concretely: the contract lives next to the producer's code (a Protobuf/Avro schema or a versioned dbt model contract), and the producer's CI fails the merge if a change is incompatible. The dividing line is additive vs breaking: adding a nullable column is safe and ships freely; dropping a column, renaming one, narrowing a type, or changing units is breaking and requires a deprecation window. This is the same expand-then-contract discipline used for schema migrations.

Why interviewers probe this

"Garbage in, garbage out" is the most common and hardest-to-diagnose cause of model and analytics failures, and a candidate who only tests code misses it. A strong answer treats data as something to validate automatically (schema, ranges, nulls, freshness, volume, uniqueness) and proposes data contracts enforced in producer CI to stop silent breaking changes at the source. The follow-up they hold: "who owns the check, and what happens when it fires at 3am?" The answer is severity tiers and an owning team, not a wall of blocking assertions nobody triages.

Common misconceptions

• "If it does not error, the data is fine." Bad data is silent; you must check it explicitly.
• "Validate at the model." Validate at the data layer, before it reaches models/dashboards, and halt on failure.
• "Quality is the consumer's problem." Data contracts push enforcement to the producer's CI, stopping breakage at the source.
• "Schema checks are enough." Also check ranges, nulls, freshness, volume, and uniqueness; a unit switch passes every schema check.

Key takeaways

• Downstream quality is bounded by data quality, and bad data fails silently (no error).
• Run automated checks: schema/types, value ranges, null rates, freshness, volume, uniqueness, halting on failure.
• Use data contracts enforced in the producer's CI so breaking changes cannot ship unannounced.
• "Garbage in, garbage out" is the most common, hardest-to-diagnose model/analytics failure.