Restaurant partners are seeing ~12% inflated revenue in our partner-ping job. The job builds daily_restaurant_revenue from the orders + dropoffs tables. Run tests/test_no_double_count.py to reproduce: rows where one order has multiple dropoffs (multi-stop deliveries) get counted once per dropoff. Fix the SQL in queries/daily_restaurant_revenue.sql so revenue is per order, not per (order, dropoff).
queries/daily_restaurant_revenue.sql
/* queries/daily_restaurant_revenue.sql */ /* Daily revenue per restaurant. Joined to dropoffs so we can attribute to delivery zone for the partner ping job. */ with joined as ( select o.restaurant_id, o.order_id, o.amount_cents, o.order_date, d.zone_id from orders o join dropoffs d on d.order_id = o.order_id ) select restaurant_id, order_date, sum(amount_cents) as revenue_cents, count(*) as order_count from joined group by restaurant_id, order_date
Active Now|Data Engineer (L4)|||3.6k Attempts|1.0k Solves|
SQL Debugging Exercise: Counted Twice
An AI-assisted SQL coding round for data engineers at mid-level level. Work in a real IDE with an AI agent, then defend your changes to an interviewer.
- Stack
- SQL
- Format
- Debugging Exercise
- Seniority
- Mid-Level
- Estimated time
- 30 minutes
- Files in the repo
- 3
The Task
Restaurant partners are seeing ~12% inflated revenue in our partner-ping job. The job builds daily_restaurant_revenue from the orders + dropoffs tables. Run tests/test_no_double_count.py to reproduce: rows where one order has multiple dropoffs (multi-stop deliveries) get counted once per dropoff. Fix the SQL in queries/daily_restaurant_revenue.sql so revenue is per order, not per (order, dropoff).
Summary
Twice the revenue, half the truth.
Repository Files
- queries/daily_restaurant_revenue.sql (sql)
- etl/run.py (python)
- tests/test_no_double_count.py (python)