How to assess · For hiring teams

How to Assess SQL Skills When Hiring

The test formats that actually work for SQL, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.

The short answer

Assess SQL with a task, not a conversation: hands-on query exercise, take-home analysis task, ai-generated sql assessment, live query review / debugging or mcq knowledge check. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.

Writes correct joins (inner, left, self, and anti-joins) and knows exactly which one a question needs
Aggregates accurately with GROUP BY and HAVING, and understands what each row in the result represents
Uses window functions (ROW_NUMBER, RANK, running totals) where a plain GROUP BY cannot answer the question
Handles NULLs deliberately and knows how they affect joins, aggregates, and comparisons

Build a SQL assessment →Read the full article ↓

Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.

When you are hiring for any data-facing role, SQL is the skill most likely to be overstated on a resume. Almost everyone claims "proficient in SQL," yet the gap between writing a basic SELECT and correctly joining, aggregating, and optimising queries over messy production data is wide. As a recruiter or hiring manager, you need to test SQL directly because it is the daily tool for analysts, engineers, and many product roles. This guide explains what to evaluate, which assessment methods reveal real ability, and how to score what you see before making an offer.

Why SQL is worth testing

SQL is the single most over-claimed line on data resumes, and weak SQL produces wrong numbers that quietly mislead a whole business. Testing directly shows whether a candidate truly understands joins, grouping, NULL behaviour, and how to get correct results from imperfect data, rather than recognising syntax. Because so many decisions depend on these queries, verifying real ability protects both your hire quality and your data's trustworthiness.

What strong SQL looks like

Writes correct joins (inner, left, self, and anti-joins) and knows exactly which one a question needs
Aggregates accurately with GROUP BY and HAVING, and understands what each row in the result represents
Uses window functions (ROW_NUMBER, RANK, running totals) where a plain GROUP BY cannot answer the question
Handles NULLs deliberately and knows how they affect joins, aggregates, and comparisons
Reasons about query performance: indexes, sargable predicates, and why a query is slow
Reads a schema and models data sensibly, spotting where granularity or duplicates will distort results
Validates their own output instead of trusting the first number the query returns

Ways to assess SQL

Hands-on query exercise

The candidate writes real queries against a sample schema, ideally against a live database where results execute and can be checked.

Pros

Directly measures the skill you are hiring for and surfaces correctness, not just syntax recognition.

Cons

Needs a realistic schema and a way to run queries; designing good problems takes effort.

Best for Any analyst, data, or engineering role where SQL is part of the daily job.

Take-home analysis task

A dataset and a business question to answer with SQL, plus a short write-up of findings.

Pros

Tests not only query skill but judgment, validation, and how they communicate results.

Cons

Authorship is hard to verify and AI can draft passable queries; keep it tightly scoped.

Best for Analyst and analytics-engineer roles where interpreting results matters as much as writing SQL.

AI-generated SQL assessment

An automated test like Cohesyve's that generates a unique schema and query problem per candidate, executed against real data with automatic result checking.

Pros

Cheat-proof and scalable: each candidate's problem differs so answers cannot be shared, and results are graded objectively.

Cons

A short discussion is still worth adding for senior roles to probe modelling judgment.

Best for Screening a high volume of applicants fairly before committing interviewer time.

Live query review / debugging

Hand the candidate a slow or incorrect query and ask them to diagnose and fix it while talking through their reasoning.

Pros

Reveals debugging skill, performance intuition, and how they reason about a query plan.

Cons

Harder to standardise and needs an interviewer who knows the material well.

Best for Senior analysts and data engineers who will own and optimise production queries.

MCQ knowledge check

A short quiz on join types, NULL semantics, and the order of SQL execution.

Pros

Quick, consistent early filter on fundamentals.

Cons

Recognising the right answer is far easier than writing a correct query from scratch.

Best for An initial gate before a hands-on stage, never as the deciding signal.

Cohesyve

Run a SQL assessment on your next opening

Cohesyve generates a unique SQL task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.

Try it free →Book a 30-min demo

What to test

Joins and set logic

The most error-prone area in everyday SQL. Test whether they pick the right join and understand its effect on row counts.

Return all customers and their orders, including customers with no ordersFind rows in table A that have no match in table B (anti-join)Explain why an inner join is silently dropping rows and fix itUse a self-join to compare each row to a related row in the same table

Aggregation and grouping

Confirm they understand grouping granularity, HAVING versus WHERE, and what each result row means.

Compute revenue per region and filter to regions above a thresholdExplain the difference between WHERE and HAVING with an exampleFind the average order value per customer, then the overall average of those averages

Window functions

Separates intermediate from advanced SQL. Test ranking, running totals, and per-group comparisons.

Rank products by sales within each categoryCompute a 7-day running total of daily revenueFind each customer's most recent order using ROW_NUMBERCalculate month-over-month change with LAG

NULLs and data correctness

NULL handling quietly breaks queries. Confirm they reason about it deliberately.

Explain why COUNT(column) and COUNT(*) can differShow how a NULL in a join key affects resultsSafely handle NULLs in a SUM or an average

Query performance and data modelling

For senior roles, test how they reason about indexes, query plans, and schema design.

Explain why a query is slow and how an index would helpRewrite a correlated subquery as a join for performanceCritique a denormalised schema and describe the trade-offs

Sample SQL questions

Write a query that returns every customer and the number of orders they have placed, including customers with zero orders.

Entry

Look for Strong: LEFT JOIN with COUNT on the order id (not *), and a GROUP BY that returns zero for orderless customers. Weak: INNER JOIN that drops zero-order customers, or COUNT(*) returning 1 for them.

What is the difference between WHERE and HAVING?

Entry

Look for Strong: WHERE filters rows before aggregation, HAVING filters groups after, with a clean example. Weak: thinks they are interchangeable or cannot give an example.

Find the second-highest salary in an employees table. Then explain how your answer handles ties.

Mid

Look for Strong: uses DENSE_RANK or a clean subquery and explicitly addresses duplicate salaries. Weak: uses LIMIT/OFFSET without considering ties, or hard-codes assumptions.

For each category, return the top three best-selling products. How would you write that?

Mid

Look for Strong: window function (ROW_NUMBER or RANK) partitioned by category, filtered in an outer query. Weak: tries to do it with GROUP BY and gets stuck, or returns only one per category.

You run COUNT(*) and COUNT(email) on the same table and get different numbers. Why?

Mid

Look for Strong: explains that COUNT ignores NULLs in a specific column, so some emails are NULL. Weak: confused, or assumes the data is corrupted.

A dashboard query takes 40 seconds. Walk me through how you would diagnose and speed it up.

Senior

Look for Strong: reads the query plan, looks for full scans, adds or uses indexes, makes predicates sargable, reduces unnecessary joins, considers pre-aggregation. Weak: random rewrites with no plan inspection.

When would you denormalise a schema, and what risks does that introduce?

Senior

Look for Strong: denormalise for read performance or reporting, trading off update anomalies and storage; mentions materialised views as an alternative. Weak: treats normalisation as always right or always wrong.

This query uses a correlated subquery and is slow. How would you rewrite it, and why is the rewrite faster?

Senior

Look for Strong: converts to a join or window function so the engine evaluates once instead of per row, and explains the cost difference. Weak: cannot identify the per-row evaluation problem.

Red flags

Reaches for an INNER JOIN by default and loses rows without noticing
Cannot explain how NULLs behave in joins, comparisons, or aggregates
Confuses WHERE and HAVING or the logical order of SQL execution
Has never used a window function for a problem that clearly needs one
Trusts the first result without sanity-checking row counts or totals
Cannot reason at all about why a query is slow or how an index helps
Recognises syntax in a quiz but cannot write a correct multi-table query from scratch

Scoring rubric

Criterion	Weight	What strong looks like
Join correctness and set logic	25%	Chooses the right join every time and reasons about its effect on row counts and duplicates.
Aggregation and grouping accuracy	20%	Groups at the correct granularity, uses HAVING correctly, and knows what each result row represents.
Window functions and advanced querying	20%	Applies ranking, running totals, and per-group comparisons fluently where GROUP BY cannot.
Data correctness and NULL handling	20%	Handles NULLs deliberately and validates output instead of trusting the first number.
Performance and modelling reasoning	15%	Reads query plans, reasons about indexes, and understands normalisation trade-offs.

Mistakes hiring teams make

Treating "proficient in SQL" on a resume as a verified skill rather than a claim
Testing only simple SELECTs and never probing joins, NULLs, or window functions
Using an MCQ quiz as the sole signal, where recognising syntax is far easier than writing it
Ignoring data-correctness habits, which is where weak SQL quietly produces wrong numbers
Designing toy schemas so clean that real-world messiness never surfaces
Over-weighting esoteric performance trivia for roles that mostly write analytical queries

Roles that need SQL

Data AnalystBusiness Intelligence AnalystData EngineerAnalytics EngineerBackend DeveloperData ScientistProduct AnalystDatabase Administrator

Common questions

Almost every candidate says they are proficient in SQL. How do I verify it?

Have them write real queries against a sample schema, not answer a quiz. Recognising syntax is easy; producing a correct multi-table join, choosing the right window function, and reasoning about NULLs is not. A hands-on exercise where results actually execute quickly separates genuine proficiency from resume optimism.

What level of SQL should I require for an analyst versus an engineer?

Analysts need rock-solid joins, aggregation, window functions, and the discipline to validate results. Data engineers need all of that plus performance tuning, query plans, and data modelling. Set the bar to the role: for many analysts, correctness and clear thinking matter more than deep optimisation knowledge.

How do I prevent candidates from copying SQL answers from each other or the web?

Use unique, per-candidate problems. An AI-generated assessment like Cohesyve's creates a different schema and query challenge for each person and checks the results against real data, so shared or Googled answers do not transfer. That keeps a high-volume screen fair without your team hand-grading every submission.

Is whiteboarding SQL a good test?

It is a weak proxy. Real SQL work involves running a query, reading the result, and iterating. Asking someone to write perfect syntax on a whiteboard with no execution penalises detail-orientation over actual ability. Let candidates run queries against a real database so you observe how they verify and refine their work.

Cohesyve · Skill assessments for hiring

Test SQL before the first interview

Generate a role-specific SQL assessment from your job description and see who can do the work before you spend interview time on them.

1,500+

assessments completed

50%

faster time-to-hire

90%

completion rate

5 min

from JD to assessment

No credit card · 10 free candidates · Plans sized to your hiring volume

From the blog

Related skill guides