You can spend a year reading SQL tutorials and still freeze the first time someone slides an interview laptop in front of you. The reason isn't talent. It's that SQL is a layered skill — and most learning paths jumble the layers together until you can't tell what you actually know from what you've just seen once. A checklist fixes that. Walk down it honestly. Mark what you can do cold, what you can do with a reference open, and what still looks like wizardry. You'll know exactly where to spend the next two weeks.

This guide lays out a SQL skills checklist by level — beginner, intermediate, advanced — and then points you at the practice sites that train each layer best.

We'll cover the core syntax everyone needs (SELECT, WHERE, ORDER BY, JOINs, GROUP BY), the intermediate moves that separate juniors from mids (CTEs, window functions, CASE WHEN logic), and the advanced territory that shows up in senior interviews (recursive CTEs, indexes, query plans, isolation levels). We'll also map which keywords and patterns to memorize for a SQL coding test, where to find the best cheat sheets, and how to translate "data analyst skills math statistics persuasion sql" job descriptions into a study plan that actually fits your timeline.

One framing note before we start. SQL skills aren't binary. You don't "know JOINs" — you know inner joins comfortably, you can do left joins with one foot dragging, and you've never written a self-join under pressure. The checklist below uses three tiers — confident, working, unfamiliar — so you can rate yourself honestly. Take a notebook. Score each item. Whatever lands in "unfamiliar" becomes your study queue for the next sprint.

Start at the beginner tier. This is the layer most self-taught learners skim over because it feels obvious — and then they discover during a coding test that they can't write a clean GROUP BY without a syntax error. Boring fundamentals win interviews. Spend a week here even if you think you're past it. The payoff is automatic syntax recall under pressure, which frees your working memory for the harder parts of the question.

Beginner SQL covers single-table querying and basic multi-table work. You should be able to SELECT specific columns, filter rows with WHERE using comparison operators and IN/BETWEEN/LIKE, sort with ORDER BY ascending and descending, and limit results with LIMIT or TOP depending on the dialect. Aggregate functions — COUNT, SUM, AVG, MIN, MAX — come paired with GROUP BY and HAVING for filtering after aggregation. Most beginner SQL questions on coding tests live entirely inside this layer. Master it and you'll handle maybe 40% of any interview's question bank without breaking a sweat.

The other half of the beginner tier is INNER JOIN and LEFT JOIN. Forget RIGHT JOIN for now — almost nobody uses it in practice, and you can always rewrite it as a LEFT JOIN with the tables flipped. What you need cold is the ON syntax, how to choose join keys, how to handle nullable columns in the right table, and the classic gotcha of WHERE clauses on left-joined tables nullifying the outer join behavior.

That last one trips up roughly one in three candidates in technical screens. If you can explain why WHERE b.col IS NULL behaves differently from putting the same condition in the ON clause, you're past the beginner threshold.

Intermediate SQL is where the layering really starts. This tier is what mid-level data analysts and backend developers use every day, and it's where most coding tests for analyst and engineer roles concentrate their hardest questions. Subqueries come first. Correlated and non-correlated. You should be able to use a subquery in the SELECT clause, in the FROM clause as a derived table, and in the WHERE clause with IN, EXISTS, or comparison operators. The EXISTS pattern in particular shows up constantly — and writing it correctly with proper correlation is a marker that you've moved past beginner.

Then come CTEs. WITH name AS (...) — the syntax that makes long queries actually readable. CTEs are functionally similar to subqueries but they shine when you need to reference the same derived dataset more than once, or when the query logic has three or four logical steps that would be impossible to follow inline.

Practice writing a CTE that builds a daily aggregation, then a second CTE that ranks rows within each day, then a final SELECT that filters the ranked output. That's the canonical three-CTE pattern that shows up in interview questions like "find the top customer by revenue each month."

Window functions are the next big layer. ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, SUM OVER, and the PARTITION BY / ORDER BY syntax. These are the single most-tested concept in modern SQL interviews, especially for data analyst and data engineer roles. You should be able to explain the difference between ROW_NUMBER and RANK without looking it up — ROW_NUMBER assigns unique sequential integers, RANK assigns the same integer to ties and skips the next value, DENSE_RANK assigns the same integer to ties but doesn't skip. Memorize that and the typical "find the second highest salary" question becomes a 30-second answer.

CASE WHEN is the third intermediate skill that separates juniors from mids. You'll use it constantly to bucket continuous values into categories, to handle missing data with sensible defaults, and to build pivot-style aggregations when you don't have access to the PIVOT keyword. The pattern SUM(CASE WHEN condition THEN value ELSE 0 END) is so common in production analytics queries that you should write it from memory in under ten seconds. If it takes longer, drill it.

UNION and UNION ALL round out the intermediate tier. The distinction here trips people up — UNION deduplicates, UNION ALL doesn't. UNION ALL is almost always what you want for performance reasons unless you have a specific need to remove duplicates. Knowing which to reach for, and why, signals that you've thought about how SQL actually executes. Add column-list alignment, NULL handling across the unioned sets, and ordering of the final combined output, and you have the full UNION skill in your kit.

Now — advanced SQL. This is the tier where you stop being a SQL user and start being someone who actually understands how the database thinks. Recursive CTEs come first. The pattern WITH RECURSIVE cte AS (anchor query UNION ALL recursive query referencing cte) lets you traverse hierarchical data, build sequences, walk graphs, and solve problems that would otherwise require procedural logic. Org charts, category trees, dependency graphs, gap-and-island analysis — all recursive CTE territory.

Indexes are the next advanced skill. You need to understand what a B-tree index actually does, when adding one helps a query and when it hurts insert performance, what a covering index is, and why composite indexes are order-sensitive. The classic interview question — "this query is slow, what would you check?" — usually has "the right index isn't being used" somewhere in the answer. Run EXPLAIN on a query without an index, add the index, run EXPLAIN again, and watch the plan change. That hands-on exercise teaches you more about indexes than any tutorial.

Query execution plans are the second advanced pillar. Every major database has its own way of showing the plan — PostgreSQL has EXPLAIN ANALYZE, SQL Server has the graphical Execution Plan, MySQL has EXPLAIN with its own format. Learning to read one teaches you to read all of them. Look for sequential scans on large tables (bad), missing index usage (often bad), nested loop joins on huge inputs (sometimes bad), and hash joins or merge joins where appropriate. Knowing when a plan is reasonable and when it's pathological is what separates a senior SQL practitioner from a strong intermediate.

Partitioning is the next layer up. Table partitioning by date range, by hash, or by list — when does it help and when is it a maintenance nightmare? Most analysts don't need to design partitioned tables, but understanding the concept matters for working with them in data warehouses like BigQuery or Snowflake, where partition pruning can make a query 50x faster or 50x slower depending on whether your WHERE clause hits the partition key. Read your platform's partitioning docs once. Bookmark them.

Transaction isolation levels round out the advanced tier — and they're the topic most candidates skip entirely. The four standard levels are READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE. Each protects against a different concurrency anomaly: dirty reads, non-repeatable reads, phantom reads. PostgreSQL's default is READ COMMITTED. SQL Server's default is also READ COMMITTED. MySQL's InnoDB defaults to REPEATABLE READ. Knowing the defaults and the trade-offs comes up in senior interviews and in real production work whenever two transactions touch the same row.

Deadlock detection and resolution is a related advanced skill. A deadlock happens when two transactions hold locks that the other one wants. The database resolves it by killing one transaction — usually whichever did less work. Understanding lock ordering, how to read a deadlock graph, and how to redesign queries to avoid the problem entirely is the kind of knowledge that gets you hired as a senior database engineer rather than as a SQL analyst. Most analyst-track interviews won't probe this far, but knowing it impresses everyone in the room.

Now — cheat sheets. Every SQL learner eventually builds or downloads one, and most of the public ones are terrible. The ones worth keeping are the ones that show syntax patterns rather than vocabulary lists. "SUM, AVG, COUNT" is not a cheat sheet — that's a glossary.

A real cheat sheet shows you the full skeleton of a window function call with PARTITION BY and ORDER BY and an OVER() frame clause, with three example use cases below. The PostgreSQL official documentation has the best SQL window function reference in existence. Print the relevant pages. Keep them next to your laptop.

A word on the job description gauntlet — "data analyst skills math statistics persuasion sql" and its variants. When recruiters list four or five skills like that, SQL is almost always the gating filter. They'll happily train you on the business communication side if your SQL is sharp. They won't hire you for the SQL role if your queries don't run.

So if you're allocating prep time across that skill bundle, give SQL twice as much weight as anything else in the list. Statistics matters too — but most analyst roles only need descriptive statistics and basic hypothesis testing concepts, which take a long weekend to refresh. SQL takes months to build properly.

Practice site strategy matters more than people realize. Don't bounce between four platforms. Pick one. Work through fifty problems systematically. Then switch when the marginal learning per problem drops off. HackerRank is the right starter for most learners because it has the cleanest difficulty ramp. LeetCode SQL is the right next stop because its medium and hard problems closely resemble what shows up in FAANG-style interviews. StrataScratch is the right finisher because its problems are pulled from actual interview question banks at real companies — and many include the original company name as context.

For ongoing practice once you've cleared the beginner and intermediate tiers, switch tactics. Stop drilling on artificial questions and start writing queries against real data.

Find a free dataset on Kaggle, load it into PostgreSQL locally, and force yourself to answer real business questions about it. "What was the day-over-day revenue change for the top five products in the last 90 days, ranked by retention rate?" That kind of question forces you to integrate window functions, CTEs, and JOINs in ways no canned exercise can replicate. The transition from solving problems to designing them is where intermediate SQL becomes advanced SQL.

One last skill that doesn't fit neatly in any tier — dialect fluency. SQL is a standard, but every database vendor has its own quirks. PostgreSQL has rich window function support and array types. MySQL has a slightly different LIMIT syntax and weaker recursive CTE support depending on the version. SQL Server uses TOP instead of LIMIT and has TRY_CAST instead of NULL-returning casts. BigQuery has standard SQL plus its own data type extensions. Snowflake leans on the standard but adds variant types for semi-structured data.

Pick one dialect to be fluent in. For most analyst roles that's PostgreSQL or SQL Server. For data engineer roles in modern stacks it's increasingly Snowflake or BigQuery. Once you're fluent in one, learning a second takes a long weekend — you just read the dialect differences page and write a few queries to feel out the edge cases. Don't try to learn three dialects simultaneously. You'll end up with shallow knowledge of all three and deep knowledge of none.

The advanced interview question banks live mostly on the data engineer and data analyst tracks. "Advanced SQL interview questions for data analyst" pulls up question sets that focus on window functions, CTEs, and complex aggregations. "Advanced SQL interview questions for data engineer" pulls up sets that lean harder into performance, indexing, and pipeline-style queries. "Advanced SQL interview questions for experienced professionals" usually means senior-level questions covering query plans, isolation, and architectural trade-offs. Tailor your prep to the actual role you're targeting. A senior data engineer interview will probe parts of SQL that an analyst interview never touches, and vice versa.

Building the skills checklist into a real study plan is the part most people skip. Don't. Take the checklist above, rate yourself honestly on every item, and turn the "unfamiliar" entries into a queue. Spend one hour per day on the easiest "unfamiliar" item until it becomes "working," then move to the next. Once everything is at least "working," cycle back to the top and push everything to "confident." That's two passes through the list — maybe six weeks of consistent daily practice — and it covers the entire SQL skill space for analyst and engineer roles.

If a SQL coding test is on your calendar in the next month, change the strategy. Don't try to push all your unfamiliar items to confident in time. Instead, prioritize the items most likely to appear. Window functions are tested in roughly 70% of analyst coding tests. CTEs in 60%. Subqueries in 80%. JOIN gotchas in nearly all of them.

Recursive CTEs in maybe 15%. Isolation levels essentially never on a coding test, though they come up in oral interviews afterward. Spend your prep on the high-probability items and accept that you might see one question you can't fully solve. That's fine. Brute-force the rest and submit clean code.

Final thought — the SQL skills market rewards depth over breadth. A candidate who's confident in 80% of the intermediate tier and competent in two-thirds of the advanced tier will outperform one who's seen every advanced feature once but can't write a clean window function under pressure. Drill the basics until they're automatic. Drill the intermediate layer until you can structure a three-CTE query in your sleep. Sample the advanced layer until you understand what each concept does and why it matters. That mix wins interviews and lets you ship real production queries on day one of any new job.