How do you debug a data quality issue in a complex pipeline?

WHAT THIS TESTS: This question evaluates your ability to apply a systematic, multi-stage debugging process to a complex data system. Interviewers are looking for more than just technical debugging; they want to see your understanding of business impact, communication, and proactive system improvement. It separates candidates who just fix code from senior engineers who improve systems. It tests your grasp of data lineage, observability, and the trade-offs between immediate fixes and long-term health.

A GOOD ANSWER COVERS: A strong answer has three parts. First, immediate triage: communicate the issue to stakeholders, quantify the blast radius (e.g., which reports are affected, for what time period), and consider disabling the report or posting a data quality warning. Second, systematic root cause analysis, working backwards from the point of observation: analyze the report's query, then the data in the data mart, then the output of the final Spark stage, then intermediate data sets within Spark, and finally the raw data ingested from the source microservices. Third, a forward-looking proposal for tooling: describe specific tools you wish you had, such as column-level data lineage graphs, automated data quality contract tests (e.g., using Great Expectations or dbt tests) at each transformation step, and centralized, structured logs for the entire pipeline.

COMMON WRONG ANSWERS: A common mistake is jumping to a conclusion, like immediately saying "I'd check the Spark job for a bug." This lacks a systematic approach. Another red flag is focusing only on code and ignoring the data itself; the problem could be upstream data corruption, not a processing error. Inexperienced candidates often forget the first step: containment and communication. A senior engineer must address the business impact first. Finally, vague answers about tooling like "we need better monitoring" are weak. Be specific: "I'd want a tool that automatically checks for nulls in primary key columns and alerts if row counts drop by more than 10% day-over-day."

LIKELY FOLLOW-UPS: Expect questions about the recovery process. For example: "Once you find and fix the bug, how do you correct the historical data in the financial report?" This probes your understanding of pipeline replayability, idempotency, and backfilling strategies. Another likely follow-up is: "How would you justify the engineering cost of building this new data lineage tooling to a product manager?" Be ready to frame the ROI in business terms, such as "We spent 80 engineer-hours debugging data issues last quarter. This tool would cost 120 hours to build but could reduce debugging time by 75%, saving us money within two quarters."

ONE CONCRETE EXAMPLE: Imagine a 'Total Revenue' metric is unexpectedly down 15%. Working backwards: the report's SUM query is correct. The final fact_transactions table in the data mart shows missing transactions. The Spark job output that writes to this table is also missing them. You trace it to an intermediate stage that joins orders with payments. You discover a recent change switched an OUTER JOIN to an INNER JOIN, incorrectly dropping orders that had a temporary payment failure before a successful retry. The fix is reverting the join logic. The proactive tooling would have been a data quality check asserting that COUNT(transactions) in the output is not less than 0.98 * COUNT(orders) from the input, which would have failed the pipeline and prevented the bad data from ever reaching the data mart.