DoorDash Data Engineer Interview Guide

Tables: orders(order_id, customer_id, trip_id, status, order_timestamp), trips(dasher_id, trip_id, estimated_delivery_timestamp, actual_delivery_timestamp), customers(customer_id, signup_timestamp). Join orders to trips and customers, filter to users who signed up in June 2022, restrict to orders within 14 days of signup, compute ratio of bad-status orders to total orders.

Schema: orders(order_id, customer_id, order_time, promised_delivery_time, actual_delivery_time). Task: select orders where actual_delivery_time > promised_delivery_time. Extended follow-up: compute the average late delivery time by restaurant or city, and percentage of late orders per day. Requires timestamp comparison, WHERE clause filtering, and potentially GROUP BY for follow-up analytics. From DoorDash Data Engineer interview on InterviewQuery.

Senior DE onsite at DoorDash, 2026. The data modeling round asked the candidate to design a fitness tracking app schema. Unusually, the interviewer also required the candidate to draw visualizations—specifically an advanced trend graph—not just a schema. The candidate noted: "Never in my past 8 years of work experience I had to do any visualizations but looks like DE in DoorDash work on visualizations as well." No specific schema constraints were provided upfront; the candidate was expected to define entities, facts, and metrics independently.

Senior DE onsite at DoorDash, 2025. The data modeling round presented the candidate with a complex, poorly-defined metric and asked them to design supporting tables. The candidate noted: "They gave me some weird metric that I needed to build tables for. It was difficult to even understand what the metric was. I was a bit lost on it." This tests the ability to clarify ambiguous requirements and translate a vague business metric into a fact/dimension schema.

Senior DE onsite at DoorDash, 2026. The system design question was to design a DataBricks-like platform. The interviewer specifically wanted YAML code written for each data source, testing infrastructure-as-code knowledge for data pipelines. The candidate wrote a pseudo-script and answered follow-up questions on each architectural component. The candidate struggled with the semantic layer component. The question contained 6–7 lines of requirements.

Senior DE onsite at DoorDash, 2025. The system design round asked the candidate to design a URL shortener. The candidate noted this is a classic SWE system design question and was unsure how to frame it from a DE perspective. A DE-angle approach would involve: key-value store design for short→long URL mapping, high-throughput write ingestion for new short links, read-optimised lookup, and analytics tables tracking redirect click events.

This tests schema evolution and operational engineering. Key steps: (1) ALTER TABLE to add nullable column with a default value — online DDL supported by most modern databases, no downtime, (2) batch backfill: UPDATE the column in small chunks (e.g. WHERE id BETWEEN x AND x+10000) with COMMIT between batches to avoid long-running transactions and locking, (3) add NOT NULL constraint after backfill is complete. Follow-ups: how to handle concurrent writes during backfill (use atomic CAS or make the column nullable first), rollback strategy, monitoring the backfill progress, using…

This tests database observability and debugging skills. Approaches: (1) enable query logging / slow query log in the database, filter by session or user identifier, (2) use network packet capture (e.g. tcpdump or Wireshark) on the database port to inspect SQL queries, (3) if using a proxy or connection pooler (PgBouncer, ProxySQL), inspect query logs there, (4) use database-native tools: pg_stat_activity (PostgreSQL), SHOW PROCESSLIST (MySQL), Query Store (SQL Server). Follow-ups: how to filter to a specific user, handling parameterized queries. From DoorDash DE interview testing data…