Data Analyst Interview Questions
Real questions with answers: SQL, statistics, analytics cases and behavioural. Filter by topic and level.
- Free
- 20 questions with answers
- 4 topics
- No sign-up
20 questions
SQL
The most-tested skill in an analyst interview, usually live.
- INNER JOIN returns only rows that match in both tables. LEFT JOIN returns every row from the left table and fills the right-side columns with NULL where there is no match. Reach for LEFT JOIN when 'customers with no orders' should still appear.
- WHERE filters individual rows before aggregation; HAVING filters groups after aggregation. You cannot use an aggregate like COUNT(*) in WHERE, but you can in HAVING. So 'orders over $100' is WHERE; 'customers with more than 5 orders' is HAVING.
- Use a window function: SELECT DISTINCT salary FROM (SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) rnk FROM employees) t WHERE rnk = 2. DENSE_RANK handles ties correctly; a bare LIMIT/OFFSET breaks when two people share the top salary.
- A window function computes across a set of rows related to the current row without collapsing them into one, unlike GROUP BY. Use it for running totals, ranking within a group, or comparing a row to the group average (e.g. each order's amount versus that customer's average, with every row still returned).
- COUNT(*) counts all rows; COUNT(column) counts only rows where that column is not NULL. A gap between them is a quick way to measure missing values in a column.
- Almost always a condition on the right table in the WHERE clause. Filtering a right-table column in WHERE removes the NULL rows a LEFT JOIN just created, silently turning it into an INNER JOIN. Move that condition into the ON clause instead.
Statistics & experimentation
Enough to be trusted with an A/B test read-out.
- When the data is skewed or has outliers. One very large value drags the mean up, so for salaries, response times or order values the median is the more honest 'typical' figure. If mean and median differ a lot, the distribution is skewed.
- It is the probability of seeing a result at least this extreme if there were no real effect. A p of 0.03 does not mean a 97% chance the variant is better. It means a gap this big would occur 3% of the time by chance alone. It says nothing about effect size or business impact.
- The 5% false-positive rate assumes you look once, at a sample size fixed in advance. If you check daily and stop the moment it turns significant, you will declare winners on tests where nothing happened. Decide the sample size up front and read the result once.
- Correlation means two variables move together; causation means one drives the other. Ice-cream sales and drowning deaths correlate, but both are driven by hot weather. To claim causation you need a controlled experiment or a strong design that rules out the lurking variables.
- From four inputs: the baseline rate, the minimum effect worth detecting (MDE), the statistical power (usually 80%) and the significance level (usually 95%). Smaller effects need far larger samples: roughly quadrupling the sample to halve the detectable effect. Fix this before launching.
- A trend that appears in each subgroup can reverse when the groups are combined, usually because of an uneven split behind the aggregate. It is why you segment before trusting an overall number: a treatment can look worse overall yet be better for every individual group.
Analytics & product case
How you think, not what you memorised.
- First rule out instrumentation, because a broken tracking tag or a data pipeline failure explains most overnight cliffs. Then segment: by platform, region, new vs returning, and version. A drop concentrated in one segment points at a cause; a uniform drop points at tracking or an external event. State a hypothesis, then check it against the data.
- Start from the goal, then pick one primary metric that captures it, plus guardrail metrics that catch harm. For a new checkout flow: primary = conversion rate; guardrails = revenue per user, refund rate, support tickets. Define adoption (did people use it?) separately from impact (did it help?).
- They want your structure, not the number. Break it down: population × share who use the app × average rides per active user per day, adjusted for time of day and day of week. State assumptions out loud, keep the arithmetic round, and sanity-check the answer against something you know.
- Check whether it was ever powered to detect the effect you care about. An inconclusive result on an underpowered test is expected, not informative. If it was powered and still flat, the honest read is 'no meaningful effect', which is a valid, shippable finding. Do not extend it hoping to cross the line; that reintroduces the peeking problem.
Behavioural & communication
The half of the job that isn't code.
- Lead with the decision, not the method. Say what you found and what they should do, in one sentence, then offer the 'how' only if asked. Use their units (revenue, customers, days), not yours (p-values, joins). The best analysts are translators, and this question tests exactly that.
- Pick a real example, own it plainly, and focus on what you changed. Strong answers show you caught it (or how you'd catch it now): a validation step, a second data source, a sanity check you added. Interviewers are testing honesty and how you handle being wrong, not whether you ever are.
- Show what the data actually says, including the parts that don't support the conclusion, and separate the analysis from the recommendation. You can respect their decision while refusing to launder it. Saying 'here's what the numbers show; the call is yours' keeps your credibility intact, which is the only thing that makes your future analysis worth anything.
- By impact and reversibility: which decisions are biggest, and which are hard to undo without the analysis. Make the trade-off visible to the requesters rather than silently dropping work, and push back on requests that are curiosity rather than a decision. Managing the queue transparently is itself a senior skill.
How it works
How analyst interviews are usually structured
Most analyst loops have four parts: a live SQL screen, a statistics/experimentation round, an analytics or product case, and a behavioural conversation. The SQL screen filters hardest, so if your time is limited, spend it there, and practise out loud, because you will be talking through your query while you write it.
What they're really testing
Interviewers care less about a perfect answer than about how you reason: do you clarify the question, state assumptions, sanity-check your result, and explain it in the stakeholder's language? A slightly wrong answer with clear thinking beats a right answer you can't justify.
Other free tools
More in Career & job search
- Resume ↔ Job MatcherCompare your resume with any analyst job description.
- H-1B Sponsor CheckerType a company: its USCIS H-1B approvals and the roles it has open today.
- How to Become a Data AnalystA free five-phase roadmap: SQL, stats, viz and a portfolio.
- How to Become an AI AnalystA free playbook: what the role is, and the path built on analyst foundations.
- Analyst Skills ChecklistPick a target role, tick what you have, see what to learn next.
- Resume Bullet BuilderTurn what you did into strong, metric-driven resume bullets.
All tools
Practise, then apply
Real analyst roles scraped daily from company career pages. No ghost jobs.
