SQL Interview Questions to Assess Database Skills (2026)

Almost every backend, data, and full-stack role still runs on a relational database, which is why SQL interview questions remain one of the most reliable ways to separate engineers who truly understand data from those who only copy queries. The hard part is not finding questions; it is asking the right ones in the right order and knowing what a strong answer actually sounds like. This guide gives you 40 ready-to-use SQL interview questions with model answers and concrete scoring guidance, so every candidate gets the same fair, structured technical screen.

TL;DR: Use these 40 SQL interview questions, grouped from fundamentals to advanced topics, to assess real database skill instead of memorized syntax. Each comes with a model answer and what a strong response should cover, and the whole set imports into Intervy as a ready-to-run interview.

---

How To Use These SQL Interview Questions

A good database screen is not a trivia quiz. The goal is to watch how a candidate reasons about data, correctness, and performance, not whether they remember an exact function name. Mix difficulty levels so you learn where someone's depth runs out.

Tip: Start easy to build rapport, then escalate. The moment a candidate's confidence outpaces their accuracy is the most informative signal in the whole interview.

What to look for as you move through the set:

• Correctness first. Does the query return the right rows, including edge cases like NULLs and ties?
• Reasoning out loud. Strong candidates narrate trade-offs ("a join is cheaper than this correlated subquery") rather than reciting answers.
• Performance awareness. Senior candidates instinctively consider indexes, row counts, and execution plans.
• Honesty about limits. "I'd reach for the docs on the exact PIVOT syntax" beats a confident wrong answer.

A balanced screen pulls a few questions from each difficulty tier. This set is roughly 30% easy, 40% medium, and 30% hard, so you can assemble a 45-minute interview without over-indexing on memorization.

---

SQL Interview Questions: Fundamentals, Joins, And Aggregation

This is where you confirm a candidate can actually write and reason about everyday queries. These SQL interview questions cover filtering, joins, and grouping, the bread and butter of any data role.

Start with a classic that separates people who memorize from people who understand the query lifecycle: the difference between WHERE and HAVING.

SELECT department_id, COUNT(*) AS headcount
FROM employees
WHERE active = true        -- filters rows first
GROUP BY department_id
HAVING COUNT(*) > 5;       -- filters groups after aggregation

• What a strong answer covers. WHERE filters individual rows before grouping; HAVING filters groups after aggregation and can reference aggregate functions. Bonus points for naming the logical order: FROM then WHERE then GROUP BY then HAVING then SELECT then ORDER BY.

Joins are where many candidates quietly stumble. A favorite trap is asking why a LEFT JOIN can silently behave like an INNER JOIN.

-- Bug: drops customers with no 2026 orders
SELECT c.*, o.id
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.created_at >= '2026-01-01';

-- Correct: the predicate belongs in ON
SELECT c.*, o.id
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.id AND o.created_at >= '2026-01-01';

Key takeaway: A predicate on the outer-joined table placed in WHERE removes the NULL-padded rows and converts a LEFT JOIN into an inner join. Strong candidates spot this instantly and move the condition into ON.

For aggregation, ask how COUNT(*), COUNT(column), and COUNT(DISTINCT column) differ. The discriminating detail is NULL handling: COUNT(*) counts every row, COUNT(column) ignores NULLs, and COUNT(DISTINCT column) returns unique non-NULL values. If a candidate glosses over NULLs here, they will likely produce subtle bugs in real reports.

---

Advanced SQL Interview Questions: Indexing, CTEs, And Transactions

For senior and staff-level candidates, the advanced SQL interview questions are where you find real depth. These probe performance, set-based thinking, and concurrency, the topics that decide whether a system survives production load.

Window functions are the clearest line between intermediate and advanced. A great prompt is "get the top N rows per group," which has no clean answer without them.

SELECT *
FROM (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY category_id ORDER BY price DESC
    ) AS rn
  FROM products
) ranked
WHERE rn <= 3;

• What a strong answer covers. Numbering rows within each partition, then filtering. Extra credit for knowing when to swap row_number() for rank() or dense_rank() to include ties at the boundary.
• A common follow-up. Ask the difference between PARTITION BY and GROUP BY: the former computes per-group aggregates while keeping every detail row, the latter collapses rows into one per group.

On performance, "why might an index not be used even when it exists?" reveals whether someone has actually debugged slow queries.

Tip: Listen for the word "sargable." Candidates who mention functions on the column, implicit type casts, low selectivity, and leading wildcards have clearly tuned real workloads, not just read about indexes.

Concurrency is the final frontier. Ask about isolation levels and deadlocks, then watch whether the candidate connects theory to practice.

-- Lock rows up front in a deterministic order to avoid deadlocks
SELECT * FROM accounts WHERE id IN (1, 2) ORDER BY id FOR UPDATE;

• Deadlock prevention. Consistent lock ordering, short transactions, and treating the aborted victim as retryable.
• Isolation trade-off. Higher isolation prevents more anomalies but lowers concurrency and raises serialization conflicts.

---

Data Modeling And Normalization Questions

Schema design questions surface long-term thinking. A candidate who models data well saves a team months of migrations later.

The anchor question is normalization: what problems do the normal forms solve? A strong answer names the three anomalies and the trade-off against read-time joins.

• Update anomaly. The same fact stored in many rows must be changed everywhere.
• Insert anomaly. You cannot record one fact without supplying another unrelated one.
• Delete anomaly. Removing a row unintentionally loses unrelated data.

Then test practical modeling with the many-to-many relationship, which every real schema eventually needs.

CREATE TABLE student_courses (
  student_id  BIGINT REFERENCES students(id),
  course_id   BIGINT REFERENCES courses(id),
  enrolled_at TIMESTAMPTZ DEFAULT NOW(),
  PRIMARY KEY (student_id, course_id)
);

Key takeaway: The junction table with a composite primary key, optionally carrying its own attributes like enrolled_at, is the canonical answer. Candidates who reach for an array column or comma-separated string instead are a flag for junior modeling instincts.

Close the section by asking when they would deliberately denormalize. The best answers frame it as a conscious trade of write complexity for read speed on hot paths, with a plan to keep the redundant copies consistent.

---

Run Structured SQL Interviews In Intervy

Great questions are only half the job. To compare candidates fairly, every interviewer needs to ask the same questions and score them the same way. That is exactly what a structured interview tool is for, and it is where a dedicated technical interview platform beats a shared doc.

Here is how this set maps onto Intervy:

• One reusable question bank. Store every question with a Markdown body, syntax-highlighted code blocks, and a reference answer, organized by color-coded category, difficulty, and tags.
• Reusable interview templates. Build a plan once, add questions from the bank, drag-and-drop to reorder, duplicate it for variants, and filter by category, so SQL screens stay consistent across the team.
• Keyboard-first live scoring. During the interview, see the question, rate the answer on a 1 to 5 scale from Strong No to Strong Yes, and capture an auto-saving comment, all without leaving the keyboard.

Tip: Press a number key to score and an arrow key to advance. Keeping your hands off the mouse means more eye contact with the candidate and faster, more honest notes.

After the session, the interview scoring tool turns ratings into color-coded score cards (green, yellow, red) that summarize each question's rating and comments at a glance, so a hiring panel can compare candidates in minutes rather than reconstructing scattered notes. Core interview management is free, and every account starts with 300 free AI credits if you want AI-drafted interview summaries on top.

For roles that go beyond databases, pair this set with our backend developer interview questions and Python interview questions to build a complete, structured technical screen. You can manage all of it from Intervy.

---

Getting Started

You do not have to copy these questions one by one. The fastest path is to import the whole set and start customizing.

• Import in seconds. Load the full bank, pre-categorized and tagged by difficulty.
• Trim to fit. Build a template scoped to the role, whether that is a 30-minute screen or a deep staff-level loop.
• Score consistently. Run the live interview and let the score cards do the comparison.

Key takeaway: A structured, repeatable SQL screen is the single highest-leverage change most teams can make to hire better engineers, and it costs nothing to start.

All 40 questions are also available as a ready-to-import set in Intervy. Head to the Export / Import page, select "SQL Interview" from the Sample Interview Data dropdown, and click Load — organized by category, tagged by difficulty, and ready to drop into your next interview template.