Interview Questions That Actually Reveal SQL Skill

Good SQL Server interview questions reveal how someone reasons when the answer is not obvious. Give the candidate a small problem, then listen to the questions asked before the query appears.

Ask What the Result Should Mean

Start with a task that has more than one reasonable interpretation. Ask for each customer’s latest order. Then wait to hear whether ties, customers without orders, and time zones need clarification.

A candidate who asks about the business rule is not avoiding SQL. Those details determine whether the answer is correct. Memorizing ROW_NUMBER does not settle what latest means.

WITH Orders AS
(
    SELECT * FROM (VALUES
      (1, 101, CONVERT(date, '20260101', 112)),
      (1, 102, CONVERT(date, '20260101', 112)),
      (2, 103, CONVERT(date, '20260102', 112))
    ) AS v(CustomerId, OrderId, OrderDate)
)
SELECT CustomerId, OrderId, OrderDate,
       ROW_NUMBER() OVER
       (PARTITION BY CustomerId ORDER BY OrderDate DESC, OrderId DESC) AS rn
FROM Orders;

Ask the candidate to explain the tie-breaker rather than merely filter rn to one. Would the business accept the greater identifier as the winner? A confident answer should still acknowledge that assumption.

Make Missing Data Part of the Problem

NULL questions are useful when they test a real reporting mistake. Ask why a count differs from the number of rows. Then ask how a missing amount should affect the result.

WITH Amounts AS
(
    SELECT Amount FROM (VALUES (10), (NULL), (20)) AS v(Amount)
)
SELECT COUNT(*) AS row_count, COUNT(Amount) AS known_amount_count,
       SUM(Amount) AS known_amount_total
FROM Amounts;

The candidate should distinguish missing information from a known zero. Replacing every NULL with zero is a business choice, not automatic cleanup. Ask for an example where that replacement would mislead a reader.

Follow with a LEFT JOIN question if the role involves reporting. A filter on the optional table can change which rows survive. Let the candidate draw the intermediate rows on paper.

Offer a Slow Query Without Offering a Diagnosis

Say that an application search became slow this morning. Do not tell the candidate that an index is missing. Ask what evidence would be collected before making a change.

SELECT session_id, status, command, wait_type,
       blocking_session_id, cpu_time, total_elapsed_time
FROM sys.dm_exec_requests
WHERE session_id <> @@SPID;

Strong answers separate blocking, resource pressure, plan changes, and changed inputs. They ask whether every request is affected and what changed recently. They also recognize that one snapshot can miss the problem.

Do not require a memorized DMV column list unless that is genuinely the job. Let candidates consult documentation after explaining the approach. You are hiring judgment, not an offline autocomplete feature.

Ask How a Change Reaches Production

Give the candidate a proposed index and ask what happens next. Useful answers discuss write overhead, storage, representative tests, and a reversal plan. The best response depends on the workload and available maintenance window.

For a DBA role, ask how a successful backup becomes a demonstrated recovery capability. Look for a restore to another location, integrity checks, and application validation. A green backup job alone does not answer the recovery question.

SELECT TOP (10) database_name, type,
       backup_start_date, backup_finish_date, is_copy_only
FROM msdb.dbo.backupset
ORDER BY backup_finish_date DESC;

Ask what this history proves and what it cannot prove. It records backup operations known to this instance. It does not establish that the media remains available or that the application can use a restored database.

Score the Reasoning Consistently

Use the same core scenario for candidates applying to the same role. Record whether requirements were clarified, assumptions were stated, and proposed checks could distinguish likely causes. That is more useful than a vague impression of confidence.

Separate syntax fluency from problem-solving depth in your notes. A small syntax mistake can be corrected quickly. An unexamined decision to kill sessions or change production settings deserves a different discussion.

Leave space for the candidate to revise an answer after receiving new evidence. Real troubleshooting includes changing your mind. Reward a clear correction instead of treating the first guess as a permanent verdict.

Listen to the Questions Coming Back

Candidates should ask about workload size, availability expectations, access, and the team’s change process. Those questions show how the role will be approached. They also help both sides decide whether expectations are realistic.

End with a short explanation of an unfamiliar result rather than another trivia round. Ask the candidate to describe the next safe experiment. You learn more from that conversation than from the maximum length of a type nobody uses.

A technical interview is not a memory contest, it is a sample of working judgment.

This post was rewritten from scratch in September 2026. The original, published on 2011-11-03, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.