What are some SQL concepts that should be included in a SQL programming test?

A SQL programming test should measure eight things: data retrieval, joins, aggregation, subqueries and window functions, data manipulation, schema design and constraints, indexing and performance, and debugging a query that returns the wrong rows. Anything past that list is usually trivia, or it belongs to a different role's test.

The reason to get this right is that SQL is not a niche skill you can screen for casually. In the 2025 Stack Overflow Developer Survey, 58.6% of respondents reported extensive work in SQL over the previous year, which puts it third among all languages, ahead of Python at 57.9%. PostgreSQL alone is used by 55.6% of respondents and MySQL by 40.5%. So most of your engineering, analytics, and data candidates will claim SQL on a resume. A test is how you find out which claims hold.

TL;DR

• Test eight concepts: retrieval, joins, aggregation, subqueries and window functions, data manipulation, schema and constraints, indexing and performance, and debugging.
• Weight those concepts by seniority instead of giving every candidate the same paper. A junior analyst and a data engineer should not sit the same test.
• Keep it to 30 to 45 minutes. Long tests lose candidates without adding much signal.
• Set the passing score from what the role actually requires, not from a universal 70%.
• Hands-on queries against a real schema predict better than multiple choice. Use multiple choice only for high-volume first-pass screening.

What is a SQL programming test?

A SQL programming test is a timed, scored assessment that asks a candidate to read a database schema and write or fix queries against it. It measures whether someone can get correct results out of a relational database under realistic conditions, rather than whether they can recite syntax. The good ones look like a small slice of the job.

That distinction matters more than it sounds. A test built from definitions produces a ranked list of people who studied definitions. A test built from tasks produces a ranked list of people who can do tasks. The research backs the second approach. In a 2022 re-analysis of selection research summarized by the Society for Industrial and Organizational Psychology, job knowledge tests reach an operational validity of .40 and work sample tests .33, against .31 for general cognitive ability. Job-specific evidence wins.

What SQL concepts should the test include?

Eight concepts cover the ground for almost every SQL-adjacent role. The table maps each one to what it actually proves about a candidate and the task shape that produces that evidence. This is the Testlify Competency-to-Evidence Matrix applied to one skill: start with the role, map the role to competencies, then connect each competency to evidence you can score consistently.

1. Data retrieval

Start here because everything else sits on top of it. Give the candidate a schema they have not seen and ask for a specific slice of it. Watch for filtering that is technically correct but wrong at the edges, which is where NULL handling shows up. A candidate who writes WHERE status != 'closed' and quietly loses every row where status is NULL has told you something useful.

2. Joins and relationships

Most people can name the join types. Far fewer can predict what happens to their row count. Build one question with a three-table join where an INNER join drops legitimate records, and see who notices. This is the single most reliable separator between a candidate who has read about SQL and one who has shipped with it.

3. Aggregation and grouping

GROUP BY is where quiet errors live. Ask for a summary that requires filtering before aggregation and again after it, so the candidate has to reach for both WHERE and HAVING and know which does which. Then ask them to explain a discrepancy between two totals. The explanation is worth more than the query.

4. Subqueries and window functions

Window functions are the clearest line between intermediate and advanced. "Find each customer's most recent order" or "rank products by revenue within each category" takes a nested mess without them and about four lines with them. For analytics and data engineering roles, treat this as core rather than bonus.

5. Data manipulation

Reading data is half the job. Ask for an UPDATE or a DELETE wrapped in a transaction, with a condition that would make a careless version destructive. What you are testing is caution: does the candidate reach for a SELECT to check the affected rows before running the change? That habit is hard to teach and easy to observe.

6. Schema design and constraints

Show a small schema with a deliberate flaw, a missing foreign key or a column that should not accept NULL, and ask what would go wrong. Candidates who think in constraints prevent data problems. Candidates who do not will spend their first year cleaning up after them.

7. Indexing and query performance

Performance questions are the easiest to write badly. "What is an index?" tells you nothing. Instead, show a query plan with a full table scan and ask what to change and what it would cost. Real optimization is a tradeoff, and a candidate who mentions the write penalty of an extra index is showing judgment, not recall.

8. Debugging a query that returns the wrong rows

Save one task for a query that runs without error and returns the wrong answer. No syntax error, no crash, just a subtly incorrect result from a misplaced join condition or a filter applied after aggregation instead of before. This is what the job actually feels like, and almost no assessment includes it.

Pro Tip: put the debugging task last and tell candidates the query runs fine. The ones who re-check the output against the question rather than the syntax are the ones you want.

How should SQL test difficulty scale by seniority?

Giving every candidate the same test is the most common design error, and it fails in both directions. A junior analyst gets buried by window functions and drops out. A senior data engineer coasts through a syntax quiz and you learn nothing. Weight the eight concepts by what the role does daily.

Demand for these roles is not evenly distributed either, which is worth knowing before you set the bar. The U.S. Bureau of Labor Statistics projects employment of data scientists to grow 34% between 2024 and 2034, with about 23,400 openings a year, while database administrators and architects grow 4% over the same period with roughly 7,800 annual openings. If you are hiring into the analytics side of that split, you are competing in a much tighter market, and a 90-minute test is a candidate-experience tax you cannot afford.

How long should a SQL test be?

Thirty to 45 minutes, with 45 as the ceiling for most roles. Past that, completion rates fall and the extra questions rarely change the ranking. Four well-built tasks that require real thought produce a cleaner signal than 40 multiple-choice items, and they take a third of the candidate's evening.

There is a cost argument here too. SHRM's 2025 benchmarking report puts the average nonexecutive cost per hire at $5,475 and executive hires at $35,879. Every candidate who abandons a bloated assessment is spend you have already made and cannot recover. Shorter tests are not a compromise on rigor. They are a compromise on padding.

What is a good passing score for a SQL test?

There is no universal number, and 70% is a convention rather than a finding. The defensible way to set a cut score is to anchor it to the role: decide which concepts are non-negotiable for the job, score those sections separately, and set the bar there rather than on the aggregate.

A candidate who scores 65% overall but got every join and aggregation task right is a strong junior analyst. A candidate at 80% who failed both data-manipulation tasks is a risk you would not take for a role with write access to production. Section-level scoring catches both cases; a single percentage hides them. Document the reasoning before you see the results, because a cut score written after the fact is difficult to defend if anyone asks.

Multiple choice or hands-on queries?

Hands-on, wherever you can afford it. Writing a query against a real schema is a work sample, and work samples predict performance better than recognition tasks. Multiple choice has one genuine use: a fast first pass when you have hundreds of applicants and need to cut the pool before spending reviewer time.

The honest tradeoff is that hands-on tasks cost more to build and more to score. If you go that way, use a ready-made library test for SQL or a role-specific SQL developer assessment rather than writing questions from scratch, and reserve your own effort for the one task that mirrors your actual data model. A blended test works well: 10 minutes of multiple choice to check breadth, then two query tasks that carry most of the weight.

Where do SQL tests go wrong?

Four failure modes account for most of it.

1. Testing memory instead of judgment. Asking for syntax a candidate would look up in four seconds measures preparation for the test, not fitness for the job.
2. One test for every level. Covered above, and still the most common mistake.
3. Using the test as the whole decision. A SQL score is one signal. Pair it with structured questions for SQL developers so a strong test result gets probed rather than trusted.
4. Never checking the test against outcomes. If nobody compares scores to how those hires performed six months later, the test is a ritual.

That last one is where most teams stop. The World Economic Forum's Future of Jobs Report 2025 found employers expect 39% of workers' core skills to change by 2030, and seven in 10 companies rank analytical thinking as a core skill. A SQL test written three years ago and never revisited is measuring a job that has partly moved. Revisit the weighting once a year, and check it against how the people who passed it are actually doing. Testlify's guidance on evaluating SQL candidates end to end and the broader hiring guide for SQL developers both cover the stages either side of the test itself.

Hire SQL talent on evidence, not guesswork

Pick the eight concepts, weight them for the role, keep it to 45 minutes, and score the sections that matter separately. That is a test that tells you something. To see how the weighting, scoring, and reporting work on a real assessment, book a demo and bring the role you are hiring for.

Key takeaways

• Eight concepts, not a syllabus dump. Retrieval, joins, aggregation, subqueries and window functions, data manipulation, schema and constraints, indexing, and debugging cover almost every SQL role. Adding more concepts widens the test without sharpening it, because the extra questions correlate with the ones you already asked.
• Weight by seniority or the test lies to you. The same paper buries a junior and bores a senior, so it ranks candidates by tolerance rather than skill. Shift roughly 70% of a junior test toward retrieval, joins, and aggregation, and roughly 60% of a senior test toward performance, schema, and debugging.
• Job-specific evidence outpredicts general ability. Job knowledge tests sit at .40 operational validity and work samples at .33, against .31 for cognitive ability. That is the case for a SQL task on your schema over a generic reasoning test, and it is why the format of the question matters as much as its content.
• Cut scores belong to the role, not to convention. Decide which sections are non-negotiable before results land, score them separately, and set the bar there. A 65% with clean joins can be a better junior hire than an 80% who cannot safely run an UPDATE.
• Length is a candidate-experience decision with a price tag. At $5,475 average cost per nonexecutive hire, every abandoned 90-minute assessment burns money already spent. Thirty to 45 minutes holds the signal and keeps the funnel intact.
• One debugging task earns its place. A query that runs cleanly and returns the wrong rows is the closest thing to the real job, and it is the task almost every assessment leaves out. It separates candidates who verify their output from those who stop at "no error".
• A test that is never reviewed stops being a test. With 39% of core skills expected to shift by 2030, re-check the weighting yearly against how the people who passed are performing, or the score becomes a habit rather than a measurement.

FAQs