How data science SQL interviews work
The SQL round of a data science interview usually gives you 30 to 60 minutes and one to three problems in a shared editor, often with the choice of SQL or pandas. The guides we read agree that it rewards the right grain, joins that do not duplicate rows and edge cases said out loud (NULLs, ties, duplicates, empty input) far more than dialect trivia. Window functions and retention or cohort queries are the themes reported most.
Key points
- Say what one row of your result is before you write the query. A wrong grain is the most common way a query that runs is still wrong.
- Before every join, ask whether it can multiply rows. Join fan-out quietly inflates counts and sums.
- Decide how ties and NULLs count, and say it. RANK, DENSE_RANK and ROW_NUMBER give different answers on ties.
- Test edge cases before you say you are done, even when the sample data looks clean.
- Dialect matters little. Naming the one you are writing at the start is enough.
Where the SQL round sits in the loop
A product or analytics data scientist loop is usually built from a few distinct rounds. The SQL round is the most mechanical of them, which is why careless mistakes there cost so much.
| Round | Typical time | What happens |
|---|---|---|
| SQL and pandas | 30 to 60 min | One to three problems in a shared editor: write the query, explain it, test it. |
| Statistics and probability | Varies | Hypothesis tests, confidence intervals, power, and what the numbers do and do not mean. |
| Product case or metrics | About 45 min | Define a metric with guardrails, design an experiment or explain why a metric moved. |
| A/B testing | 30 to 60 min | Sometimes its own round, sometimes part of the case: unit, sample size, duration and pitfalls. |
| Behavioral | Varies | Stakeholders, ambiguity, impact. |
What interviewers look for
No company publishes its SQL rubric. The guides describe the same few signals:
- The right grain: the result has one row per the thing the question asks about, and you can say what that is.
- Joins that are correct for the data: the right join type, and no rows duplicated by a one-to-many join.
- NULLs and ties handled on purpose: an anti-join that survives NULLs, a ranking function chosen for its tie behavior.
- Testing: edge cases checked before you call it done, not after the interviewer finds them.
- Assumptions said out loud as you go, so the interviewer can follow and correct you early.
The query patterns that come up most
- Window functions: ranking within groups, running totals, period-over-period change.
- Self joins for retention: users active in one period and again in a later one.
- Funnels and conversion timing: how many users reach each step, and how long it takes.
- Sessionization and gaps and islands: grouping events by inactivity or by unbroken streaks.
- Cohorts: grouping users by when they started and following them over time.
- Anti-joins and deduplication: rows with no match, and keeping one row per key.
The mistakes guides report most
- A result at the wrong grain, or a one-to-many join that silently duplicates rows.
- NULLs dropped without noticing, for example by a NOT IN against a column that contains NULL.
- The wrong ranking function for ties.
- Saying “done” before testing edge cases.
- Precise numbers with no stated assumptions.
How the interviewer behaves
Expect questions about duplicates or NULLs even when the sample data looks clean: the interviewer wants to know whether your query would survive real data, not whether it passes the example. You are expected to test edge cases before declaring the query finished, and to walk through why a result looks the way it does.
The sources disagree only on small things, such as whether to name your dialect at the start. They agree that dialect details matter little next to the logic.
How the bar changes with level
Sources on levels are thin for SQL rounds. What they report is that the bar for the query itself barely moves: correct, with the edge cases handled. Senior candidates are also expected to judge scale and data quality, such as what happens on a far larger table or when the data has duplicates it should not have. The larger level differences in a data science loop sit in the case and experimentation rounds.
After the SQL round: the case round
The case round is a different conversation: clarify the decision the analysis serves, define one primary metric with a precise definition and two or three guardrails, then design the experiment or work out why a metric moved. The mistake reported most is jumping to a test statistic before the metric and the design are settled.
Go deeper on this round
Practise the round out loud
Mockich’s SQL round is the data science coding round: 45 min, two problems at regular and one deeper at lead, in SQL or pandas. Where a question has tables, your query runs on them and Vera reads the result, asks about ties, NULLs and joins, and gives at most three small nudges, never the answer. The report scores problem solving, code quality, complexity, testing and communication (plus production thinking at lead) and quotes what you said.
Sources
We read these public guides on 2026-10-30 (sources 4 to 6 through search excerpts only) and summarised where they agree, in our own words. They report typical practice; no company publishes how it scores SQL rounds, sources on SQL rounds are thinner than on case rounds, and formats differ between companies.
- [1] PracHub, The Data Science Case Study Interview: a 4-step framework
- [2] PracHub, Product metrics, guardrails and retention
- [3] bookdown.org, A/B Testing (Product Data Science Interview)
- [4] KDnuggets, Crack SQL interviews
- [5] HackerNoon, Stop grinding LeetCode SQL, do this instead
- [6] Interview Kickstart, Senior data scientist interview process