Data Analyst Interview Questions: Rounds, SQL & a Worked Example

Data analyst interviews test three things in different proportions depending on the company: SQL (and sometimes Excel or Python), case-study reasoning on open-ended business questions, and how clearly you communicate findings to a non-technical audience. The technical bar is usually lower than for a software engineer role — the differentiator is judgment, not syntax mastery.

The Interview Rounds

SQL / technical screen. Write queries against a given schema — JOINs, GROUP BY with aggregates, subqueries, and window functions (RANK, ROW_NUMBER, LAG/LEAD) are the most commonly tested patterns.

Case study / business reasoning. An open-ended prompt like "engagement dropped last month, how would you investigate?" — there's rarely one correct answer; interviewers are scoring your approach.

Behavioral. Stories about a time your analysis changed a decision, or a time a stakeholder disagreed with your findings.

Excel (role-dependent). Still common outside product/tech companies — pivot tables and VLOOKUP/XLOOKUP are the baseline expectation.

SQL Patterns Worth Practicing

Most SQL interview questions are a combination of a small set of patterns: joining multiple tables correctly (and knowing when to use LEFT vs. INNER), aggregating with GROUP BY and HAVING, using window functions to rank or compare rows within a group, and writing subqueries or CTEs to break a complex question into steps.

A Framework for Case-Study Questions

When given an open-ended business question, work through it in this order rather than jumping to a guess:

1. Clarify the metric. Confirm exactly how it's defined and measured — "engagement" can mean five different things.

2. Confirm the change is real. Rule out a tracking or reporting bug before investigating a real business cause.

3. Segment to isolate it. Break the metric down by the obvious dimensions (platform, geography, user cohort, time) to find where the change is concentrated.

4. Form a hypothesis and name what would confirm it. State a specific, testable cause and the data that would prove or rule it out — this shows structured thinking, not just a guess.

Worked Example: Month-over-Month Growth Rate

A common SQL question that tests window functions and date handling together.

The ask: Given a table of monthly revenue (month, revenue), calculate the percentage change from the previous month.

Approach: Use LAG(revenue) OVER (ORDER BY month) to pull the previous month's revenue into the same row, then compute (revenue - prev_revenue) / prev_revenue * 100. The key insight interviewers are checking for is knowing that a window function — not a self-join — is the clean way to reference "the previous row" in a time series.

Follow-up to expect: "What happens for the very first month?" — a correct answer names that LAG returns NULL with nothing before it, and that the query should handle that explicitly rather than silently erroring.

How to Practice

Reading about SQL patterns and writing correct, efficient queries under interview pressure are different skills. Practice explaining your approach out loud — not just typing the query — in a live-scored AI Mock Interview, or build the daily habit with Flash Practice. See our SQL interview questions guide for more fundamentals.

Frequently Asked Questions

How much SQL do I need to know for a data analyst interview? Enough to comfortably write JOINs, GROUP BY with aggregate functions, subqueries, and window functions like RANK() or ROW_NUMBER(). Most interview questions combine 2-3 of these rather than testing exotic syntax.

What is a case-study round in a data analyst interview? An open-ended business question like "Sign-ups dropped 20% last month, how would you investigate?" — testing whether you can structure an analytical approach, not just recall a formula.

Do data analyst interviews test Excel or just SQL? It depends on the company. Many still test Excel (pivot tables, VLOOKUP/XLOOKUP) alongside SQL, especially for roles that support non-technical stakeholders. Product and tech companies lean more heavily on SQL and sometimes Python/pandas.

How do I answer "a metric dropped, investigate it" questions? Start broad before going deep: confirm the drop is real (not a tracking bug), segment by the obvious dimensions (platform, geography, user type) to isolate where it's concentrated, then form a hypothesis and state what data would confirm or rule it out.