SQL is the single most commonly tested skill in data analyst interviews, and unlike many technical skills, it barely changes from job to job — a SQL query written for a retail company and one written for a healthcare company use the same core syntax. This roadmap covers the skill in the order that maps to real job requirements, not the order most tutorials happen to teach it in.
Stage 1: Query Fundamentals (Weeks 1–2)
Everything else builds on this stage — don't rush it.
SELECT, WHERE, ORDER BY, LIMIT — filtering and sorting rows
Basic aggregate functions: COUNT, SUM, AVG, MIN, MAX
GROUP BY and HAVING — the difference between filtering rows and filtering groups trips up almost everyone at first; don't move on until this is genuinely comfortable
Recommended starting point: Introduction to SQL, which is free-tier-friendly and interactive.
Stage 2: Joins (Weeks 2–4)
Joins are where most interview screens actually separate candidates. Real business data lives across multiple tables, and combining them correctly is the daily reality of the job.
INNER JOIN — matching rows only
LEFT JOIN / RIGHT JOIN — keeping all rows from one side even without a match
Understanding NULL behavior after a LEFT JOIN — this is the single most common source of wrong-answer bugs in real analyst work
Self-joins — joining a table to itself, common in hierarchical or sequential data (e.g., comparing a customer's current and previous order)
Practice target: given two tables (customers, orders), answer "which customers have never placed an order" — this requires a LEFT JOIN and a NULL check, and it's a genuinely common real-world and interview question.
Stage 3: Subqueries and CTEs (Weeks 4–6)
This is where SQL moves from "filtering and combining" to "reasoning in steps."
Subqueries — a query nested inside another query's WHERE or FROM clause
Common Table Expressions (CTEs) — the WITH clause, which lets you name and reuse intermediate steps, making complex queries far more readable than deeply nested subqueries
When to use a CTE vs. a subquery — mostly a readability choice once you're comfortable with both
This is the stage that separates "knows SQL" from "is genuinely fluent in SQL," and it shows up constantly in intermediate-to-advanced interview questions.
ROW_NUMBER, RANK, DENSE_RANK — assigning order within groups without collapsing rows the way GROUP BY does
LAG and LEAD — comparing a row to the previous or next row, essential for period-over-period comparisons
Running totals and moving averages — using window functions with a frame clause
Practice target: calculate month-over-month revenue growth per product category — this single problem exercises ranking, LAG, and often a CTE together.
Stage 5: Query Optimization (Weeks 8–10)
Not every analyst role tests this deeply, but it matters increasingly as you work with larger tables, and it's a strong differentiator in interviews for more senior roles.
Reading an EXPLAIN plan — understanding what the database is actually doing to execute your query
Indexes — what they are, when they help, and why adding one isn't always free
Avoiding common performance mistakes — functions applied to indexed columns, unnecessary subqueries, SELECT * on wide tables
Stage 6: Practice at Interview Difficulty (Ongoing)
Once you're through stages 1–5, the remaining work is repetition against realistic problems, not new concepts. Rotate through practice platforms and real interview-style questions rather than continuing to consume new tutorial content — at this stage, fluency comes from doing, not watching.
For someone with no prior SQL experience studying 5–7 hours a week, expect roughly 8–10 weeks to reach genuine interview-ready fluency through window functions. Query optimization can be learned more gradually alongside real work, since it matters less for junior screening than the earlier stages do.
The One Mistake That Slows Everyone Down
Learning syntax without practicing on messy, realistic multi-table data. Tutorial exercises with one clean table teach the syntax but not the judgment — real practice means deliberately working with data that has duplicate rows, inconsistent NULLs, and tables that need three joins to answer one question.
Frequently Asked Questions
Do I need to learn all of this before applying for jobs?
No — stages 1–3 are enough to pass many entry-level screens. Window functions (stage 4) increasingly show up even at entry level, though, so don't skip it entirely.
Is SQL still relevant with all the AI coding tools available now?
Yes — SQL fluency lets you verify and correct what an AI tool generates, which matters more, not less, as more of the boilerplate gets automated. See our piece on whether AI will replace data analysts for the fuller argument.
Should I learn SQL or Python first?
SQL, for most people — see our SQL vs Python comparison for the full reasoning.
What's the best way to practice beyond a course?
Rotate between structured practice platforms and real interview question sets, and periodically try to answer a business question using a multi-table dataset without looking up syntax first — that friction is where real fluency gets tested.
Bottom Line
SQL rewards a specific, staged approach: fundamentals, joins, subqueries/CTEs, window functions, then optimization, with heavy practice on realistic multi-table data throughout. Most of the value sits in stages 1–4 — get those genuinely solid before worrying about advanced optimization, and you'll clear the large majority of analyst interview screens.
