SQL Mistakes in Interviews

Mistake 1: Not clarifying edge cases first

Most interview questions are worded ambiguously on purpose. "Find the top-selling product" doesn't say what happens if two products tie. "List each customer's most recent order" doesn't say what happens if a customer placed two orders on the same timestamp. Candidates who ask about these cases before writing SQL signal exactly the habit that prevents production bugs — jumping straight to code signals the opposite.

Mistake 2: Assuming NULL behaves like a normal value

NULL breaks intuition in more places than any other single concept: NULL = NULL is not true, NOT IN with a NULL in the list can zero out an entire query, and COUNT(column) silently skips it while COUNT(*) doesn't. An answer that doesn't at least mention NULL as a possibility is missing one of the most commonly tested edge cases in SQL. Full depth in NULL Handling in SQL and the specific subquery failure mode in SQL Subquery Interview Questions.

Mistake 3: JOIN + aggregate without accounting for fan-out

Question: total revenue per customer, joining customers to both orders and a separate reviews table.

-- Mistake: joining to reviews multiplies every order row
-- once per review the customer left
SELECT c.name, SUM(o.total) AS revenue
FROM customers c
JOIN orders o ON o.customer_id = c.id
JOIN reviews r ON r.customer_id = c.id
GROUP BY c.name;

Alice has 2 orders totaling 120 and left 3 reviews. Joining both tables together produces one row per (order, review) pair — 6 rows — and SUM(o.total) adds each order's total once per matching review, inflating 120 into 360. The fix is aggregating each one-to-many relationship independently (in its own subquery or CTE) before joining the pre-aggregated results together. This exact trap is why join fan-out gets its own section in SQL Joins Interview Questions With Answers.

Mistake 4: SELECT * out of habit

Beyond the real-world performance cost covered in Why SQL Queries Are Slow, SELECT * in an interview answer signals that you haven't thought about exactly what the question asked for. Naming the specific columns the question requires reads as more deliberate and is easier for an interviewer to verify against the expected output at a glance.

Mistake 5: Mixing up WHERE and HAVING

Putting a row-level condition in HAVING, or trying to filter on an aggregate in WHERE, is one of the fastest ways to signal a shaky grasp of execution order. WHERE filters rows before grouping; HAVING filters the resulting groups — see Why HAVING Is Used After GROUP BY for the reasoning, and SQL GROUP BY Interview Questions for more of this pattern.

Mistake 6: Not testing your own query against ties

The classic case is finding the "Nth highest" value using OFFSET instead of DENSE_RANK() — it works fine on data with no ties, and fails silently the moment two rows tie for a value. Mentally running your own query against a small example with a deliberate duplicate, before declaring it done, catches this before the interviewer does. Worked through in full in SQL Tricky Interview Questions With Answers.

Mistake 7: Not narrating your reasoning

Writing a correct final query in silence is worse than talking through wrong turns out loud. Narrating "first I'll filter to active rows, then group by customer, then take the average" lets an interviewer catch a misunderstanding of the question before it's too late to redirect you, and demonstrates the same execution-order thinking covered in SQL Execution Order Explained.

Mistake 8: Never mentioning performance

Even when a question only asks for a correct result, briefly flagging that a filtered or joined column would benefit from an index, or noting a query would trigger a full table scan on a large table, shows awareness beyond just getting the right answer — without needing to over-engineer a response to a question that didn't ask for it. See the SQL Optimization Checklist and EXPLAIN Query Plan – Beginner to Advanced for what that awareness looks like in practice.