10 SQL Interview Mistakes That Cost You the Job (And How to Fix Them)

Most SQL interview failures are not because the candidate does not know SQL. They fail because of how they write it, communicate it, and handle edge cases.

Here are the 10 most common mistakes — and exactly how to fix each one.

Mistake 1: Jumping straight into writing without thinking

The single most common mistake. Interviewers see candidates immediately start typing without restating the problem, identifying the tables they need, or thinking about edge cases.

What interviewers see: someone who writes code impulsively without engineering thinking.

The fix: spend 60 seconds before writing anything:

1. Restate the question in your own words
2. Identify which tables and columns you need
3. State the expected output
4. Mention any edge cases you see

This one habit alone separates average candidates from strong ones.

Mistake 2: Getting NULL handling wrong

NULLs silently break SQL queries. The most common version:

sql
-- Looks correct, returns wrong results:
WHERE referee_id <> 2

This drops all rows where referee_id IS NULL because NULL <> 2 evaluates to NULL, not TRUE.

The fix:

sql
WHERE referee_id <> 2
   OR referee_id IS NULL

Always ask: can this column contain NULLs? If yes, handle them explicitly.

Mistake 3: Confusing COUNT(*) and COUNT(column)

sql
SELECT COUNT(*) FROM orders;          -- counts all rows including NULLs
SELECT COUNT(shipped_at) FROM orders; -- counts only non-NULL shipped_at values

If you want to count how many orders have actually shipped, COUNT(*) gives the wrong answer.

The fix: always think about what you are counting. If the column can be NULL and you only want non-NULL rows, use COUNT(column) not COUNT(*).

Mistake 4: Using WHERE instead of HAVING to filter aggregates

sql
-- This FAILS:
SELECT customer_id, COUNT(*) AS order_count
FROM orders
WHERE COUNT(*) > 5        -- cannot use aggregate in WHERE
GROUP BY customer_id;

-- This WORKS:
SELECT customer_id, COUNT(*) AS order_count
FROM orders
GROUP BY customer_id
HAVING COUNT(*) > 5;

The fix: remember the execution order. WHERE runs before grouping, HAVING runs after. Aggregate functions must go in HAVING.

Mistake 5: Selecting columns not in GROUP BY

sql
-- This FAILS (in standard SQL):
SELECT country, name, COUNT(*) AS total
FROM customers
GROUP BY country;   -- name is not in GROUP BY and not aggregated

MySQL sometimes allows this but picks an arbitrary value — which is worse than an error because it silently produces wrong results.

The fix: every column in SELECT must either be in GROUP BY or inside an aggregate function. If in doubt, add it to GROUP BY.

Mistake 6: Not handling the row inflation from JOINs

sql
-- If a customer has 5 orders, this returns 5 rows per customer
SELECT c.customer_id, c.name, o.order_id
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id;

Candidates are often surprised when their result has more rows than expected. Worse, if you then SUM a column from the customers table without noticing, you double-count.

The fix: before writing any JOIN, state the cardinality: "customers is one-to-many with orders, so I expect multiple rows per customer." This shows you understand the data model.

Mistake 7: Forgetting that NOT IN fails with NULLs

sql
-- This returns ZERO rows if any customer_id in orders is NULL:
SELECT name
FROM customers
WHERE customer_id NOT IN (
  SELECT customer_id FROM orders   -- if ANY value here is NULL, the whole thing fails
);

The fix: use NOT EXISTS instead:

sql
SELECT name
FROM customers c
WHERE NOT EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.customer_id
);

Mistake 8: Writing a working query but not explaining it

An interviewer who hears silence while you type for 5 minutes has no idea if you know what you are doing. Even if the query is perfect, you may fail because you did not communicate.

The fix: narrate as you write:

• "I am joining customers to orders on customer_id"
• "I am using LEFT JOIN because I want to include customers with no orders"
• "I am using HAVING here because this filter applies to the aggregated result"

This turns a code exercise into a conversation and shows your reasoning.

Mistake 9: Using LIKE with a leading wildcard and not flagging the performance cost

sql
WHERE email LIKE '%gmail.com'  -- cannot use index, full table scan

This is correct, but on a million-row table it will be slow.

The fix: write it correctly, then add: "I should mention that LIKE with a leading wildcard cannot use an index. On a large table, we would want to consider a full-text index or storing the domain separately."

Proactively flagging trade-offs makes you look senior even if you cannot fully solve them on the spot.

Mistake 10: Not considering edge cases in the output

You write a query that looks correct, but you did not think about:

• What if the table is empty?
• What if a user has no orders — should they appear with 0 or not appear at all?
• What if two rows are tied for first place?
• What if the date range has no data?

The fix: after writing your query, say out loud: "Let me think about edge cases. If a customer has no orders, they will not appear in this result — is that the intended behaviour?" This shows senior-level thinking.

The pattern behind all 10 mistakes

Every mistake above has the same root cause: writing code without thinking first.

The candidates who pass SQL interviews consistently do these four things:

1. Restate the problem before writing
2. Identify tables, joins, and filters needed
3. Write step by step, narrating as they go
4. Review for NULLs, edge cases, and performance after writing

You do not need to be perfect. Interviewers know SQL is hard under pressure. What separates good candidates is structured thinking — and that is completely learnable.

Practice avoiding these mistakes on TheQueryLab

The best way to avoid these mistakes in a real interview is to practice them in a low-stakes environment first. TheQueryLab's problems are designed around exactly the edge cases and patterns that trip up candidates.

Start with the SQL Interview Preparation Kit — practice writing queries out loud (even to yourself), handling NULLs explicitly, and narrating your reasoning as you go. By the time you are in a real interview, these habits will be automatic.