SQL Practice Exercises: A Step-by-Step Plan From SELECT to Window Functions 2026

SQL practice exercises are hands-on query problems that make you write SELECT, JOIN, GROUP BY, window function, and DDL statements against a sample database, then check the results. The best routine is 20 to 30 minutes a day, moving from single-table filters to joins, aggregates, CTEs, and window functions over roughly eight weeks.

SQL Practice Exercises: Key Facts (Updated October 2026)

Learning SQL is less about memorizing syntax and more about building pattern recognition. Each exercise trains you to read a business question, identify the tables involved, and translate the request into a declarative query. Reading tutorials produces familiarity, but only writing queries, seeing wrong row counts, and debugging them produces fluency. That is why practice exercises, not passive lectures, are the fastest route to passing a technical screen or handling real reporting work.

A good exercise has three parts: a realistic schema, a clear question, and a way to verify the answer. For example, given customers and orders tables, you might be asked to list every customer who spent more than 500 dollars in March. You write the query, compare your output with the expected rows, and then study any difference. That feedback loop is where nearly all the learning happens.

Beginners often ask whether they need a database installed before starting. You do not. Browser-based sandboxes let you run queries instantly, which removes setup friction during your first week. Once you feel comfortable, install PostgreSQL or SQLite locally so you can practice creating tables, loading CSV files, and experimenting with your own data. Local practice also teaches you error messages, which are a surprisingly large part of real-world SQL work.

Difficulty should rise in small, deliberate steps. Start with SELECT, WHERE, ORDER BY, and LIMIT on a single table. Then add INNER and LEFT joins, followed by GROUP BY with HAVING, subqueries, common table expressions, and finally window functions such as ROW_NUMBER, RANK, and LAG. Jumping straight to window functions before you understand grouping is the most common reason learners stall and decide they are bad at SQL.

This guide gives you a complete system: what to practice, in what order, how to check your work, and how to avoid habits that waste time. You will find a four-level exercise path, a comparison of practice methods, a weekly checklist, interview-style problems, and a short list of mistakes to avoid. Every section answers one question directly, so you can jump to the part you need or read straight through.

Finally, think about why you are practicing. A data analyst needs fast, accurate aggregates and date logic. A backend developer cares about joins, indexes, and transactions. A data engineer leans on CTEs, window functions, and DDL. The core exercises overlap heavily, but knowing your target role lets you spend the last two weeks on the topics that your interviewers or your daily job will actually test.

How Do You Practice SQL Step by Step?

Practice SQL by working one topic at a time, solving each exercise without looking at the answer first, and then comparing your output row by row. Spend about 70 percent of your session on new problems and 30 percent redoing earlier ones. This split keeps old patterns fresh while you stretch into harder material, and it prevents the common trap of only repeating what already feels easy.

Step one is reading the schema before you read the question. Spend a minute listing table names, primary keys, and foreign keys. Many wrong answers come from joining on the wrong column or assuming a column is unique when it is not. If your tool shows sample rows, scan them for NULL values, duplicate names, and odd date formats, because these details decide whether your query is correct.

Step two is writing the query in small pieces. Start with the FROM clause and make sure it returns the rows you expect. Add the join, run it, and check the row count. Then add WHERE, then GROUP BY, then the SELECT list. Building incrementally means that when a result looks wrong, you know exactly which clause caused it, which saves far more time than rewriting the whole query.

Step three is verifying against a known answer. Good exercise platforms provide expected output, but you can also verify by hand. Count rows with a simple SELECT COUNT(*), spot-check one customer or product manually, and test an edge case such as a customer with no orders. If two different queries give the same result, you can trust the answer much more than if you ran only one.

Step four is reviewing the official solution even when you were right. Compare approaches: did you use a subquery where a join would be cleaner, or a join where a window function would be simpler? Comparing styles teaches idioms that tutorials rarely mention. Keep a notes file with one line per lesson, such as use LEFT JOIN plus IS NULL to find missing matches.

Step five is repetition on a schedule. Revisit problems you missed after one day, one week, and three weeks. This spaced approach is far more effective than doing a single large block of exercises. For deeper topic lists, see this guide to sql practice exercises in full practice-test format, which pairs well with the daily drills described here.

Step six is adding variety in tools and data. Solve some problems in a browser sandbox, some in a local database, and a few on data you care about, such as your own spending or a public dataset. Different engines also behave differently with dates, string functions, and NULL ordering, so touching PostgreSQL, MySQL, and SQLite at least once makes your skills portable across employers.

Which SQL Exercises Build Interview Skills?

The exercises that matter most for interviews are the ones that combine joins with aggregation and ranking. Employers rarely ask you to recite syntax. They give a small schema and a business question, such as finding the top three products by revenue in each category, and watch how you reason. Practicing this exact pattern, with a timer, is the most direct preparation you can do.

Start with the classic ranking problem: return the second highest salary, or the top N per group. Solve it three ways using a subquery, DENSE_RANK, and ROW_NUMBER. Notice how ties change the answer. Interviewers love tie questions because they reveal whether you understand the difference between RANK and DENSE_RANK, and whether you ask clarifying questions instead of assuming.

Next, practice finding missing or duplicate data. Examples include customers who never placed an order, emails that appear more than once, and orders without a matching shipment. These tasks use LEFT JOIN with IS NULL, GROUP BY with HAVING COUNT(*) greater than one, and NOT EXISTS. Each pattern shows up constantly in both interviews and real data cleaning, so it is worth memorizing the shape of each.

Time-based problems are a third favorite. Compute month-over-month growth, a rolling seven-day average, or the number of users active on consecutive days. These rely on date functions, LAG, and self joins. Date syntax differs by database, so confirm which engine the employer uses, and practice with its functions such as DATE_TRUNC in PostgreSQL or DATEADD in SQL Server.

Platforms in the style of hackerrank sql are useful because they are timed and auto-graded, but they reward speed over explanation. Balance them by practicing aloud. Narrate your plan: identify the tables, state the grain of the result, choose the join type, and mention edge cases. Interviewers often score communication as heavily as the final query, particularly for analyst and engineering roles.

Finally, rehearse how you handle uncertainty. If you forget a function name, say so and describe what you need, then use a simpler alternative. If a query returns surprising output, debug out loud by checking row counts after each join. Calm, structured debugging impresses interviewers more than a perfect first attempt, and it is a skill you can train with ordinary daily exercises.

A realistic interview-prep target is thirty to forty problems across these themes, each solved at least twice. Track them in a simple table with the topic, the date, whether you solved it unaided, and the next review date. This small system turns scattered practice into measurable progress, and it tells you exactly where to focus when the interview is a week away.

What Mistakes Slow Down SQL Practice?

The biggest mistake is copying solutions after a few minutes of struggle. Struggle is the learning mechanism. Give every problem at least ten to fifteen minutes, including a re-read of the schema and a smaller version of the query. When you do look at the answer, close it and rewrite the query from memory the next day, so the pattern truly moves into long-term memory.

The second mistake is ignoring NULL values. NULL is not equal to anything, including another NULL, so a condition like salary = NULL never matches. Learners also forget that COUNT(column) skips NULLs while COUNT(*) does not, and that NOT IN returns no rows if the subquery contains a NULL. Build deliberate NULL exercises into every week until the behavior feels automatic.

Third, many learners misuse joins and then hide the damage with DISTINCT. If a join returns duplicate rows, adding DISTINCT may mask a flawed relationship rather than fix it. Instead, check the grain of each table: is it one row per customer, per order, or per order line? Aggregate to the right grain before joining, and your numbers will match the expected totals without tricks.

Fourth, people practice only what they already do well. It feels good to complete ten easy SELECT problems, but growth comes from the topics that feel uncomfortable. If window functions, recursive CTEs, or date logic make you nervous, schedule them first in the session while your attention is fresh. A simple rule is to start every session with one problem from your weakest topic.

Fifth, skipping the fundamentals of design hurts later. Even if you want to be an analyst, spend a few sessions on CREATE TABLE, primary and foreign keys, data types, and constraints. Understanding how tables are built explains why joins behave as they do. If you want a structured path through these topics, the guide on online sql courses: free & paid practice resources compares options by cost and depth.

Sixth, neglecting readability makes your own queries hard to debug. Use consistent capitalization for keywords, put each major clause on its own line, give tables short meaningful aliases, and name CTEs for what they contain, such as monthly_revenue. Readable queries are easier to check, easier to explain in interviews, and far easier for teammates to maintain months after you wrote them.

Finally, avoid measuring progress by hours rather than outcomes. Two focused 25-minute sessions with prediction, verification, and review beat a three-hour passive binge. At the end of each week, ask three questions: which problem types did I solve unaided, which did I miss twice, and what will I redo on Monday? Honest answers keep your practice aimed at real improvement.

How Should You Prepare in the Final Two Weeks?

In the last two weeks before an interview or assessment, stop learning new topics and start simulating the real event. Take a realistic schema, set a 30 or 45 minute timer, and solve three to five problems in a row without notes. Afterward, review every error. The purpose is to rehearse performing under pressure, which is a different skill from learning, and it only improves through deliberate repetition.

Spend the first week on your weak spots. Review your notes file and sort missed problems by topic. If four of your five misses involve window functions, schedule two focused sessions on partitions, ordering, and frames. If joins with duplicates are the issue, redo problems that require aggregating before joining. Targeted repair is more efficient than another pass over material you already know.

Use the second week to polish speed and communication. Practice stating your plan before typing, then write the query cleanly the first time. Learn keyboard habits for your editor, such as running a selected statement and formatting code quickly. If the interview uses a shared screen or plain text editor, practice there, because losing autocomplete and syntax highlighting can feel surprisingly disorienting if you have never worked without it.

Prepare a short mental checklist you can run on every problem: identify the grain of the output, list the tables needed, choose join types, decide the filters, then decide the aggregation or ranking. Finally check for NULLs, ties, and duplicates. Reciting this checklist silently takes ten seconds and prevents most careless errors, especially when nerves are high and your working memory is limited.

Know the basics of performance, even if the role is not engineering. Be ready to explain what an index does, why selecting only needed columns helps, and how to read a simple EXPLAIN output. Interviewers often ask a follow-up such as how would you make this faster, and a clear two-sentence answer about indexes, filtering early, and avoiding functions on indexed columns sets you apart from candidates who only memorized syntax.

The day before, do a light review rather than a heavy session. Skim your notes, redo two or three favorite problems, and stop early. Sleep and calm matter more than one extra hour of cramming. Confirm the technical details you can control, like the database engine, the allowed resources, and the time limit, so nothing about the format surprises you on the day.

After the interview or test, write down every question you remember, whether you solved it, and what you would do differently. This feedback loop turns each attempt into practice material for the next one. Over a few cycles, you will see the same patterns repeat: ranking, missing data, duplicates, and time-based comparisons. Mastering those four families covers a large share of what real SQL screens actually ask.