Data analyst interviews test three separate skills that rarely sit in the same person: getting the data out, being right about what it means, and explaining it to someone who will not read a chart. Expect questions from all three.
Last reviewed September 2026
Data analyst interviews test SQL, statistics and communication. Expect joins and window functions, a question about investigating a metric that moved, and at least one request to explain something technical in plain language. The most common failure is explaining a p-value incorrectly, which interviewers listen for specifically.
The single most common SQL question, and a surprising number of candidates get the edge case wrong.
State both, then say what happens to unmatched rows, which is the part that actually matters in practice.
An inner join keeps only rows matching in both tables. A left join keeps every row from the left table, filling nulls where there is no match. It matters when you are counting: an inner join silently drops customers with no orders, so your average looks higher than it is.
Tests whether you reach for GROUP BY and HAVING naturally.
Give the query, then say what you would do about them, because finding them is only half the job.
Group by the columns that should be unique and filter with HAVING COUNT(*) greater than one. Before deleting anything I would check whether they are truly identical or differ in a timestamp, because that changes which one you keep.
The most realistic question in the set. They want a method, not a guess.
Check the data before you check the business. Most overnight drops are broken pipelines, not customer behaviour.
First, is it real? Check whether the pipeline ran and whether tracking changed. If the data is sound, segment it: by platform, region, new against returning. A drop concentrated in one segment is a bug, a drop spread evenly is usually external.
Tests understanding and communication at once, and most people fail the second half.
Avoid the textbook wording. If you say "probability the null hypothesis is true" you have got it wrong, and interviewers listen for exactly that.
It is how surprised we should be by this result if nothing were really going on. A small p-value means this would rarely happen by chance alone, so the effect is probably real. It does not tell us how big the effect is, which is usually the thing people actually want.
Sounds basic, but they want to hear you apply it, not define it.
Define it in one line, then give an example from actual work where you had to push back.
Two things moving together does not mean one causes the other. We once saw users who used a feature retain better, and the team wanted to push everyone into it. But heavy users found the feature, not the other way round. We ran a proper test and the effect was much smaller.
Checks whether you think about the audience or just the data.
Tie the chart to the question being asked, not to the data type.
It depends on the question. Comparison over time is a line. Comparing categories is a bar, sorted, because unsorted bars make people hunt. I avoid pie charts beyond about three slices, since nobody can compare angles accurately.
Tests whether you have a spine and whether you have tact. They want both.
Give them the number, and give them the context. Refusing outright rarely works and makes you look difficult.
I give them what they asked for, and next to it the version I think is more honest, with one line on why they differ. Then it is their call. Withholding it just means they get it from someone with less context.
Separates people who write basic SQL from people who write efficient SQL.
Explain what it does differently from GROUP BY, then a use case.
It calculates across a set of rows while keeping every row, unlike GROUP BY which collapses them. I use it for running totals and for ranking within a group, like each customer first order, which is painful without it.
Everyone says "it depends". They want to hear what it depends on.
Say that the reason it is missing decides the treatment, and give the cases.
It depends why it is missing. Missing at random, I might impute with a median. Missing because a form field was added later, imputing invents history, so I limit the analysis to the period after. The dangerous case is missing because something failed, where a null means something.
Analysts who never change anything are reporting, not analysing.
Name the decision, the evidence, and what happened next. The follow-through is the point.
We were about to build a feature for a segment we assumed was growing. I looked properly and the growth was one large customer, not a trend. We paused it and spoke to that customer instead, which turned out to be a support problem, not a product gap.
Almost every data analyst interview includes a live SQL round. These five patterns cover most of what gets asked. Say what the query does before you write it, and name the edge case, because that is what separates a memorised answer.
SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);The largest salary below the largest salary. A window function with DENSE_RANK also works and scales better to Nth highest, but this version is easier to say out loud.
Two passes over the table, or one with an index on salary.
If everyone earns the same, this returns NULL rather than erroring, which is usually the behaviour you want. Say that before they ask.
SELECT email, COUNT(*) AS times
FROM users
GROUP BY email
HAVING COUNT(*) > 1;Group by the column that should be unique, then filter groups with HAVING. WHERE cannot be used here because the count does not exist until after grouping.
One pass plus the grouping.
Being able to explain why it is HAVING and not WHERE is the actual question. Most candidates write it correctly and cannot say why.
SELECT
day,
revenue,
SUM(revenue) OVER (ORDER BY day) AS running_total
FROM daily_sales
ORDER BY day;A window function. Unlike GROUP BY it keeps every row, which is the whole point: you want each day and the cumulative figure beside it.
One pass, plus a sort if day is not indexed.
Without ORDER BY inside OVER you get the grand total on every row, not a running one. That is the most common mistake in this question.
SELECT
month,
revenue,
LAG(revenue) OVER (ORDER BY month) AS prev_month,
ROUND(
(revenue - LAG(revenue) OVER (ORDER BY month))
* 100.0 / NULLIF(LAG(revenue) OVER (ORDER BY month), 0),
1) AS growth_pct
FROM monthly_revenue
ORDER BY month;LAG gives the previous row. The growth is the difference over the previous value. NULLIF guards against dividing by zero when a month had no revenue.
One pass over the ordered set.
Multiply by 100.0 rather than 100, or integer division silently returns zero in several databases. And the first month has no previous row, so it is NULL rather than zero growth.
SELECT category, product, revenue
FROM (
SELECT
category,
product,
revenue,
ROW_NUMBER() OVER (
PARTITION BY category ORDER BY revenue DESC
) AS rn
FROM product_sales
) ranked
WHERE rn <= 3
ORDER BY category, revenue DESC;Rank within each group with PARTITION BY, then filter in an outer query. The window function cannot be filtered in the same WHERE clause, which is why the subquery is needed.
One pass plus a sort per partition.
ROW_NUMBER breaks ties arbitrarily. If two products tie for third and you want both, use RANK or DENSE_RANK instead. Interviewers often ask exactly that as a follow up.
InvisiHire listens to your call and drafts what you could say next, using your own resume. Free to start, no card needed. Check your employer's or your institution's rules on assistance before you use it.
Start free See how it works