Intermediate — Your SQL Skill Level
Everyday reporting is solid; the edge is clauses interacting with each other
Intermediate handles everyday reporting queries comfortably — joins, GROUP BY, straightforward filtering — without being slowed down by routine dashboard or ad-hoc analysis work.
The gap to Advanced is mostly in what happens when clauses interact: a WHERE clause on the joined table quietly turning a LEFT JOIN back into an INNER JOIN, a join that fans out row counts before an aggregate gets applied to them, a NOT IN that silently returns nothing because one NULL slipped into the subquery. Those are the kind of bugs that pass a quick eyeball check and only show up when someone compares the total to a different report.
Strengths
- Everyday reporting queries — joins, GROUP BY, straightforward filtering — do not slow you down.
- You would not be the bottleneck on routine dashboard or ad-hoc analysis work.
- You handle multi-table joins comfortably: matching keys, picking the right join type for the question.
- You read a query for what it returns, not just for what it looks like it should return.
- This is the level most day-to-day reporting and analysis work actually requires.
Growth Edges
- A WHERE clause filtering on the joined table's columns quietly turns a LEFT JOIN back into an INNER JOIN, dropping the unmatched rows you meant to keep.
- A one-to-many join fans out row counts before an aggregate runs, which inflates a SUM or COUNT unless you deduplicate first.
- NOT IN silently returns zero rows the moment a single NULL slips into the subquery — EXISTS usually does not have that trap.
- HAVING and WHERE look interchangeable and are not — one filters rows before grouping, the other filters groups after.
- Following an existing multi-table query is comfortable; designing the join order and filter placement for a new one is a different, not-yet-practiced skill.
Career Matches
Compare
Frequently Asked Questions
What does an Intermediate SQL result mean?
You handle everyday reporting queries comfortably. The gap to the next band is mostly bugs that appear when clauses interact with each other, not general query-writing ability.
What should I learn next from this band?
How WHERE filtering on a LEFT JOIN's right-hand columns can silently turn it into an INNER JOIN, row multiplication from one-to-many joins before you aggregate, why NOT IN breaks in the presence of NULLs, and HAVING vs WHERE.
Why does a LEFT JOIN sometimes behave like an INNER JOIN?
If you filter on the right-hand table's columns in the WHERE clause, unmatched rows — which have NULL in those columns — get filtered out too, because NULL fails almost every comparison. The fix is moving that condition into the ON clause instead.
Why does NOT IN sometimes return zero rows unexpectedly?
If the subquery feeding NOT IN returns even one NULL, every comparison against that NULL evaluates to UNKNOWN, and SQL can no longer guarantee any row satisfies the NOT IN condition — so it returns nothing. NOT EXISTS does not have this trap.
How is the SQL Test scored?
30 scenario questions across four areas — filtering and NULL semantics, joins and set operations, aggregation and subqueries, and window functions, CTEs and constraints. Your band comes from the total, and the breakdown is shown by category.
Is this a certified SQL qualification?
No. This is a self-check that places you in one of four bands so you know what to learn next. It is not a certification and it is not a validated assessment instrument.
Explore all results in depth
Already taken the test, or just curious? Read the in-depth guide for any result — strengths, challenges, career matches, famous people, and FAQs.
Results Library content is educational, not a clinical assessment.