20 SQL Mistakes Freshers Make in Interviews
Codevity Admin · 10/25/2026
Step 24 of 25 · SQL Interview Preparation for Beginners · Stage 6: Interview readiness
Codevity Admin · 10/25/2026
Interviewers see the same mistakes again and again. Each one below is paired with the fix, so you can avoid it. They are grouped by topic, and every group links to the article that explains the idea in depth.
1. Filtering an aggregate with WHERE. WHERE COUNT(*) > 5 is invalid, because WHERE runs before grouping. Put aggregate conditions in HAVING.
2. Comparing with = NULL. WHERE salary = NULL is never true. Write WHERE salary IS NULL. (A comparison with NULL is UNKNOWN, and WHERE keeps only TRUE.)
3. Falling into the NOT IN trap. If the subquery returns even one NULL, NOT IN returns no rows at all. Use NOT EXISTS, or filter the NULLs out of the subquery.
4. Treating COUNT(*) and COUNT(column) as the same. The first counts rows. The second counts only rows where the column is not NULL.
5. Using DISTINCT to hide a join bug. If a join multiplies rows, adding DISTINCT masks the logic error and costs time and memory. Find out why the rows are duplicated.
6. Filtering the right table of a LEFT JOIN in WHERE. WHERE o.status = 'paid' removes the rows with no match and quietly turns the query into an inner join. Move the condition into the ON clause.
7. Writing an accidental Cartesian product. A missing or incomplete join condition pairs every row with every row. Always write the ON clause and check the row count.
8. Skipping table aliases. In multi-table queries, e.name and d.name make it obvious which table a column comes from. Unqualified column names break the day someone adds a column.
9. Using UNION when UNION ALL is enough. UNION removes duplicates, which takes extra work. If duplicates are impossible or acceptable, use UNION ALL.
10. Mixing up ROW_NUMBER, RANK and DENSE_RANK. Be ready to explain ties: ROW_NUMBER never repeats, RANK repeats and leaves gaps, DENSE_RANK repeats without gaps. See window functions.
11. Assuming a table has an order without ORDER BY. Tables are unordered sets. Without ORDER BY, the order of the result is not guaranteed, even if it looks consistent today.
12. Thinking ISNULL and COALESCE are identical. ISNULL is T-SQL only, takes two arguments and returns the first argument's data type. COALESCE is ANSI standard, takes any number of arguments and follows data type precedence.
13. Writing predicates that cannot use an index. WHERE YEAR(order_date) = 2026 wraps the column in a function and forces a scan. Compare the bare column to a range instead. See indexes and SARGability.
14. Confusing a primary key with a clustered index. A primary key is a logical constraint. In SQL Server it is implemented with a clustered index by default, but they are different things.
15. Believing every index improves performance. Each index slows , and and takes space. Index what you query on, not everything.
16. Confusing and . is not "unlogged" (it is minimally logged), it resets the identity counter, and it cannot run on a table referenced by a foreign key. See SQL fundamentals.
17. Mishandling the time part of dates. misses orders placed on that day after midnight. Use . See filter by date range.
18. Running or without a safety net. Run the matching first, wrap the change in a transaction, and check the row count. See safe update with a transaction.
19. Expecting identity values back after a rollback. They are consumed and not reused, so gaps in an identity column are normal.
20. Writing code before asking questions. Ask whether columns can be , whether duplicates exist, and how ties should be broken. Two clarifying questions beat five minutes of rewriting.
Pick the five mistakes you recognise yourself in, write a short query that shows each one going wrong, and then fix it. After that, work through the top 50 interview questions.
INSERTUPDATEDELETEDELETETRUNCATETRUNCATEWHERE order_date <= '20261025'>= start AND < next dayUPDATEDELETESELECTNULL