Data Quality Interview Questions cheat sheet

Contracts, tests versus expectations, freshness, reconciliation, and the quality questions interviews use to test production judgment.

Interview PrepIntermediate6 sections

Definitions

What does 'data quality' mean in a pipeline, concretely?: The data is complete, unique at the declared grain, well-typed, fresh within an SLO, and reconcilable to the source. Vague answers like 'accurate and reliable' fail this question. Interviewers want dimensions you can test.
What is a data contract and who enforces it?: A schema plus semantics the producer guarantees and the consumer can fail a deploy on. Enforcement belongs in the producer's CI and at the ingestion boundary, not only in a downstream dbt test after bad data has already landed. A contract nobody can fail a build with is a document.
Quality versus observability versus testing — how do you separate them?: Tests are assertions you run in a build. Observability is freshness, volume, and distribution over time. Quality is the union plus the process when something fails. Teams that only have tests find out about silent zero-row loads from a user.
When is a warning better than a failing test?: Known-imperfect sources where a small number of bad rows is the cost of doing business. A permanently red build trains people to ignore failures. Use severity warn plus a threshold, and keep fail for grain and not-null on keys.

What tests does every model need?: unique and not_null on the primary key. If you cannot name a testable key, the grain is undefined. Relationships on important foreign keys next. Everything else is situational. Interviewers treat 'we have 400 tests' without key tests as a smell.
How do you test a metric definition?: A singular test that reconciles the mart to a source-derived total within a tolerance, plus a unit test for the CASE or window logic with fixed fixtures. Testing only that revenue is not null does not catch a doubled join.
Where should checks run — files, warehouse, or both?: At the ingestion boundary so you do not load garbage, and at the gold boundary so you do not publish it. Testing only gold means bad data has already been copied into five downstream tables. Pre-load checks belong in GX or a file validator; warehouse checks belong in dbt or Soda.
How do you test freshness?: max(event_time) compared to now, or a source freshness block in dbt, or a Soda freshness check. Job success is not freshness. A DAG that succeeds on zero rows is the classic freshness incident.
What is a volume anomaly check and when does it fail you?: Row count versus a baseline or a threshold. It catches empty loads and exploded joins. It fails you on the first day of a real business change (Black Friday) unless the baseline is seasonal or someone can acknowledge the alert. Pair it with a human-ack path.

dbt tests versus Great Expectations versus Soda — how do you choose?: dbt tests when data is already in the warehouse and the team owns the models. GX for pre-load DataFrames and file validation, and when stakeholders want Data Docs. Soda when analysts must read and edit checks, and for freshness and anomaly detection out of the box. Default to dbt; add a second tool with a reason.
What is store_failures and why do you turn it on?: dbt writes failing rows to a table so you can query what broke. Without it, an incident is a red X and a guess. Turn it on for tests you actually triage. Storing failures for 200 noisy tests just creates another swamp.
How do unit tests in dbt differ from data tests?: Unit tests run transformation logic against fixed inputs and need no warehouse data. Data tests run against real tables. Unit tests catch CASE bugs; data tests catch yesterday's broken source. Put unit tests in the pre-merge CI stage.
What does a contract: enforced model do in dbt?: The build fails if columns or types drift from the declared schema. It is a breaking-change guard for published models. Without it, a renamed column ships and twenty dashboards break on Monday.

Source says 10,412 orders, the warehouse says 10,387. What do you do?: Do not start in the mart. Compare bronze to source, then silver to bronze, then gold to silver. The first layer that diverges is the bug. Check timezone cutoffs, late-arriving rows, and filters on status. The 25-row gap is almost never 'rounding'.
How do you reconcile a CDC pipeline that misses deletes?: Periodic full-table counts and a set-difference on keys, not just the happy-path stream. Query-based CDC cannot see deletes; log-based can. If you cannot have the WAL, schedule a reconcile job that flags orphans and missing keys.
When is a tolerance acceptable in a reconciliation?: When the source itself is eventually consistent or timestamps do not align to the same second. Document the tolerance and the reason. An undocumented 0.5 percent fudge is how material finance errors hide.
How do you communicate a known data gap?: A status page or Slack in the same channel the dashboard users already watch, with the affected metric, the time window, and the ETA. Silence until the fix lands is how trust dies. Put the gap in the table (a _is_estimated flag) if it will persist.

Who owns a failed test at 2 a.m.?: The team that owns the model, named in meta.owner, paged by the orchestrator. A #data-quality channel that everyone watches and nobody owns is not an on-call rotation. Ownership is part of quality.
How do you roll out a new test without blocking the whole DAG?: Ship it as warn, watch the failure rate for a week, fix the data or the test, then flip to error. Introducing 30 failing tests on a Monday morning is how you train the company to ignore CI.
What is a quality SLO you have actually used?: Examples: 99 percent of gold models have unique and not_null on their key; freshness under 4 hours for executive dashboards; zero unresolved severity-error tests for more than one business day. SLOs without a number are wishes.
How do you stop quality work from becoming a graveyard of alerts?: Budget a weekly triage hour, expire alerts that have not been actionable in 30 days, and require an owner on every new check. Adding checks is easy; deleting them is the skill. Interviewers have all seen a 400-alert dashboard nobody looks at.

Is a pipeline with no tests better than one with 20 flaky tests?: The flaky one is worse if people ignore it. Zero tests is honest about the risk. Twenty ignored tests create false confidence. I would rather have five tests that page and get fixed.
A source sends a new enum value. Fail the pipeline or land it?: Land it in bronze as raw, fail or warn in silver if the enum is load-bearing, and never silently map it to Other in gold without a ticket. The answer depends on whether a missing row or a wrong classification is worse. Say which you chose and why.
How do you quality-check an LLM-enriched column?: You cannot unique-test a sentence. Use a labeled eval set, a critic prompt or a cheaper model, and spot checks on a sample each run. Store the model version and prompt hash so you can reproduce a bad batch. Treating LLM output like a source column with not_null only is cargo cult.
What quality question do you ask in a design review?: What is the grain, what happens on a rerun, and how would we know this is wrong before a user does. If those three have no answer, the design is not done. Schema and tool choice can wait.

From DataLane — tutorials at/blog, practice SQL live in theplayground.