Blog›SQL Practice Questions (With Answers, Easy to Hard)
SQL SkillsCareer
SQL Practice Questions Easy to Hard, With Answers
Ten practice questions with worked solutions, from your first WHERE clause to window functions. Try each one before you reveal the answer, because that is where the learning actually happens.
CR
Conor Robertson
July 18, 2026 · 9 min read
Frequently asked questions
The questions people ask about practising SQL.
Ready to practice on real data?
QueryCase teaches SQL through mystery cases on real datasets. Music, sports, film, and more. Your first cases are completely free.
Most SQL practice fails for one boring reason: people read answers instead of writing queries. You skim a solution, it makes sense, you feel like you learned something, and then a week later you are staring at a blank editor with no idea where to start. Recognising a correct query and being able to produce one are completely different skills, and only one of them gets you through an interview or a real task at work.
So here is the deal with the ten questions below. Each one is a prompt and a schema. Write your query first. Only then reveal the answer and compare. If your query matched, great, move on. If it did not, the gap between yours and the worked solution is the single most valuable thing on this page, more valuable than the solution itself.
They ladder from a first WHERE clause up to window functions, which is roughly the order these ideas show up in real work, and almost exactly what a data-analyst interview walks through.
How to use this page
Read the question. Look at the schema. Write your own query somewhere, even if you are not sure. Then hit Reveal solution and compare. The point is not to collect answers, it is to notice where your instinct and the worked query diverge.
Ten questions, easy to hard
Every solution is written in standard SQL (it runs as-is in PostgreSQL or DuckDB) and each one has been checked by hand. The schema for each question sits right above it, so there is no scrolling back and forth.
EasyQuestion 1
List the name and salary of every employee in the Sales department.
Calculate the month-over-month percentage change in revenue.
orders(id, customer_id, amount, order_date)
HardQuestion 10
Produce a running total of daily sales, ordered by date.
sales(id, sale_date, amount)
The patterns underneath the questions
If you look back at those ten, they are not really ten separate things to memorise. They are a handful of patterns that recombine endlessly:
Filter, then aggregate. Questions 1, 2, 4 and 6. Almost every reporting query is some version of "narrow the rows down, then count or sum what is left."
Find what is missing. Question 5. The anti-join (a LEFT JOIN with a NULL check, or NOT EXISTS) is how you answer any "who has never" or "which of these has no matching" question, and it trips people up far more than it should.
Filter after grouping. Question 6. WHERE cannot see an aggregate because the aggregate does not exist yet when WHERE runs. HAVING filters after the grouping happens. This is the single most common SQL interview gotcha.
Compute across a group without collapsing it. Questions 7, 8, 9 and 10. The moment you need every row and something calculated across its group (a department average, a rank, a previous value, a running total), you have left behind and you need a window function.
GROUP BY
Notice that the difficulty is not really about syntax getting harder. It is about the same operations combining in more steps. That is why practising the patterns beats memorising queries: once you can see which pattern a question is asking for, writing it is mechanical.
Why "read the answer" does not count as practice
There is a real reason attempting the query first matters, and it is not just discipline.
When you read a worked solution, your brain runs a cheap recognition process: "yes, that looks right." Recognition is easy and it fades fast. When you write a query from a blank editor, you run a much more expensive retrieval process: you have to actually reconstruct the pattern from memory and commit to it. Retrieval is what builds durable recall, which is the difference between nodding along to a HAVING explanation and reaching for HAVING under interview pressure without thinking.
This is also why passive resources (video courses, cheat sheets you scroll) feel productive but leave you unable to write anything. They are all recognition, no retrieval.
You do not learn SQL by understanding a query. You learn it by producing one from nothing, being wrong, and closing the gap.
If you want the concepts behind these questions in more depth, we have written the hard ones up in full:
The trouble with a list of ten questions is that it ends. Real fluency comes from doing this steadily against a real database, not memorising a page. That is what QueryCase is built for: 54 guided cases that ladder exactly like the questions above, each one a mystery you crack by writing genuine SQL, with drills between topics and an exam at the end of every rank. It runs entirely in your browser, so there is nothing to install and no database to set up.
The first rank is free, and you can solve the opening case before you even make an account. Start there, and the difference between reading SQL and writing it will close faster than any list of answers can manage.
SQL Practice Questions (With Answers, Easy to Hard) | QueryCase