Most "SQL interview questions" lists give you a wall of queries and nothing else. You read them, nod, and still freeze the moment an interviewer asks you to talk through your logic live.
Below are 20 real examples, grouped by the pattern interviewers actually reuse — aggregation, joins, funnels, and window functions. For each group, you'll also see what a strong verbal answer sounds like, not just the query.
WhalePrep observation: Candidates who can write the correct query but can't narrate it clearly usually score lower than candidates with a simpler query and a clear explanation.
Aggregation & grouping questions
These test whether you can turn a vague business ask into a precise GROUP BY — and whether you clarify the definition before you write anything.
- Find the top 10 customers by total revenue over the last 12 months.
- Calculate month-over-month growth in daily active users.
- Find the average order value per customer segment.
- Identify the three best-selling products in each category.
- Calculate what percentage of users made a purchase within 7 days of signing up.
Saying it out loud: for question 5, a strong answer starts before any SQL: "I'm assuming 'purchase' means a completed order, not an added-to-cart event — and I'll measure the 7 days from account creation, not first login. With that grain defined, I'd join users to their first order, filter to a 7-day window, and divide by total signups."
JOIN-heavy questions
These check whether you understand why two tables relate, not just which keyword connects them.
- Find customers who have never placed an order.
- List all orders with the customer's name and email, including orders with missing customer records.
- Find employees who earn more than their direct manager.
- Identify duplicate customer records based on matching emails.
- Find products that were never included in any order.
Saying it out loud: for question 6, avoid jumping straight to LEFT JOIN. Instead: "I'd start from the customers table, since that defines who I'm looking for. Then I'd LEFT JOIN orders and filter to rows where the order side is null — that gives me customers with no matching order." That one sentence signals you understand the join direction, not just the syntax.
Funnel & conversion questions
Common at product- and growth-focused companies. The SQL gets complex fast — interviewers mainly want to see you break it into stages instead of one giant query.
- Calculate the conversion rate from page view to signup, broken down by traffic source.
- Find the drop-off rate between each step of a 4-step checkout funnel.
- Identify users who viewed a product page but didn't purchase within 24 hours.
- Calculate 30/60/90-day retention for users who signed up in a given month.
- Find the average time between signup and first purchase.
Why this works: narrating a funnel question stage by stage — "first I'll isolate everyone who viewed, then everyone who signed up, then join those two sets" — keeps the interviewer able to follow you even before you've written a single line.
Window functions & ranking questions
These come up constantly and rarely get covered in generic "SQL basics" prep — which is exactly why they're worth practicing out loud specifically.
- Find the second-highest salary in each department.
- Calculate a running total of daily revenue.
- Rank customers by total spend within each region.
- Find each customer's most recent order and how many days since their previous one.
- Calculate a 7-day moving average of daily signups.
Saying it out loud: for question 16, name the tool before you use it: "This is a ranking problem within groups, so I'd reach for a window function — RANK() partitioned by department, ordered by salary descending — then filter to rank 2." Naming the pattern first ("this is a ranking problem") is what makes you sound like you're reasoning, not guessing.
The part most prep skips
Knowing these 20 patterns gets you through the thinking half of a SQL interview. The half most candidates lose points on is different: explaining the query while you write it, in real time, in your second language, without losing your structure halfway through.
That's a separate skill from SQL itself, and it's worth practicing on its own. We wrote a full breakdown of how to do it — restating the question, defining the grain, narrating your plan before you type, and calling out edge cases out loud — in SQL in a data analyst interview: how to walk through your reasoning.
Practical target: pick 3 questions from the list above and explain your approach out loud, start to finish, before writing any SQL. Even alone, even if it feels awkward — that's the exact muscle a live interview tests.
