Make talent quality your leading analytic with skills-based hiring solution.
Plenty of candidates can define a JOIN. Fewer can write one against a messy table and explain why their result has duplicate rows. Good SQL interview questions find that gap early, before an analyst or developer ends up on a team that needed someone who can actually query production data.
This guide groups SQL interview questions by difficulty, gives a sample query or model answer for the questions that matter most, and notes what a strong answer shows. Use it to build an interview loop, calibrate a hiring manager, or check your own understanding if you’re preparing.
Jump to a section:
Resumes list SQL the way they list Excel: almost everyone claims it, and the claim covers anything from a few SELECT statements to tuning queries on billion row tables. Targeted questions do three jobs. They show whether stated experience matches real skill, they show how a candidate reasons when a query doesn’t return what they expected, and they give every candidate the same questions, which keeps the evaluation consistent.
Best for: business analysts, data analysts early in their careers, QA testers, and support engineers who query data occasionally.
These questions cover the vocabulary and basic commands. A candidate who struggles here will struggle with everything after it.
Core concepts to cover:
Question: Why does WHERE discount = NULL return no rows, even when some discounts are missing?
What a strong answer shows: NULL means “unknown,” so any comparison with = evaluates to unknown, not true. The correct filter is WHERE discount IS NULL. Strong candidates also mention that aggregate functions like AVG() ignore NULLs, which changes results.
Question: How would you count customers per country and show only countries with more than 100 customers?
SELECT country, COUNT(*) AS customer_count
FROM customers
GROUP BY country
HAVING COUNT(*) > 100;What a strong answer shows: they use HAVING for the aggregate filter, not WHERE, and can explain why.
Other beginner questions: How do you create, update and delete a table? How do you select specific columns? What does DISTINCT do? What is a subquery? What are the main uses of SQL in a business?
Best for: SQL developers, ETL developers, BI developers and analysts who own reporting.
At this level, the questions test whether a candidate can combine functions, understand execution order and design tables that stay clean as data grows.
Topics to cover:
CASE expressionORDER BY, set operators (UNION, UNION ALL, INTERSECT, EXCEPT) and pattern matching with LIKETRUNCATE vs DELETE vs DROPWHERE vs HAVINGQuestion: You join orders to customers with an INNER JOIN and the order count drops. Why, and how would you keep every order?
What a strong answer shows: an INNER JOIN keeps only rows that match on both sides, so orders with a missing or invalid customer_id disappear. A LEFT JOIN from orders keeps them, with NULLs in the customer columns. Strong candidates suggest checking for those orphaned rows as a data quality signal.
Question: How do you find duplicate email addresses in a users table?
SELECT email, COUNT(*) AS occurrences
FROM users
GROUP BY email
HAVING COUNT(*) > 1;Follow up: How would you delete the duplicates but keep the earliest record? Listen for a window function or a self join on the key, and for the candidate asking which record counts as “earliest” before writing anything.
Question: Why can’t you use a column alias defined in SELECT inside the WHERE clause?
What a strong answer shows: WHERE is evaluated before SELECT, so the alias doesn’t exist yet. The logical order is FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY.
Other intermediate questions: How do you select odd or even rows? How do you insert rows in bulk? How do you find the last inserted ID? How do you return random rows? How do you search text by pattern?
Best for: senior data engineers, data architects, database administrators and data scientists who own pipelines.
Advanced questions move from writing correct queries to writing queries that stay correct and fast at scale, under concurrent load.
Topics to cover:
EXPLAIN; tuning a slow queryROLLUP and CUBEQuestion: Return the top three products by revenue in each category.
WITH ranked AS (
SELECT category, product_id, revenue,
DENSE_RANK() OVER (PARTITION BY category ORDER BY revenue DESC) AS rnk
FROM product_revenue
)
SELECT category, product_id, revenue
FROM ranked
WHERE rnk <= 3;What a strong answer shows: they choose between ROW_NUMBER, RANK and DENSE_RANK on purpose and can explain what happens with ties.
Question: A dashboard query that ran in two seconds now takes two minutes. Walk me through what you’d check.
What a strong answer shows: a sequence, not a guess. Check the execution plan for full scans, confirm the filtered columns are indexed, look for a function wrapped around an indexed column, check whether table statistics are stale, and ask what changed in data volume. Red flag: jumping straight to “add more indexes” without looking at the plan.
Question: What problem does the REPEATABLE READ isolation level solve, and what can still go wrong?
What a strong answer shows: it prevents non repeatable reads within a transaction. Depending on the engine, phantom reads may still occur, and higher isolation means more locking or more serialization failures.
Definitions tell you what a candidate has read. A short query task tells you what they can do. Good scenario prompts for a 20 to 30 minute slot:
Ask the candidate to talk through assumptions before they start. The best ones ask about NULLs, ties and time zones without being prompted.
Verbal SQL interview questions have a ceiling. Candidates can rehearse definitions, and question lists like this one are public. The stronger signal comes from watching someone write and debug a query against real tables.
Glider’s Technical Assessments cover 250+ languages and technologies, including MySQL, PostgreSQL, Oracle, MSSQL and PL/SQL, so a SQL screen can run on the dialect your team actually uses. Coding Simulations recreate a working environment where candidates build and debug rather than answer isolated questions, and Live Coding Interviews let an interviewer watch a candidate work through a scenario like the ones above.
Because remote SQL tests are easy to outsource, pair them with AI Proctoring and ID Verify, so the person who passes the test is the person you interview and hire. Proctoring flags are evidence for a recruiter to review, not automatic rejections. If you’re also screening for reporting or analysis roles, the Skills Test Library and the Interview Questions Library have related tests and question sets.
The most common SQL interview questions cover JOIN types, the difference between WHERE and HAVING, GROUP BY with aggregates, primary vs unique keys, normalization, indexes, and finding the second highest value in a column. Advanced rounds add window functions, CTEs, execution plans and isolation levels.
Focus on aggregation, joins, filtering, date handling and window functions, then give one short scenario such as month over month revenue change. Data analysts rarely need deep database administration knowledge, so weight query writing and result interpretation over tuning and replication.
Look for correct logic first, then how the candidate handles edge cases (NULLs, ties, duplicates), then readability. A candidate who states assumptions and checks their result is usually stronger than one who writes a fast query and stops.
A typical SQL round runs 30 to 60 minutes: a few concept questions to calibrate, then one or two query tasks. A hands on assessment before the interview can shorten the live round, since basic query skill is already verified.
Beginner questions test vocabulary and basic commands such as SELECT, WHERE and GROUP BY. Advanced questions test performance, concurrency and design: execution plans, indexing tradeoffs, isolation levels, partitioning and replication.
Not on their own. Questions show understanding, but a timed, proctored query task shows ability. Most teams get the clearest signal by combining a short SQL assessment with a focused interview.
Yes. The questions and sample queries here are standard SQL concepts. Practicing them helps, but interviewers usually adapt questions to their own schema, so understanding why a query works matters more than memorizing it.
Asking good SQL interview questions is the first step. Watching a candidate write the query is the second, and it’s the one that tells you whether they’ll be useful in the first month. Book a demo to see how Glider runs SQL assessments with proctoring built in.
A recruiter screens a strong candidate on video, a hiring manager runs a solid technical round, and an offer goes out. On day one, the person who logs in is not the person who interviewed. Nobody on the team did anything careless. The process simply never confirmed who the candidate was. That gap is why […]
Introduction Technical roles are some of the hardest to fill. The process is a landmine of recruitment challenges. HR teams often find themselves under-resourced and struggling to find suitable talent, while engineers waste too much time interviewing candidates who don’t meet the necessary qualifications. Meanwhile, high-quality candidates get frustrated by slow and inefficient hiring processes and […]
What is QA and Testing? Quality Assurance (QA) and testing are integral processes in software development aimed at ensuring the reliability, functionality, and usability of applications. QA involves establishing standards and procedures to monitor and improve the software development lifecycle, focusing on preventing defects and identifying areas for optimization. It encompasses various activities such as […]