SQL Skills Assessment: What to Test When Hiring for Data Roles

Why generic SQL tests miss the signal they need

A candidate who can write a correct JOIN or GROUP BY on request has cleared a fairly low bar. What separates a SQL-fluent hire from a merely SQL-literate one is usually invisible in a simple syntax test: do they reason about what happens with NULLs and duplicates, do they think about how a query performs once the table has ten million rows instead of ten, and can they reason about how a schema should be structured before writing the queries that depend on it.

This guide is a framework for structuring that assessment, not a fixed question list.

The four dimensions of SQL assessment

1. Query fundamentals and correctness

What it tests: whether the candidate writes SQL that returns the right rows, not just SQL that runs without an error.

How to probe it: give a small multi-table scenario and ask for a query with a join, then quietly check whether they consider what happens to unmatched rows, NULL values, or duplicate keys, without prompting them first.

What a strong answer sounds like: states an assumption about NULLs or unmatched rows before running the query, and adjusts the join type or filter placement accordingly.

Red flag: the query works on the sample data shown but would silently return wrong results the moment a real-world edge case (a missing foreign key, a NULL in a filtered column) appeared.

2. Query performance and scale awareness

What it tests: whether the candidate's solution holds up once the data isn't a handful of sample rows, since most SQL interview mistakes that matter in production are invisible on small test data.

How to probe it: after a correct query, ask what changes if the table has ten million rows. Listen for whether they can name what would slow down (a missing index, a full table scan, an OFFSET-based pagination) without being walked through it.

What a strong answer sounds like: names the specific operation that would become expensive at scale and proposes a concrete fix, an index, a different pagination approach, a rewritten join, rather than a vague "it would probably be slower."

Red flag: no instinct for cost at all. The candidate is visibly unprepared for the "what if this table were huge" follow-up and has never considered query performance as a design concern.

3. Data modeling and schema judgment

What it tests: whether the candidate can reason about how data should be structured, not just how to query structures someone else already built.

How to probe it: describe a small business scenario (an e-commerce order system, a simple booking platform) and ask the candidate to sketch out the tables and relationships before writing any queries against them.

What a strong answer sounds like: identifies the entities and relationships correctly, discusses normalization trade-offs where relevant (e.g., "I'd denormalize this field for read performance since it's queried far more often than it's updated"), and can explain the reasoning, not just produce a diagram.

Red flag: the candidate can write queries fluently but has no framework for schema design when asked to start from a blank slate, or jumps straight to tables without discussing what the data actually represents.

4. Data integrity and production readiness

What it tests: habits that don't show up in a query-writing exercise but matter enormously with real data: handling duplicates safely, writing idempotent inserts or updates, and thinking about what happens when a query runs against data that doesn't match the assumptions baked into it.

How to probe it: ask what happens if their query or update runs twice, or against a table with more duplicate or NULL values than expected. See whether they've already accounted for it.

What a strong answer sounds like: proactively distinguishes between operations that are safe to re-run (idempotent) and ones that aren't, and can explain how they'd guard against a destructive query running against the wrong data or running twice by accident.

Red flag: every query assumes clean, well-formed data with no duplicates and no unexpected NULLs, and the candidate has no answer for what happens when that assumption turns out to be wrong.

Calibrating by role level

Level	Fundamentals	Performance & scale	Schema judgment	Data integrity
Junior / fresher	Writes correct joins and aggregations with some guidance	Aware indexes and query cost exist, may need prompting to reason about them	Can follow an existing schema; not expected to design one unprompted	Understands duplicates and NULLs need handling, even if incomplete
Mid-level	Handles NULLs, unmatched rows, and duplicates without prompting	Names what would become slow at scale and proposes a fix unprompted	Can sketch a reasonable schema for a well-scoped scenario	Writes idempotent operations by habit, not just when asked
Senior / staff	Reasons about correctness under edge cases most candidates wouldn't think to test	Reasons about performance alongside real infrastructure constraints (indexing strategy, read/write patterns)	Defends schema trade-offs (normalization vs. denormalization) against real alternatives	Anticipates data-integrity failure modes a mid-level candidate would miss, including concurrent writes

A junior candidate who needs a nudge toward performance thinking is normal. A senior candidate who needs that same nudge, on a role where SQL is core to the job, is a real signal worth weighing carefully.

Common mistakes when assessing SQL skills

Testing syntax recall instead of reasoning. Asking a candidate to recite the difference between WHERE and HAVING says little. Asking them to write a query and watching whether they consider NULLs and duplicates unprompted says much more.
Never asking about scale. A query that's correct on ten sample rows can be catastrophically slow on ten million. Skipping the "what if this table were huge" question is the single most common gap in informal SQL screens.
Treating schema design as out of scope for a "SQL round." For data-heavy roles especially, the ability to design a reasonable schema is at least as important as the ability to query one someone else built.
Not distinguishing junior from senior expectations. The same syntax question can be a fair bar for a fresher and a wasted signal for a senior candidate who should be probed on judgment and trade-offs instead.

Frequently asked questions

Should SQL assessment be a separate round from general coding assessment? For data-heavy roles, yes, ideally. SQL reasoning (schema judgment, query performance, data integrity) is different enough from general algorithmic problem-solving that combining them into one round usually shortchanges both.

How much SQL depth should a backend engineer be expected to have, versus a dedicated data engineer? A backend engineer generally needs strong query fundamentals and performance awareness, since they'll write production queries regularly. Schema design and deeper data-modeling judgment matter more for data engineers and analysts who own the underlying structure, not just the queries against it.

Is it reasonable to test SQL without access to a real database? For fundamentals, yes, a whiteboard or shared-doc query is enough to assess reasoning. For performance and scale questions specifically, a real (or realistic sample) dataset gives much better signal than a candidate reasoning purely in the abstract.

What's the single most revealing question in this framework? "What would you check before running this against the real data?" It reliably separates candidates who think about NULLs, duplicates, and idempotency from those who only think about getting the right answer on the sample shown.

Do these four dimensions apply the same way across MySQL, PostgreSQL, and other SQL dialects? Yes. The dimensions are about reasoning, not dialect-specific syntax. Minor differences (window function syntax, upsert patterns) don't change what's actually being assessed.

Structuring this at scale

Running a consistent SQL assessment across every data-role candidate, same four dimensions, same calibration by level, comparable scoring across interviewers, is hard to sustain informally as hiring volume grows. If you're screening SQL-heavy roles at scale and want structured, comparable assessments rather than ad hoc question lists, Skolarli's assessment platform is built around this kind of framework-first evaluation.