This course contains the use of artificial intelligence.
Here is what that means in practice, and why it is the reason to take this
one rather than another. Every question in these tests is built around a small
set of tables and one query. When the test was assembled, that query was
executed on two independent engines, SQLite and DuckDB, and the option marked
correct is the result set they both returned. A question whose stated answer
disagreed with the engines could not be published, the build refuses it. A
query on which the two engines disagreed could not be published either, because
that is a question about a dialect wearing the costume of a question about SQL.
Those two checks are the whole point of the product.
If you have taken SQL practice tests before, you already know the two
complaints. The answer key is wrong often enough that you stop trusting it, and
half the questions turn out to be about one vendor’s engine even though the
title said SQL. Neither can happen here. Each explanation ends with the exact
result both engines returned, and any query the two of them answered
differently was thrown out during the build rather than argued about in the
reviews.
What is inside
Six full practice tests, 180 questions, forty-five minutes and a pass mark
of 70 percent each. The sixth is deliberately the hardest of the set.
Every question runs against one of three small tables you will get to know
quickly, a shop with customers and orders, a company with departments and
employees, and a table of exam marks. They are deliberately small, and they are
deliberately awkward. There is an order whose customer does not exist, an
employee with no department, a department with no employees, a mark that was
never recorded and a pair of identical salaries. Those five rows are where the
interesting questions live, because they are where real tables break real
queries.
Questions are spread over seven blocks. Selecting, filtering and sorting.
Joins, including the outer joins and the anti join. Grouping and aggregation.
NULL, CASE and the set operators. Subqueries and common table expressions.
Window functions. Strings, numbers and type conversion. Every question is
tagged with its block, so the result screen tells you which one is costing you
the marks instead of leaving you to guess.
Each answer, right or wrong, carries its own explanation. Not one comment
for the question, one for every option, saying why that particular option is
wrong and which confusion usually produces it.
What you will not find here
No question depends on which database you use at work. Nothing about
PL/SQL, nothing about T-SQL, no vendor specific date function and no engine
specific string function. If a query behaved differently on the two engines it
was cut, which means what you learn here transfers to Postgres, MySQL, SQL
Server, Oracle and SQLite alike.
You will also not find the same question twice. The build rejects a repeated
query outright, which is the second thing reviewers on this shelf complain
about.
How to use it
Sit a test under exam conditions first, forty-five minutes, no database
open. Read every explanation afterwards, including the ones you got right,
because guessing correctly and knowing are not the same thing. Then rerun the
queries yourself. The tables fit in a screen and rebuild in a second on any
engine you like.
Who this is for
Anyone facing a SQL screening test for a data analyst, data engineer,
analytics or backend role, and anyone who writes SQL most weeks and suspects
that a few of the habits are cargo cult. If you have ever been surprised by
what NOT IN does when the subquery returns a NULL, or by a left join that
silently turned into an inner join, this is aimed squarely at you.
