How do you build data quality checks?

Direct answer

What a strong answer covers

How it works

Checks belong at every boundary where data changes hands: on ingestion to detect a source that changed shape or stopped sending, after each transformation to catch logic errors, and before a dataset is published to consumers. Each check tests one property with a threshold: schema matches, required columns have no nulls, keys are unique, foreign keys resolve, values sit within ranges or allowed sets, the latest partition is fresh, row counts stay within a band, and distributions have not shifted. Failing rows are quarantined rather than silently dropped, and each check has a severity that decides whether downstream jobs block and an owner who is paged.

Example

The customer pipeline runs Great Expectations suites: on landing, the file schema and a non-null email check; after transformation, uniqueness of customer_id and a country code lookup; before publication, freshness under 3 hours and a row count within 20 percent of the 7-day median. When a source started exporting a test tenant, the count check fired, the load was quarantined, and the dashboard showed yesterday’s data with a staleness banner instead of doubled customers.

Common mistakes

• Dropping invalid rows silently so totals shrink with no trace.
• Checking only at the end of the pipeline and debugging failures across ten jobs.
• Blocking every downstream job on a warning-level check and stalling the platform daily.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.