SQL and data interview help
Data interviews are two rounds wearing one name. The first half is SQL you either recall or you do not — window functions, self-joins, the difference between a filter in WHERE and the same condition in a LEFT JOIN's ON clause. The second half is a metrics conversation where the query was never the point. CueNova covers both, which matters because candidates usually prepare only for the first.
The SQL that actually appears
Data interviews draw from a small and stable pool. These five account for most of what gets asked.
Window functions
ROW_NUMBER, RANK and DENSE_RANK for top-N-per-group; LAG and LEAD for period-over-period. The single most common technical filter in data interviews.
Join semantics under NULL
Why a condition in WHERE silently turns a LEFT JOIN into an INNER JOIN. Asked constantly because it separates people who have debugged a query from people who have read about one.
Aggregation and grain
GROUP BY with HAVING, and knowing what one row represents after a join. Fan-out from a one-to-many join is the classic wrong answer.
Date and cohort logic
Retention curves, rolling windows, month-over-month. Off-by-one on inclusive date ranges is the standard trap.
Deduplication
Finding and removing duplicates on a composite key, usually with a window function rather than DISTINCT.
The half nobody prepares for
After the query comes the conversation: "daily active users dropped eight percent last Tuesday — what happened?" There is no SQL answer. The interviewer is testing whether you segment before you speculate, whether you check instrumentation before you blame users, and whether you can define a metric precisely enough to argue about it.
The strong pattern is always the same. Confirm the measurement is real before explaining it — a logging change or a failed pipeline explains more sudden drops than user behaviour ever does. Then cut by platform, region, version and new-versus-returning until the drop localises. Then, and only then, form a hypothesis.
Metric definition questions work the same way. "How would you measure the success of this feature" is asking for a definition tight enough to be gamed and for you to notice how it would be gamed.
In the round
Say the grain out loud
"One row per user per day" before writing anything. It catches half of all fan-out errors before they happen.
Narrate the query as you build it
CTE by CTE. A silent candidate producing a correct query scores below a talking candidate producing a nearly correct one.
Check instrumentation first on any drop question
It is both the right instinct and the answer interviewers are listening for.
Name the gaming risk in any metric you propose
Defining a metric and immediately identifying how it could be gamed is the senior-sounding move in this round.
Frequently asked questions
- Does it handle dialect differences?
- The core of these rounds is standard SQL that carries across PostgreSQL, MySQL, Snowflake and BigQuery. Where a function genuinely differs — date arithmetic being the usual case — it is worth naming your dialect at the start of the round, which interviewers take as a good sign anyway.
- Does it help with the case-style metrics questions?
- Yes, and that half is usually the differentiator. Segmentation frameworks for drop investigations, metric definitions, and the trade-offs in choosing one definition over another.
- What if the question is on a shared screen?
- Capture reads it off your screen. Data rounds often present a schema diagram or a table sample visually rather than reading it aloud.
Try CueNova before it matters
Creating an account is free and needs no payment method. Set up your resume, run one practice round, and confirm your audio and screen-share behaviour on your own machine.