Design a Data Quality Monitoring & Alerting System

WHAT THIS TESTS: This question assesses your ability to think systematically about data reliability. The interviewer wants to see if you can move beyond simple 'it failed' alerts and design a system that proactively identifies issues, quantifies their severity, and routes alerts appropriately. They are testing your operational maturity and understanding that data is a product whose trustworthiness is paramount, especially for executive-level consumers.

A GOOD ANSWER COVERS: A strong answer covers four key areas in order. First, start with the business context: the goal is to ensure executive dashboards are trustworthy, so checks must prevent bad data from reaching them. Second, detail the specific checks, categorizing them: Freshness (e.g., data is no more than 60 minutes old), Volume (e.g., row count is within +/- 10% of the 7-day moving average), Schema (e.g., no columns dropped, data types are correct), and Distribution/Validity (e.g., a country_code column contains >99.5% valid ISO codes, null percentage for user_id is <0.1%). Third, describe the monitoring implementation: checks should run as a blocking step in the pipeline itself, after loading but before the data is promoted to production. Fourth, explain the alerting strategy: differentiate between critical alerts that page an on-call engineer (e.g., freshness failure, >20% volume drop) and warnings that post to a team Slack channel (e.g., a new value in an enum field).

COMMON WRONG ANSWERS: A common red flag is focusing exclusively on one type of check, like null counts, while ignoring others like freshness or distribution. Another is suggesting a purely manual review process, which doesn't scale. The biggest mistake is jumping straight to naming a specific tool (like dbt tests, Great Expectations, or Deequ) without first explaining the principles. The tool is an implementation detail; the strategy is what matters. A vague answer like 'I'd check for bad data' is a sign of inexperience.

LIKELY FOLLOW-UPS: 'How would you handle a gradual data drift vs. a sudden spike?' 'How would you backfill corrections if a quality issue is found?' 'At what scale would you move from in-pipeline checks to a separate, dedicated data quality service?' 'How do you decide the thresholds for these alerts, like the 10% volume change?'

ONE CONCRETE EXAMPLE: For a daily user activity table, I'd set a freshness check to fail if the max event_timestamp is not from today. I'd set a volume check to warn if the row count deviates by more than 15% from the same day last week, and to page if it deviates by more than 40%. For distribution, I'd ensure the user_id column has fewer than 0.5% nulls. A schema check would fail the pipeline if a column is dropped or its data type changes. These checks would run after the ETL job finishes and before the table is made available to dashboarding tools.