SQL is on every backend and data engineering job description, and almost every developer claims to know it. Most do — at a basic level. They can write SELECT statements, filter with WHERE, join two tables, and group aggregations. That covers maybe 30% of what production SQL engineering actually involves.
The other 70% — window functions, query execution plans, index design, transaction isolation, the N+1 problem, covering indexes, query cost estimation — is where the real skill lives. And it's exactly what backend and data engineering interviews probe.
SQL is unusual among programming skills in that the gap between "I know SQL" and "I'm good at SQL" is enormous, and most developers don't know which side of that gap they're on. This quiz is calibrated to find that line.
What senior SQL knowledge looks like
Window functions are one of the most powerful and underused features in SQL. Unlike aggregate functions that collapse rows, window functions compute values across a set of rows while keeping each row visible in the result. ROW_NUMBER(), RANK(), LAG(), LEAD(), SUM() OVER() — these unlock query patterns that would otherwise require multiple passes or application-level processing. If you've never used window functions, you're solving problems the hard way.
CTEs (Common Table Expressions) use the WITH clause to let you name and reuse intermediate query results. They make complex queries readable and maintainable. The distinction between a CTE and a subquery is not just stylistic — in some databases, CTEs are materialised (computed once and stored), while subqueries are re-evaluated at each reference. That distinction matters for performance.
The execution plan is how a query planner decides how to execute your SQL. EXPLAIN and EXPLAIN ANALYZE in PostgreSQL show you the plan — whether it's doing a sequential scan or an index scan, the estimated vs actual row counts, and where the bottleneck is. Developers who've never read an execution plan are optimising SQL by intuition rather than evidence.
Index design is an engineering decision with real trade-offs. A B-tree index speeds up range queries and equality lookups. A partial index covers only a subset of rows. A covering index includes all the columns a query needs, avoiding a table lookup entirely. Indexes slow down writes. Adding an index to the wrong column wastes disk space and provides no benefit. Understanding when to add an index — and when to avoid it — requires understanding how the query planner uses them.
ACID and transaction isolation levels determine what one transaction can see about another in-flight transaction. Read Committed, Repeatable Read, Serializable — each provides stronger isolation with higher contention cost. Understanding dirty reads, non-repeatable reads, and phantom reads is essential for any developer writing code that touches a relational database in a concurrent environment.
10 questions that test real SQL knowledge
These questions are modelled on the SQL concepts that appear most frequently in backend and data engineering interviews.
1. You run: SELECT * FROM orders LEFT JOIN customers ON orders.customer_id = customers.id. What rows appear in the result where a customer has no matching orders? What would the customer columns contain?
2. What is the difference between a window function and a GROUP BY aggregation? Write a query that shows each employee's salary alongside the average salary for their department, without collapsing the rows.
3. You add an index to a frequently-queried column and the query actually gets slower. Name two scenarios where adding an index can hurt performance.
4. You have a slow query. What do EXPLAIN and EXPLAIN ANALYZE tell you, and what's the key difference between them?
5. What is the difference between a CTE and a subquery? In PostgreSQL, when does the distinction affect query performance?
6. What are transaction isolation levels? Name two problems (dirty read, non-repeatable read, or phantom read) and the minimum isolation level that prevents each.
7. What is a covering index? Write an example and explain why it can be significantly faster than a regular index for certain queries.
8. What is the difference between WHERE and HAVING? Can you use an aggregate function in a WHERE clause?
9. You want to update all orders that belong to customers in a specific city. Write the UPDATE statement using a JOIN or subquery.
10. What is index cardinality and why does it affect how the query planner decides to use an index?
Why SQL depth matters for backend roles
Most backend developers interact with databases through an ORM — Prisma, SQLAlchemy, ActiveRecord, Hibernate. The ORM abstracts the SQL, which is convenient until something goes wrong. A slow page load, an N+1 query, a timeout under load — these are database problems, and fixing them requires understanding what SQL the ORM is generating and whether it's efficient.
Backend developers who don't understand SQL deeply tend to solve database problems by adding more cache, upgrading hardware, or fetching more data than they need and filtering in application code. Backend developers who understand SQL solve the same problems at the query level — with an index, a JOIN rewrite, or a window function — without the operational complexity.
Data engineering is even more SQL-dependent. If you're building pipelines, writing dbt models, or working with a warehouse like BigQuery or Snowflake, SQL is your primary tool. The difference between a data engineer who can write a working query and one who can write an efficient query that doesn't consume ten times the compute budget is largely a question of SQL depth.
What your SQL score means
The Skeelzy SQL quiz covers the full range from join semantics to window functions to index strategy to transaction isolation. A score above 80% indicates you understand SQL at a production engineering level — you can read execution plans, design indexes thoughtfully, and write complex analytical queries without reaching for application-level workarounds.
A score between 60-80% indicates solid working SQL knowledge with gaps in the more advanced features. Window functions and query optimisation are the most common gaps at this level — they're features that developers often haven't needed in their day-to-day work, even if they've been writing SQL for years.
Your SQL score appears on your Skeelzy resume as a verified badge alongside your other skills. For backend and data engineering roles where SQL is genuinely tested in interviews, a verified score is a stronger signal than the unverified "SQL" that appears on every resume in the candidate pool.