← DoorDash Interview Insights

DoorDash·Data Scientist·Technical Phone Screen·Intermediate

Intermediate
Jun 2026

Summary

SQL-heavy technical screen for a DS role at DoorDash. Three questions all built on the same orders/delivery_requests schema, each one layering more complexity than the last. The kind of round where you think you're done and then they add a follow-up column to the output spec.

Questions Asked (3)

Q1

Given a parameterized time window and a late_threshold_minutes parameter, write SQL to find what percentage of completed orders were delivered late, where late means delivery time exceeded the threshold past order creation.

Product Analytics & MetricsData Modeling
Author's notes

Pretty approachable as a warmup.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify the schema and definitions (e.g., completed orders, delivery time, order creation time, parameterization). Then write a SQL query that computes the percentage of completed orders where delivery time exceeds order creation time plus the late threshold, using a subquery or CTE to isolate late orders and aggregate.

Pro tip: Always confirm whether 'completed orders' means delivered orders only, and whether the time window applies to order creation or delivery time. Also, handle edge cases like null delivery times or orders not yet delivered.

1. Clarify requirements and schema

Ask about table structure, column names, definitions of 'completed', 'delivered late', and how the time window and threshold are parameterized. Confirm if the window filters order creation or delivery time.

2. Define late condition

Late means delivery_time > order_creation_time + INTERVAL 'late_threshold_minutes minutes'. Use appropriate date/time functions based on the SQL dialect.

3. Filter completed orders in time window

Select orders that are completed (e.g., status = 'completed' or 'delivered') and whose order creation (or delivery) falls within the parameterized time window.

4. Compute percentage

Calculate the ratio of late orders to total completed orders, multiplied by 100. Use conditional aggregation or a subquery with COUNT and division.

5. Write and validate SQL

Write the final SQL query, ensuring correct handling of NULLs, division by zero, and parameter substitution. Optionally, test with sample data.

Key Points to Mention

  • Parameterization: use placeholders for time window start/end and late_threshold_minutes.
  • Definition of 'completed orders': likely delivered orders, but confirm.
  • Time window application: whether it filters order creation or delivery time.
  • Late condition: delivery_time > order_creation_time + threshold.
  • Percentage calculation: (late_count / total_count) * 100, with NULLIF to avoid division by zero.
  • SQL dialect considerations: date/time functions and interval syntax.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

Write SQL to calculate what percentage of completed orders had at least request_threshold delivery requests, and also return the average number of requests per completed order. Orders with zero delivery requests must still appear in the denominator.

Product Analytics & MetricsData Modeling
Author's notes

The zero-request inclusion is the part that gets you.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the grain of the data and the definition of 'completed orders' and 'delivery requests'. Then write a query that aggregates requests per order, ensuring orders with zero requests are included via a LEFT JOIN or COALESCE, and finally compute the percentage and average using conditional aggregation.

Pro tip: Explicitly state your assumptions about the data model (e.g., orders table and delivery_requests table) and how you handle NULLs or missing requests. This shows you think about data quality and edge cases, which is crucial for a data scientist role.

1. Clarify requirements and data model

Ask clarifying questions about the definition of 'completed orders', 'delivery requests', and 'request_threshold'. Confirm the tables involved and their relationships.

2. Aggregate requests per order

Use a LEFT JOIN from orders to delivery_requests and GROUP BY order_id to count requests per order. Ensure orders with zero requests are included by using COALESCE or COUNT on the joined table.

3. Compute percentage and average

In an outer query, calculate the percentage of orders with requests >= threshold using conditional aggregation (e.g., SUM(CASE WHEN ...) / COUNT(*)), and compute the average requests per order using AVG(request_count).

4. Handle edge cases and validate

Consider orders with no requests, NULLs, and potential duplicates. Validate the query logic with a small sample or mental test.

Key Points to Mention

  • Use of LEFT JOIN to include orders with zero delivery requests in the denominator.
  • Conditional aggregation (CASE WHEN) to count orders meeting the threshold.
  • Calculation of percentage as a ratio of counts, ensuring it's expressed as a percentage (multiply by 100).
  • Average requests per order computed as AVG(request_count) over all completed orders.
  • Handling of NULLs and ensuring no orders are dropped due to missing requests.
  • Assumptions about the data model and definitions of 'completed' and 'delivery requests'.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

For completed orders, calculate the percentage that had at least one offer increase across sequential delivery requests, and compute the average percentage increase across all positive increase events. An offer increase is when a request's offer amount is higher than the immediately preceding request for the same order, ordered by time then request_id.

Product Analytics & MetricsAlgorithms & Data StructuresData Modeling
Author's notes

This one took me a minute.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the definitions and edge cases (e.g., completed orders, offer increase, sequential requests) to ensure alignment. Then, outline a step-by-step SQL or Python approach: filter completed orders, order requests by time and request_id, compute lagged offer amounts, identify increases, and aggregate metrics. Finally, discuss how to handle ties, missing data, and validation.

Pro tip: Mention that you would validate the results by manually checking a few orders and considering the impact of outliers on the average percentage increase, possibly using median or trimmed mean as a robustness check.

1. Clarify Definitions and Edge Cases

Confirm what 'completed orders' means (e.g., status = 'completed'), define 'offer increase' precisely, and discuss how to handle ties in timestamps or missing offer amounts.

2. Prepare and Order Data

Filter to completed orders, then for each order, sort requests by time and request_id to establish the sequential order.

3. Identify Offer Increases

Use window functions (e.g., LAG) to compare each request's offer amount to the immediately preceding request; flag rows where the current offer is higher.

4. Calculate Metrics

Compute the percentage of completed orders with at least one increase, and the average percentage increase across all positive increase events (e.g., (current - previous)/previous * 100).

5. Validate and Interpret

Check for anomalies, consider the distribution of percentage increases, and discuss potential business implications or next steps.

Key Points to Mention

  • Use of window functions (LAG) to compare sequential requests
  • Handling ties in timestamps by using request_id as a tiebreaker
  • Definition of 'completed orders' and filtering criteria
  • Calculation of percentage increase: (current_offer - previous_offer) / previous_offer * 100
  • Aggregation: COUNT(DISTINCT order_id) for orders with at least one increase, and AVG for average percentage increase
  • Edge cases: orders with only one request, zero or negative previous offers, and missing data

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.