Every question on this page comes from a candidate's own account of a DoorDash interview, reported in 2025 or 2026. Aced members have written up seven DoorDash interviews that involved SQL, six for data scientist roles and one for a data engineer role. In November 2026 we also read more than 30 first-person reports posted since January 2025 on Glassdoor, Blind, 1point3acres, and LeetCode Discuss.
Each question says where the report came from and when. Table and column names are as the candidates remembered them. Where a candidate gave no schema, we say so and supply one. The sample data and the answers are ours, and every query was run in PostgreSQL.
How DoorDash's SQL rounds work
Data scientist: 30 minutes of SQL, then a case
The first technical round is an hour: 30 minutes of SQL and 30 minutes on a product case. An Aced member who interviewed in 2025 described that split, and another in December 2025 listed a 30-minute SQL screen and a separate 30-minute case screen. Six Glassdoor reviews posted between November 2025 and November 2026 describe 30 minutes of SQL alongside a case. Two candidates said a recruiter questionnaire came before it.
- Four questions in 30 minutes. Five Glassdoor reviews from August 2025 to August 2026 put the SQL part at four questions. One reviewer (July 2026) had almost no time for the last one and was told candidates are not expected to finish all four.
- The hard question is a window function. Three Glassdoor reviews from 2026 name
LAG, and one of them also namesRANK. One described the hardest of the four as a metric compared with its value the month before. - Some sessions run on HackerRank, and at least one did not run code at all. A November 2025 reviewer had no way to execute code and was graded on logic. A 1point3acres poster in June 2026 said the interviewer was lenient about typos and syntax.
- Expect little conversation. An August 2026 reviewer said the interviewer pasted a question, read the answer, and pasted the next one with little comment. An Aced member who interviewed in 2025 was told the interviewer cared about a correct answer, not narration.
- The format may be changing. A Glassdoor reviewer who interviewed in September 2026 said the SQL part no longer asks you to write the query; the query is given to you. A 1point3acres poster in November 2026 described a new-format round where the interviewer showed a schema, asked what they would look at, and showed the code only in the last four minutes. A commenter on that post described the same round. These are a few reports from late 2026, so ask your recruiter which format you will get.
Candidates named these case topics: food arriving cold (an Aced member in 2025, and a 1point3acres poster in June 2026), delivery by bike (two data scientist reports in 2026), and diagnosing a drop in orders in one city (June 2026).
Data engineer: four SQL questions and one Python question
The technical screen is live coding with four SQL questions and one Python question. Four Glassdoor reviews between January 2025 and June 2026 describe that count. A candidate who posted on both Glassdoor and LeetCode Discuss in September 2025 gave the SQL mix as two easy, one medium, and one hard.
- Check the dialect before you start. A January 2026 reviewer took the screen on HackerRank, graded by test cases, and found the SQL environment accepted only MySQL. Their PostgreSQL-syntax answer would not compile, and it cost them time.
- An unconfirmed assumption cost one candidate a question. An Aced member who interviewed in April 2026 had at least three SQL questions, with the interviewer running the code as it was written. A disagreement over one assumption on the third question led to a wrong answer.
- Three out of four may not be enough. The January 2026 reviewer solved three SQL questions and the Python question and was still rejected.
- Later rounds are modeling cases. Reviewers in 2025 and 2026 describe a data-modeling case for a fitness app, a dashboard case, and a question on handling late-arriving data.
Data scientist questions
1. Monthly share of high-frequency customers
Reported on 1point3acres: DoorDash data scientist SQL round on HackerRank, posted July 2026, login needed to read it.
Table delivery_order has order_dt, customer_id, restaurant_id, dasher_id, and delivery_id. Table sales has delivery_id and sales_amount. For each month, what share of customers are high-frequency, meaning they placed more than 30 orders?
WITH monthly AS (
SELECT
DATE_TRUNC('month', order_dt) AS order_month,
customer_id,
COUNT(*) AS orders
FROM delivery_order
GROUP BY 1, 2
)
SELECT
order_month,
SUM(CASE WHEN orders > 30 THEN 1 ELSE 0 END) * 1.0 / COUNT(*) AS high_frequency_share
FROM monthly
GROUP BY order_month
ORDER BY order_month;Count orders per customer per month first, then take the share of those customers over the threshold. The denominator is customers who ordered that month, which is the only population this table can give you.
Ask whether "more than 30 orders" is per month or over the customer's lifetime. This query reads it as per month. In MySQL, replace DATE_TRUNC('month', order_dt) with DATE_FORMAT(order_dt, '%Y-%m-01').
2. Top-spending customer each month, excluding high-frequency customers
Reported on 1point3acres: DoorDash data scientist SQL round, July 2026 (same post).
On the same tables, find the customer with the highest transaction in each month, leaving out the high-frequency customers.
WITH monthly AS (
SELECT
DATE_TRUNC('month', o.order_dt) AS order_month,
o.customer_id,
COUNT(*) AS orders,
SUM(s.sales_amount) AS spend
FROM delivery_order o
JOIN sales s ON s.delivery_id = o.delivery_id
GROUP BY 1, 2
),
ranked AS (
SELECT
order_month,
customer_id,
spend,
RANK() OVER (PARTITION BY order_month ORDER BY spend DESC) AS spend_rank
FROM monthly
WHERE orders <= 30
)
SELECT order_month, customer_id, spend
FROM ranked
WHERE spend_rank = 1
ORDER BY order_month;The exclusion has to happen before the ranking. If you rank first and filter after, a month whose top spender is high-frequency returns no row.
"Highest transaction" could mean the largest monthly total or the largest single order. This query uses the monthly total. For the single-order reading, replace SUM with MAX. RANK returns every customer tied for first; use ROW_NUMBER if the interviewer wants exactly one.
3. Month-over-month sales ratio for each restaurant
Reported on 1point3acres and Glassdoor: DoorDash data scientist SQL round, July 2026 (same post). A Glassdoor reviewer who interviewed the same month described the hardest of four questions as a metric relative to the previous month.
Compute the month-over-month ratio of sales for each restaurant.
WITH monthly AS (
SELECT
o.restaurant_id,
DATE_TRUNC('month', o.order_dt) AS order_month,
SUM(s.sales_amount) AS sales
FROM delivery_order o
JOIN sales s ON s.delivery_id = o.delivery_id
GROUP BY 1, 2
)
SELECT
restaurant_id,
order_month,
sales,
sales * 1.0 / LAG(sales) OVER (PARTITION BY restaurant_id ORDER BY order_month) AS mom_ratio
FROM monthly
ORDER BY restaurant_id, order_month;LAG reads the previous row in each restaurant's partition. The first month has no previous row, so its ratio is NULL, which is correct.
The previous row is not always the previous month. If a restaurant had no sales in February, March would be compared with January. Tell the interviewer, and offer to join against a calendar of months if they want gaps treated as zero.
The same post said one more question asked for take rate. The poster gave no detail.
4. Percentage of late orders
Reported on 1point3acres: DoorDash data scientist first round, posted April 2026, login needed. A second candidate in June 2026 said they got a late-order question in place of the usual restaurant set, and a commenter guessed it was this one. The first poster recalled an order table and a request table but not the columns, so the tables here are ours.
Assume orders (order_id, customer_id, ordered_at, delivered_at). What percentage of orders were late, where late means delivered more than X minutes after the order was placed? Use 45 minutes.
SELECT
100.0 * SUM(CASE WHEN delivered_at > ordered_at + INTERVAL '45 minutes' THEN 1 ELSE 0 END)
/ COUNT(*) AS pct_late
FROM orders
WHERE delivered_at IS NOT NULL;Ask how to treat orders that were never delivered. This query leaves them out of both the numerator and the denominator. Counting them as late, or as not late, changes the answer.
5. Orders with at least X requests, and average requests per order
Reported on 1point3acres: DoorDash data scientist first round, April 2026 (same post). The poster did not say what a request is. From the third question in the set, it reads like an offer sent to a Dasher, and that is how we modeled it.
Assume requests (request_id, order_id, dasher_id, requested_at). What percentage of orders received at least X requests, and what is the average number of requests per order? Use X = 2.
WITH per_order AS (
SELECT
o.order_id,
COUNT(r.request_id) AS requests
FROM orders o
LEFT JOIN requests r ON r.order_id = o.order_id
GROUP BY o.order_id
)
SELECT
100.0 * SUM(CASE WHEN requests >= 2 THEN 1 ELSE 0 END) / COUNT(*) AS pct_orders_2_plus,
AVG(requests) AS avg_requests_per_order
FROM per_order;Start from orders with a LEFT JOIN so that an order with no requests counts as zero. An inner join would drop it and push both numbers up. COUNT(r.request_id) counts only matched rows, which is why the zero comes out right.
The third question in the same set asked for the percentage of orders with at least one offer increase and the average percentage increase across all requests. It can be answered the same way, with one row per order first and then the two aggregates.
6. Share of orders that come from the top customers
Reported on Glassdoor: DoorDash data scientist technical interview, July 2025. The reviewer did not describe the tables.
Using delivery_order from above: what percentage of orders come from the top customers, and how often do those customers order?
WITH per_customer AS (
SELECT
customer_id,
COUNT(*) AS orders,
NTILE(10) OVER (ORDER BY COUNT(*) DESC) AS decile
FROM delivery_order
GROUP BY customer_id
)
SELECT
100.0 * SUM(CASE WHEN decile = 1 THEN orders ELSE 0 END) / SUM(orders) AS pct_orders_from_top,
AVG(CASE WHEN decile = 1 THEN orders END) AS avg_orders_per_top_customer
FROM per_customer;The reviewer's wording was "the % of top customers in orders". We read it as the share of orders that come from top customers.
This query defines "top customers" as the top 10% of customers by order count, which NTILE(10) labels as decile 1. A fixed cutoff such as the top 100 customers, or ranking by spend, would be just as reasonable.
A window function can sit in the same SELECT as a GROUP BY because it runs after the grouping.
Data engineer questions
Questions 7 to 10 are one candidate's complete set: four SQL questions in 30 minutes, after 20 minutes of Python. The candidate said all four were variations on well-known problems, and found the screen much harder than expected.
7. Employees by tenure bucket
Reported on 1point3acres: DoorDash data engineer phone screen, posted June 2025, login needed. The first of four SQL questions.
Table employees has employee_id and hire_date. Compute each employee's tenure today in whole years, rounded down. Put each employee in a bucket (0-2, 3-5, 6-10, or 10+ years) and return the number of employees in each bucket.
WITH tenure AS (
SELECT
employee_id,
EXTRACT(YEAR FROM AGE(CURRENT_DATE, hire_date)) AS years
FROM employees
)
SELECT
CASE
WHEN years <= 2 THEN '0-2'
WHEN years <= 5 THEN '3-5'
WHEN years <= 10 THEN '6-10'
ELSE '10+'
END AS tenure_bucket,
COUNT(*) AS employees
FROM tenure
GROUP BY 1
ORDER BY MIN(years);Subtracting the hire year from the current year overstates tenure for anyone whose anniversary has not come yet this year. AGE returns completed years, months, and days, so extracting the year gives the rounded-down figure. In MySQL, use TIMESTAMPDIFF(YEAR, hire_date, CURDATE()).
The bucket labels as reported overlap at 10 years. Point it out and state where you put the boundary; here, exactly 10 years goes in 6-10.
8. Top customers by spend in each segment
Reported on 1point3acres: DoorDash data engineer phone screen, June 2025 (same post).
Table orders has order_id, customer_id, amount, order_date, and status. Table customers has customer_id and customer_segment. Using only completed orders placed in June 2023, compute each customer's total spend, rank customers within their segment, and return the top 3 per segment.
WITH spend AS (
SELECT customer_id, SUM(amount) AS total_spent
FROM orders
WHERE status = 'completed'
AND order_date >= '2023-06-01'
AND order_date < '2023-07-01'
GROUP BY customer_id
),
ranked AS (
SELECT
c.customer_segment,
s.customer_id,
s.total_spent,
ROW_NUMBER() OVER (PARTITION BY c.customer_segment ORDER BY s.total_spent DESC) AS rn
FROM spend s
JOIN customers c ON c.customer_id = s.customer_id
)
SELECT customer_segment, customer_id, total_spent
FROM ranked
WHERE rn <= 3
ORDER BY customer_segment, total_spent DESC;Filter and aggregate before joining, so the ranking works on one row per customer. The half-open date range (on or after June 1, before July 1) keeps working if order_date turns out to be a timestamp.
The post says the question specified ROW_NUMBER, which returns exactly three rows per segment and breaks ties arbitrarily. If ties should all be kept, use RANK or DENSE_RANK.
9. Mobile-only users as a share of active users
Reported on 1point3acres: DoorDash data engineer phone screen, June 2025 (same post).
Table devices has user_id, device_id, is_active, and device_type. An active user has at least one device with is_active = 1. A mobile-only user is an active user whose active devices are all mobile. Return mobile-only users as a percentage of active users, rounded to two decimals.
WITH active_users AS (
SELECT
user_id,
SUM(CASE WHEN device_type <> 'mobile' THEN 1 ELSE 0 END) AS non_mobile_devices
FROM devices
WHERE is_active = 1
GROUP BY user_id
)
SELECT
ROUND(100.0 * SUM(CASE WHEN non_mobile_devices = 0 THEN 1 ELSE 0 END) / COUNT(*), 2) AS pct_mobile_only
FROM active_users;"All of their active devices are mobile" is easier to test as "none of their active devices is something else". Filtering to active devices first means an inactive desktop does not disqualify a user, which is what the definition says.
On our sample data two of four active users are mobile-only. User 1 qualifies because their desktop is inactive.
10. Runs of consecutive ordering days
Reported on 1point3acres: DoorDash data engineer phone screen, June 2025 (same post). The last of the four.
Table orders has id and order_date. For each id, find each run of consecutive days with an order, and return id, segment_start, and segment_end.
WITH days AS (
SELECT DISTINCT id, order_date
FROM orders
),
grouped AS (
SELECT
id,
order_date,
order_date - CAST(ROW_NUMBER() OVER (PARTITION BY id ORDER BY order_date) AS INT) AS run_key
FROM days
)
SELECT
id,
MIN(order_date) AS segment_start,
MAX(order_date) AS segment_end
FROM grouped
GROUP BY id, run_key
ORDER BY id, segment_start;This is the gaps-and-islands pattern. Within a run of consecutive days, the date and the row number both go up by one, so the date minus the row number stays constant. That constant identifies the run.
Remove duplicate days first. Two orders on the same day would otherwise get two row numbers and split one run into two.
11. Dashers who had late deliveries
Reported on Glassdoor: DoorDash data engineer technical interview, posted June 2025: four SQL problems in 30 minutes, with the harder ones needing window functions. The reviewer did not describe the tables.
Assume deliveries (delivery_id, dasher_id, picked_up_at, promised_at, delivered_at). Find the Dashers who had late deliveries.
SELECT
dasher_id,
COUNT(*) AS late_deliveries
FROM deliveries
WHERE delivered_at > promised_at
GROUP BY dasher_id
ORDER BY late_deliveries DESC;Ask whether "late" means later than the time promised to the customer, or longer than some number of minutes after pickup. The query also returns each Dasher's count of late deliveries.
Data analyst question
12. Dasher performance by location
Reported on Glassdoor: DoorDash data analyst technical round, posted January 2025. The reviewer was given three tables and did not list them.
Assume dashers (dasher_id, name, location_id), locations (location_id, city), and deliveries as above. Write a query that shows Dasher performance by location, then explain what the result tells you.
SELECT
l.city,
COUNT(DISTINCT d.dasher_id) AS dashers,
COUNT(*) AS deliveries,
ROUND(AVG(EXTRACT(EPOCH FROM (dl.delivered_at - dl.picked_up_at)) / 60), 1) AS avg_minutes,
ROUND(100.0 * SUM(CASE WHEN dl.delivered_at <= dl.promised_at THEN 1 ELSE 0 END) / COUNT(*), 1) AS pct_on_time
FROM deliveries dl
JOIN dashers d ON d.dasher_id = dl.dasher_id
JOIN locations l ON l.location_id = d.location_id
GROUP BY l.city
ORDER BY pct_on_time;The query measures performance as speed and reliability. It reports average delivery minutes and the on-time rate for each city, with delivery volume next to them so that a city with five deliveries is not read the same way as one with five thousand.
For the second half of the question, say which city is slowest, whether volume explains it, and what you would check next.
What to practice
- Window functions. Practice
LAGfor month-over-month,RANKandROW_NUMBERfor top N per group, and gaps and islands. The window functions lesson covers all three. - Monthly rollups. Half of the data scientist questions above start by grouping to one row per customer or restaurant per month. See dates and bucketing.
- Timed sets. Time yourself on four questions in 30 minutes, in the order easy, easy, medium, hard. A July 2026 reviewer was told candidates are not expected to finish all four.
- MySQL syntax. If you normally write PostgreSQL, know the MySQL versions of date truncation and date differences before a HackerRank screen.
Our SQL interview questions and answers post covers questions reported at other companies. You can practice in a live editor in the SQL question bank and the SQL interview course.
Frequently asked questions
How many SQL questions are in a DoorDash interview?
Candidates most often report four in 30 minutes for data scientists, and four plus one Python question for data engineers. Three reports give three SQL questions (an Aced member in April 2026 who had at least three, a Glassdoor reviewer in May 2025, and a Blind commenter in June 2026).
Which SQL dialect does DoorDash use?
One data engineer candidate in January 2026 reported a HackerRank environment that accepted only MySQL. Other reports do not name a dialect, and at least one data scientist session did not run code at all. Ask the recruiter, and be ready to write date functions in MySQL.
How hard is the DoorDash SQL round?
Data scientist candidates mostly describe easy to medium questions with one harder window-function question, and an Aced member who interviewed for that role in April 2026 said the same. Data engineer candidates describe a harder set of two easy questions, one medium, and one hard. Five reports mention running short of time. Four questions in 30 minutes leaves about seven minutes each.
Is DoorDash changing its SQL interview?
Two candidates in late 2026 described a data scientist round where the query was supplied or the discussion came before any code. Most 2026 reports still describe writing four queries.
Learn everything you need to ace your data science interviews.
Aced is the fastest-growing tech interview prep platform. Get free interview guides, insider tips, and courses.
Create your free accountRelated Courses
Data Science Interview Prep Course
Python Coding Questions for Data Scientists
Related Blog Posts
14 Meta SQL Interview Questions From 2025 and 2026 Candidates
Data Science Interview Prep (2026 Guide)
Top AI/ML Companies Hiring Now
