How Do You Prepare for a SQL Interview?

Drill the building blocks, not the trivia. Almost every SQL interview question is a combination of a small number of patterns, and the patterns are learnable in an afternoon.

CREATE TABLE customers (
  id INTEGER PRIMARY KEY,
  name VARCHAR(120) NOT NULL,
  city VARCHAR(80) NOT NULL
);

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  placed_on TEXT NOT NULL
);

INSERT INTO customers (id, name, city) VALUES
  (1, 'Ada Lovelace', 'London'),
  (2, 'Grace Hopper', 'New York'),
  (3, 'Alan Turing',  'London');

INSERT INTO orders (id, customer_id, amount, placed_on) VALUES
  (1, 1, 120.00, '2026-01-05'),
  (2, 1, 340.50, '2026-01-20'),
  (3, 2,  75.25, '2026-02-03'),
  (4, 3,  90.00, '2026-02-14');

-- Block 1: aggregation and grouping.
SELECT c.city,
       COUNT(o.id) AS order_count,
       ROUND(SUM(o.amount), 2) AS revenue
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.city
ORDER BY revenue DESC;

Three rows come back: London with 2 orders and 210.00, New York with 1 order and 75.25, and no other cities, because every customer in this data has ordered.

The blocks worth drilling are these. Aggregation with GROUP BY and HAVING. The three join types and what each one keeps. Subqueries in the SELECT, WHERE and FROM clauses. Window functions, particularly ROW_NUMBER, LAG and running totals. Set operations. And the data-modifying statements, because a surprising share of SQL interviews ask you to update or delete safely rather than just to select.

For each block, practise until you can write it without looking up the syntax and can say what the row count will be before you run it. That last habit is the thing that separates a candidate who knows SQL from one who has practised SQL. The interviewer is usually watching whether you reason about the data, and being able to predict the output is the clearest possible evidence that you do.

There are four recurring shapes, and they all reward the same behaviour: think out loud.

CREATE TABLE customers (
  id INTEGER PRIMARY KEY,
  name VARCHAR(120) NOT NULL,
  city VARCHAR(80) NOT NULL
);

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  placed_on TEXT NOT NULL
);

INSERT INTO customers (id, name, city) VALUES
  (1, 'Ada Lovelace', 'London'),
  (2, 'Grace Hopper', 'New York'),
  (3, 'Alan Turing',  'London');

INSERT INTO orders (id, customer_id, amount, placed_on) VALUES
  (1, 1, 120.00, '2026-01-05'),
  (2, 1, 340.50, '2026-01-20'),
  (3, 2,  75.25, '2026-02-03'),
  (4, 3,  90.00, '2026-02-14');

-- Shape 1: a business question that needs two tables and a join.
SELECT c.id AS customer_id,
       COUNT(o.id) AS order_count,
       ROUND(SUM(o.amount), 2) AS lifetime_value
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.id
ORDER BY lifetime_value DESC
LIMIT 2;

The four shapes are these. A business question answered with a join and an aggregate — revenue per customer, orders per month. A comparison question — this month against last, this group against the overall average — which wants a window function or a self-join. A finding question — the top N per group, the second highest value, the rows with no match — which wants a ranking function or an anti-join. And a data-modification question — update these rows safely, find the duplicates, explain what this schema enforces — which wants transaction discipline rather than syntax.

How to answer matters as much as what you write. Restate the question in terms of the data before you type anything: what is one row of the output, and which table does it come from? That sentence tells you the grain, and the grain is what most wrong answers get wrong. Then say which join type you are choosing and why — the INNER versus LEFT decision is a judgement call, and saying it out loud shows you know it is one. Then write the query, and say what you expect it to return before you run it.

Two things to avoid. Do not write a query you cannot explain, because the follow-up question will find it. And do not go silent while you think — an interviewer cannot help with a problem they cannot see. Narrating a half-formed idea lets them redirect you before you have written fifty lines of the wrong thing.

Practise by writing, not by reading. The gap between recognising a correct query and producing one under interview conditions is where people fail, and only writing closes it.

Build a small schema and learn it properly — three or four tables with a handful of rows, one of them nullable so you can practise the NULL behaviour, and one with a tie so the ranking functions show their differences. Then write the same question several ways. The second-highest salary is a good exercise: once with a correlated subquery, once with LIMIT and OFFSET, once with a window function, and once with a self-join. Seeing the same answer four ways teaches more than four separate questions.

Practise the questions that produce a discussion rather than a query as well. Why would you use a subquery instead of a join? When is a LEFT JOIN slower than an INNER one? What does a UNIQUE constraint do that an index does not? Those are worth as much as the syntax, because the interviewer is usually checking whether you understand the machinery.

Learn one real engine properly rather than five partially. Know how its type system, its NULL handling and its date functions differ from the others, because the questions about those differences are where the interview becomes a conversation rather than a test. Being able to say "on PostgreSQL that would be a date_trunc, on MySQL a DATE_FORMAT" is a better signal than being able to recite function names you will never use.

Two habits to build. Before you run any query, predict its row count and its shape — the habit that proves you understand grain. And when you get it wrong, work out why rather than re-running it, because the reason you were wrong is exactly what the interview will test.