Here's something most SQL interview candidates don't know: an interviewer can watch you write a perfectly correct query and still decide not to hire you.
And they can watch someone write a query with a small bug and decide to make an offer.
This sounds contradictory until you understand what's actually being evaluated. SQL interviews aren't a unit test. They're a signal about how you'll behave on the job — debugging production queries at 9pm, reviewing a teammate's PR, designing a schema that three other teams will depend on.
Here's what senior interviewers are actually scoring.
1. Did You Ask a Clarifying Question Before Writing?
The first thing a strong candidate does is not open a code editor. They ask a question.
"Before I write this — are there NULL values in this column I should account for?"
"Is this table append-only, or can rows be updated in place?"
"When you say 'most recent', do you mean by inserted_at, or by a business date column?"
This matters for two reasons. First, clarifying questions surface assumptions that would make your query wrong. Second — and this is what interviewers are actually watching for — it's exactly what a senior engineer does in the real world before touching production data.
A candidate who immediately starts typing is showing that they optimise for looking busy over getting the right answer. That's a meaningful signal about how they'll behave on a team.
What to do: Before writing a single line, ask one to two clarifying questions. Even if you're pretty sure of the answer. It shows you know what questions to ask, which is itself a skill.
2. Do You Narrate the Edge Cases, Not Just the Happy Path?
Here's a common SQL interview moment: the candidate writes a clean query, it looks correct, the interviewer says "looks good — any edge cases to consider?"
The weak answer: "I think it handles everything."
The strong answer: "A few things. If order_date is NULL, this row gets excluded from the window — I'd want to confirm that's intentional. If two orders share the same timestamp, ROW_NUMBER() will arbitrarily break the tie; if we care about consistency I'd add a secondary sort on order_id. And if the customers table has rows that don't join to orders, they'll be dropped here — I've used an INNER JOIN, so I'd want to confirm we don't want those customers appearing with NULLs."
The second answer doesn't require the query to be different. It's the same SQL. But it demonstrates that you've thought about the data, not just the syntax.
Interviewers are hiring someone who will catch data quality issues before they become incidents. That instinct is what they're looking for — and it can only be shown through narration.
What to do: When you finish writing, do a brief audit out loud. Mention NULLs, mention ties, mention what happens at the join boundary, mention empty sets. You don't have to fix all of them — just show you see them.
3. Can You Explain Why, Not Just What?
"Why did you use DENSE_RANK() here instead of RANK()?"
"Why a CTE instead of a subquery?"
"Why LEFT JOIN rather than INNER JOIN?"
Every design decision in SQL is a choice with trade-offs. Interviewers ask "why" questions deliberately — not to trip you up, but to find out if you made an intentional decision or just wrote what came to mind first.
The wrong answer is "I just prefer it that way" or "I always use CTEs."
The right answer connects the choice to the problem:
"I used
DENSE_RANK()because there are tied revenue values in this dataset and I don't want gaps in the ranking. If I usedRANK(), two users tied for 2nd would both get rank 2, and the next user would get rank 4 — which would look wrong to business users reading a leaderboard."
This shows you understand the semantics of the function, not just the syntax. That's the difference between someone who Googled window functions last week and someone who's used them in production.
What to do: After writing each significant piece, add a one-sentence justification unprompted. Don't wait to be asked.
4. Do You Know Where Your Query Gets Slow?
SQL correctness is table stakes at senior level. Performance awareness is what separates mid from senior.
You don't need to give a query plan — but you should be able to say:
"This window function will trigger a sort on the entire events table. If this is running on billions of rows in production, I'd want to check whether there's a partition we can push down before the window."
"This correlated subquery runs once per row in the outer query — at scale, I'd rewrite this as a JOIN or a window function to avoid the N+1 scan."
"The DISTINCT here is covering up a join that's producing duplicates. I'd rather fix the join cardinality than mask it — DISTINCT hides bugs."
You're not expected to optimise every query on the spot. You are expected to flag the risk.
Interviewers hear "this might be slow on large tables" and they hear: this person has debugged slow queries before and knows what to look for. That's real signal.
What to do: For any query involving joins on large tables, window functions on unsorted data, or subqueries in WHERE/SELECT, briefly note the performance consideration. Even if you don't fix it.
5. How Do You Handle Being Wrong?
This is the one candidates think about least — because they're focused on being right.
But interviewers watch what happens when they point out an issue.
Defensive response (bad signal): "Oh, I didn't think that was part of the requirements." / "I thought you said NULLs weren't possible."
Collaborative response (strong signal): "Good catch — I'd need to handle the NULL case here. I'd add a COALESCE(date_col, '1970-01-01') or filter them out upstream, depending on what we want them to represent."
The best candidates treat interviewer feedback as information, not judgement. They update their answer, explain their reasoning, and move on.
This matters because it mirrors what senior engineers do in code review. A candidate who gets defensive about a mistake is showing exactly how they'll respond when someone reviews their dbt model and finds an issue.
What to do: If the interviewer points something out, thank them, explain what you missed and why, and fix it. Don't backtrack awkwardly or over-explain.
6. Did You Choose the Right Tool for the Problem?
Interviewers sometimes present problems that have multiple valid approaches, and watch which one you reach for.
If you immediately write a GROUP BY query when a window function is cleaner, they notice. If you use a self-join when LAG() would do, they notice. Not because the answer is wrong — but because it suggests you have a limited toolkit and you reach for familiar tools even when better ones exist.
Conversely: reaching for a window function on a simple aggregation problem where GROUP BY is perfectly appropriate shows over-engineering instincts. That's also a signal — and not a positive one.
The strongest candidates briefly note the alternatives: "I could do this with a subquery, but a window function is cleaner here and avoids the extra scan." Then pick the right one.
What to do: For any problem with multiple valid approaches, name the alternatives you considered and explain why you picked this one. It takes 10 seconds and shows genuine depth.
What Interviewers Write Down
When a senior engineer debrief after a SQL interview, they're not writing "query was correct" or "query had a bug." They're writing:
- "Asked great clarifying questions upfront — knew what assumptions to surface"
- "Didn't mention NULL handling at all — would be a problem on real data"
- "Explained trade-offs between approaches without being asked"
- "Got defensive when I pointed out the join issue — red flag"
- "Flagged the performance risk on the window function without me prompting"
The query is evidence. These observations are the verdict.
The Practice Implication
Most SQL practice focuses on "get the right answer." That's necessary but not sufficient.
To practise the dimensions that actually matter, you need to:
- Write out your answer and then audit it for edge cases before "submitting"
- Practise explaining your choices out loud, not just in your head
- Get feedback on what you missed, not just whether the query ran
A rubric-based approach — where you're scored on "did you handle NULLs?", "did you explain the trade-off?", "did you flag the performance risk?" — trains the instincts that interviewers are actually measuring.
That's exactly how the scoring works on polydomainai. Not correct/wrong, but a breakdown of which criteria your answer hit — so you know precisely where to improve before the real interview.