How to Prepare for a SQL Interview: Rounds, Practice Plan and a 20-Minute Mock

To prepare for a SQL interview, practise a small set of patterns until you can write them without looking anything up: filtering, GROUP BY with HAVING, joins (especially LEFT JOIN), window functions such as DENSE_RANK, and NULL handling. Then practise doing it out loud, on a clock, on a schema you have never seen. Interviewers are usually checking whether you can turn a plain-English question into a correct query and explain your choices. They are not checking whether you have memorised syntax.

I'm Gulab Chand Tejwani. I teach SQL at TechNet Consultancy in Vallabh Vidyanagar, Anand, and online. I run mock rounds like the one below with students before interviews. This post is the plan I give them. It doesn't promise a job offer, because no practice plan can.

What is a SQL interview?

A SQL interview is any hiring step where you are asked to read data, write queries, or reason about queries. The format depends on the company and the role, so it helps to ask the recruiter which one you are getting.

Format	What it looks like	What it mostly tests	How to prepare
Screening call	10 to 30 minutes of spoken questions, sometimes with a short query	Concepts: joins, WHERE vs HAVING, NULLs, primary keys	Explain each concept in two sentences with a tiny example
Live coding	Shared editor or whiteboard; 1 to 3 questions on a small schema	Pattern recognition, speed, and how you handle ties and NULLs	Timed practice; talk while you write
Take-home task	A dataset and a few business questions, hours or days to finish	Clean queries, correct numbers, a short written explanation	Check totals, add comments, state assumptions

Some roles mix these. A data analyst loop might start with a screening call and then move to live coding. Questions for freshers are usually narrower than for experienced candidates, so ask which level the recruiter has in mind. Our SQL interview preparation page lists the topics we cover for each level.

How do I prepare for a SQL interview?

A practical plan, adjusted to the time you have:

1. Check the basics first. SELECT, WHERE, ORDER BY, GROUP BY, HAVING, COUNT, SUM, AVG. If any of these feel shaky, fix them before anything advanced. Why SQL matters for analysts explains where each fits.
2. Learn joins properly. Know INNER vs LEFT, and practise the "find rows with no match" pattern. SQL joins explained with examples is a good drill.
3. Add window functions. ROW_NUMBER, RANK, DENSE_RANK, and a running total cover most interview questions. The mock round below includes a DENSE_RANK question.
4. Practise analysis queries. Monthly totals, top N per group, repeat customers. SQL queries for data analysis has fifteen of these with business questions.
5. Run timed rounds. Set a timer, use a schema you did not write, and talk through your thinking. If you want structured practice, the SQL interview preparation page lists topics and questions. If you are still building fundamentals, our SQL training starts earlier.

A rough weekly rhythm that works for many learners: a few short sessions on one pattern each, one longer timed round at the weekend, and a review of every query you got wrong. Review is where most of the learning happens. There is no magic number of hours. How long you need depends on where you start.

What do interviewers look for in SQL answers?

Beyond a correct result, interviewers tend to notice:

• Clarifying questions. "If two people tie, should both appear?" is a good sign.
• Correct handling of NULLs. AVG ignores NULLs; = NULL never matches.
• Safe date filters. A half-open range (>= start and < next start) keeps working if the column becomes a timestamp.
• A readable query. Aliases, one clause per line, a CTE when it helps.
• Verification. Saying "I'd check this against a hand count on a few rows" shows maturity.

Try a 20-minute mock SQL interview round

Set a timer for 20 minutes. Create the tables, then try each question before you read the answer. Everything here is illustrative data I made up for practice; none of it comes from a real company.

The schema

CREATE TABLE employees (
  emp_id    INT PRIMARY KEY,
  name      TEXT,
  dept      TEXT,
  salary    INT,        -- NULL means "not yet set"
  hire_date DATE
);

INSERT INTO employees VALUES
  (1, 'Asha',   'Sales',   52000, '2023-04-10'),
  (2, 'Bhavin', 'Sales',   45000, '2024-01-15'),
  (3, 'Chirag', 'Sales',   45000, '2024-06-01'),
  (4, 'Dhara',  'Support', 38000, '2022-09-20'),
  (5, 'Esha',   'Support', 41000, '2023-11-05'),
  (6, 'Farhan', 'Finance', 60000, '2021-03-12'),
  (7, 'Gita',   'Finance', NULL,  '2025-02-01');

CREATE TABLE orders (
  order_id   INT PRIMARY KEY,
  emp_id     INT,
  order_date DATE,
  amount     INT,
  status     TEXT
);

INSERT INTO orders VALUES
  (101, 1, '2026-09-05', 12000, 'completed'),
  (102, 1, '2026-10-02',  8000, 'completed'),
  (103, 2, '2026-10-15', 15000, 'completed'),
  (104, 2, '2026-10-20',  5000, 'cancelled'),
  (105, 3, '2026-10-31',  7000, 'completed'),
  (106, 1, '2026-11-01',  9000, 'completed'),
  (107, 5, '2026-10-10',  3000, 'completed');

Question 1 (about 3 minutes): Who in Sales earns more than 40000?

Sort by salary, highest first, then by name.

SELECT name, salary
FROM employees
WHERE dept = 'Sales'
  AND salary > 40000
ORDER BY salary DESC, name;

Expected result:

name	salary
Asha	52000
Bhavin	45000
Chirag	45000

Edge case: the two people with 45000 tie. The second sort key, name, makes the order deterministic. Without it, the database may return them in either order.

Question 2 (about 5 minutes): Which employees completed at least 8000 in orders during October 2026?

Show the total and the number of orders.

SELECT e.name,
       SUM(o.amount) AS october_total,
       COUNT(*)      AS order_count
FROM employees e
JOIN orders o ON o.emp_id = e.emp_id
WHERE o.status = 'completed'
  AND o.order_date >= DATE '2026-10-01'
  AND o.order_date <  DATE '2026-11-01'
GROUP BY e.emp_id, e.name
HAVING SUM(o.amount) >= 8000
ORDER BY october_total DESC;

Expected result:

name	october_total	order_count
Bhavin	15000	1
Asha	8000	1

Edge cases to say out loud:

• Order 104 is cancelled, so it is filtered in WHERE, before grouping.
• Asha also has orders on 5 September and 1 November. The half-open range excludes both. A filter like BETWEEN '2026-10-01' AND '2026-10-31' would work on a DATE column, but would silently drop late-evening orders on the 31st if the column were ever a timestamp.
• Chirag's 7000 and Esha's 3000 fall below the threshold, so HAVING removes them. WHERE cannot do that, because it runs before the sums exist.

Question 3 (about 4 minutes): Which employees have never placed an order?

SELECT e.name, e.dept
FROM employees e
LEFT JOIN orders o ON o.emp_id = e.emp_id
WHERE o.order_id IS NULL
ORDER BY e.name;

Expected result:

name	dept
Dhara	Support
Farhan	Finance
Gita	Finance

Edge cases:

• Test for NULL on a column that is never NULL in real orders, such as the primary key order_id. Testing a nullable column could give wrong answers.
• Do not put o.status = 'completed' in the WHERE clause of this query. For employees with no orders, o.status is NULL, so the row would be dropped and the query would quietly turn into an inner join. If you need a status condition, put it in the ON clause.

Question 4 (about 5 minutes): Show the top two salary levels in each department

If two people share a salary, they get the same rank. Ignore employees whose salary is not set.

WITH ranked AS (
  SELECT name, dept, salary,
         DENSE_RANK() OVER (
           PARTITION BY dept
           ORDER BY salary DESC
         ) AS salary_rank
  FROM employees
  WHERE salary IS NOT NULL
)
SELECT dept, name, salary, salary_rank
FROM ranked
WHERE salary_rank <= 2
ORDER BY dept, salary_rank, name;

Expected result:

dept	name	salary	salary_rank
Finance	Farhan	60000	1
Sales	Asha	52000	1
Sales	Bhavin	45000	2
Sales	Chirag	45000	2
Support	Esha	41000	1
Support	Dhara	38000	2

Edge cases:

• DENSE_RANK keeps both 45000 rows at rank 2. ROW_NUMBER would pick one of them arbitrarily, and RANK would leave a gap after a tie. Say which one you chose and why.
• In PostgreSQL, ORDER BY salary DESC puts NULLs first unless you add NULLS LAST. Filtering them out in the CTE avoids the surprise. Without that filter, Gita would take a ranking slot in Finance, and the results would look wrong.
• You cannot filter on salary_rank in the same SELECT that defines it, which is why the CTE is there.

Question 5 (about 3 minutes): Headcount, salaries on file and average salary by department

SELECT dept,
       COUNT(*)            AS headcount,
       COUNT(salary)       AS with_salary,
       ROUND(AVG(salary))  AS avg_salary
FROM employees
GROUP BY dept
ORDER BY dept;

Expected result:

dept	headcount	with_salary	avg_salary
Finance	2	1	60000
Sales	3	3	47333
Support	2	2	39500

Edge case: COUNT(*) counts rows; COUNT(salary) counts non-NULL values. AVG also ignores NULLs, so Finance averages one salary, not two. If an interviewer asks "is that the right average for the department?", the honest answer is "it depends on whether a missing salary means zero or unknown."

Score yourself honestly

After the 20 minutes, note which questions you finished, which you finished only after looking something up, and which you could not finish. Then repeat the weak ones the next day on the same tables. Re-running the same schema teaches you faster than switching to new data every time.

What are common SQL interview mistakes?

• Starting to type before restating the question.
• Using WHERE where HAVING is needed, or the reverse.
• Forgetting that a LEFT JOIN becomes an inner join when you filter the right table in WHERE.
• Using = or <> with NULL instead of IS NULL or IS NOT NULL.
• Picking ROW_NUMBER for a top-N question that needs ties.
• Not checking a result against a manual count.

FAQ

How long does it take to prepare for a SQL interview?

It depends on where you start. If you already write basic queries, a few weeks of regular practice on joins, grouping and window functions is a reasonable plan. If SQL is new, build the fundamentals first and add interview practice after.

What SQL topics are asked most in interviews?

Filtering, GROUP BY and HAVING, joins (including LEFT JOIN for missing rows), NULL behaviour, ranking with window functions, and date filtering. Take-home tasks add readable queries and written explanations.

Do I need to memorise syntax?

No. Know the core patterns well enough to write them from memory, and say plainly when a function name differs between PostgreSQL, MySQL and SQL Server. Clear thinking matters more than exact syntax.

Which SQL dialect should I practise?

Ask the recruiter if you can. If you cannot find out, PostgreSQL is a sensible choice, since it is free and its syntax is close to standard SQL. The mock round above is PostgreSQL-compatible.

Is a live coding SQL round harder than a take-home?

They are different. Live coding rewards speed and talking through your reasoning. Take-homes reward care: correct totals, clean queries and clear assumptions. Practise both.

Can practice guarantee I will get the job?

No. Practice improves your odds of writing correct queries under pressure. Hiring decisions depend on many other factors.

If you want guided practice with feedback, see our SQL interview preparation page. If you are still building foundations, start with SQL training. You can learn in Vallabh Vidyanagar, Anand, or online.