LeetCode SQL for Data Engineer Interviews

LeetCode's SQL problem set covers SELECT, WHERE, JOIN, GROUP BY, HAVING, and subqueries well. If you're starting from zero or rusty on fundamentals, LeetCode's easy and medium SQL problems are a good warmup. The platform runs real queries against real databases, so you get immediate feedback on correctness. For building basic SQL fluency, it works.

Each LeetCode problem has a discussion section where people share solutions, explain approaches, and debate edge cases. For SQL learners, reading multiple solutions to the same problem is valuable because SQL problems often have 3 to 4 valid approaches (CTE vs. subquery vs. window function vs. self-join). The community discussions surface these alternatives.

LeetCode problems have clear schema definitions, sample data, expected output, and test cases. This structured format is good for building confidence: you know exactly what the problem is asking and whether your solution is correct. For beginners, this clarity reduces frustration.

LeetCode has some window function problems, but the coverage is shallow compared to what DE interviews demand. You'll find basic ROW_NUMBER and RANK problems, but LEAD/LAG with complex conditions, running totals with resets, moving averages with date gaps, and NTILE for percentile calculations are rare or absent. In a real DE interview at Google, Amazon, or Uber, the window function problem alone can take 20 minutes and involve 3 to 4 nested window expressions. LeetCode doesn't build that muscle.

DE interviews are obsessed with time. Month-over-month comparisons, retention cohorts, 7-day rolling averages, gap-and-island problems, session detection based on time gaps between events. These patterns appear in the majority of DE SQL rounds. LeetCode's SQL problem set has limited time-series coverage. Most problems treat dates as simple filters (WHERE date > '2023-01-01') rather than as the core analytical dimension.

Real DE interview SQL problems are multi-step. You compute an intermediate result, use it to calculate something else, and then filter or aggregate the final output. These problems naturally require CTEs or nested subqueries with 3 to 5 steps. LeetCode's SQL problems are mostly solvable in a single query block or with one subquery. The complexity ceiling is lower than what interviews demand.

Most candidates think the interview ends when the query runs. The interviewer thinks it starts there. The real question is the one that follows: 'Fine, now this table is 5 billion rows. What breaks first?' You're expected to talk about partition pruning, join order, broadcast vs shuffle, whether to materialize an intermediate CTE, and which index would actually get used. LeetCode grades correctness and stops. Everyone who trained exclusively there freezes in the second half of the round, every single time.

DE interviews frequently include data modeling questions: design a schema for this use case, normalize or denormalize this table, explain the trade-offs between a star schema and a snowflake schema. LeetCode gives you the schema and asks you to query it. It never asks you to design one. This is a blind spot that catches candidates off guard because it's a completely different skill from query writing.

LeetCode SQL problems use generic schemas: Employee, Department, Sales, Products. DE interviews use domain-specific schemas tied to the company: Uber uses trips/drivers/riders, Amazon uses orders/shipments/inventory, Google uses ad impressions/search queries/video views. The domain context matters because it changes how you think about the data: what constitutes a meaningful metric, what edge cases exist, and how the data is typically queried. Generic schemas don't build this intuition.