Data analyst interview questions

What a data analyst interview tests, round by round

A data analyst loop is usually three or four conversations, and each tests something different. The recruiter screen checks the basics: the tools you touch daily, the domain you have worked in, your notice period and your salary range. The technical round is where SQL lives, often as a shared screen with a small schema and three or four questions that build on each other. Many teams add a case or take-home task: here is a dataset or a business question, show us how you would approach it. The final round is usually with the hiring manager or a stakeholder you would serve, and it is about communication, prioritizing and pushing back.

The US Bureau of Labor Statistics describes this kind of work as using analytical tools and techniques to extract meaningful insights from data, with duties that include determining which data are available and useful for the project and using data visualization software to present findings. The interview mirrors that order: first you show you can get the numbers out, then that you picked the right numbers.

Two habits decide most outcomes. The first is checking the grain of the data before writing anything: what does one row mean, and can a join duplicate it? The second is narrating your reasoning, because a wrong query with clear commentary usually scores better than a silent correct one.

The SQL round: joins, grouping and window functions

Data analyst technical interview questions cluster around a handful of SQL ideas: the difference between an inner and a left join, what GROUP BY does to rows, why COUNT(*) and COUNT(column) can disagree, and how to rank rows inside a group.

A typical opener is an aggregation with a filter, such as revenue by product this year keeping only products above a threshold.

SELECT p.product_id,
       p.name,
       SUM(o.quantity * o.unit_price) AS revenue
FROM orders o
JOIN products p ON p.product_id = o.product_id
WHERE o.order_date >= '2026-01-01'
  AND o.status = 'completed'
GROUP BY p.product_id, p.name
HAVING SUM(o.quantity * o.unit_price) > 2500
ORDER BY revenue DESC;

Two details earn credit. WHERE filters rows before grouping and HAVING filters groups after, so the date and status conditions belong in WHERE while the revenue threshold belongs in HAVING. And every column in the SELECT list that is not inside an aggregate has to appear in GROUP BY.

The follow-up is almost always a ranking question: the top two products in each category. That is a window function.

SELECT category, name, revenue
FROM (
  SELECT p.category,
         p.name,
         SUM(o.quantity * o.unit_price) AS revenue,
         ROW_NUMBER() OVER (
           PARTITION BY p.category
           ORDER BY SUM(o.quantity * o.unit_price) DESC
         ) AS rank_in_category
  FROM orders o
  JOIN products p ON p.product_id = o.product_id
  WHERE o.status = 'completed'
  GROUP BY p.category, p.name
) ranked
WHERE rank_in_category <= 2
ORDER BY category, revenue DESC;

Interviewers like to ask why the ranking sits in a subquery. The answer is evaluation order. PostgreSQL’s documentation states that window functions are permitted only in the SELECT list and the ORDER BY clause of the query and are forbidden elsewhere, such as in GROUP BY, HAVING and WHERE, because they logically execute after the processing of those clauses. So you compute the rank in an inner query, where it becomes an ordinary column, then filter on it outside. Expect the tie-breaking follow-up too: on a tie, ROW_NUMBER still hands out distinct numbers, RANK gives both the same number and then skips one, and DENSE_RANK repeats the number without leaving a gap.

A third favorite asks you to find rows that are not there, such as customers with no completed order.

SELECT c.customer_id
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
 AND o.status = 'completed'
WHERE o.order_id IS NULL;

The subtle part is that the status test sits in the ON clause. Move it to WHERE and the left join behaves like an inner join, because the unmatched rows carry nulls by then and fail the test. If you offer NOT IN instead, add that a NOT IN subquery returning even one NULL produces no rows at all.

For query-by-query drills rather than interview shape, work through SQL interview questions.

Excel and business intelligence tool questions

Plenty of analyst roles still run on spreadsheets, so Excel questions are common and specific. Lookups come up most. Microsoft documents the syntax as =XLOOKUP(lookup_value, lookup_array, return_array, [if_not_found], [match_mode], [search_mode]), and that signature answers “why XLOOKUP over VLOOKUP”: it takes a lookup array and a separate return array instead of a column index, so you are not counting columns, it can return a value that sits to the left, and you supply your own not-found text. Expect PivotTables as a task rather than a question, plus duplicate removal and the perennial date column that is secretly text.

Business intelligence interview questions move one level up, to the model behind the dashboard. If the advert names Power BI, be ready to explain a star schema, because Microsoft’s own modeling guidance recommends exactly that: dimension tables enable filtering and grouping, fact tables enable summarization, and the one side of a one-to-many relationship is always the dimension table. Power BI interview questions for data analyst roles then tend to probe measures. An explicit measure is DAX that you write, an implicit measure is a column the visual summarizes for you, and you write explicit measures when you need control over how a column may be aggregated, such as a unit price that should never be summed. For Tableau or Looker the vocabulary differs and the real question does not: how do you keep a dashboard fast and unambiguous?

Have an answer ready about a dashboard you built: who used it, what decision it changed, and what you took off it. Analysts who can name what they removed understand their audience.

The analytics case and the take-home task

The case round sounds open-ended but is marked on structure. A prompt such as “sign-ups fell last week, what happened?” is not asking you to know the answer. It is asking how you narrow a vague problem.

Check the measurement before the business. Is the drop real, or did tracking break, a filter change, a bot exclusion land, a time zone move the day boundary? Then segment: by channel, country, device, new versus returning. Compare like with like, which usually means the same weekday a week earlier, because weekly seasonality will otherwise hand you a confident wrong story. Name the cut you would look at first and say why.

Take-homes usually arrive as a messy CSV and a loose brief. The common failure is a notebook full of charts and no conclusion. Lead with the question, state your assumptions and which rows you dropped, show the two or three charts that carry the argument, then finish with one recommendation and the next thing you would measure. Keep it reproducible: one script or notebook that runs top to bottom on a fresh copy of the data.

If the task is live in Python or pandas, print the shape and the null counts before transforming anything, and end with a sanity check that reaches one total by a second route. Checking before computing is part of what is being scored, not a delay.

Stakeholder and behavioral questions for analysts

The final round is rarely technical. It tests whether a business team would want you in their planning meeting, and whether a number you produce can go into a board deck unchecked.

The prompts repeat across companies. Tell me about a time you explained a technical result to a non-technical audience. A time two reports disagreed and you reconciled them. A time you told a stakeholder their favorite metric measured the wrong thing. How you prioritize when three people ask for a dashboard on the same morning.

Answer these as short, specific stories. MIT’s career office describes the STAR pattern as situation, task, action and result, and advises that most of your response should focus on your actions, which is precisely what an interviewer is listening for here. If the structure is new to you, the STAR method page walks through it.

Two analyst-specific notes. In a reconciliation story, name the actual cause: a different date field, a filter on cancelled orders, a currency conversion applied twice. Vague talk about “aligning on definitions” sounds rehearsed because it usually is. And when you describe a request you declined, include the trade you offered instead.

If this is your first analyst role

Interview questions for a data analyst fresher are not easier, they are sourced differently. With no work projects to draw on, the interviewer will use whatever you do have: a course capstone, a dataset you pulled yourself, a tracker you built for a student society, a report you wrote in an unrelated job. One project you can discuss in depth beats four you can only list.

Prepare that project the way you would prepare a case. Where did the data come from, what did one row represent, what did you clean and why, what did you conclude, and what would you do differently with another week? Expect a question about a mistake, so choose a real one: a join that double-counted, a chart that misled, an assumption you never tested.

Close the obvious gaps before the call: joins, aggregation, window functions and null handling in SQL, and opening a CSV, pivoting it and producing a clean chart without fighting the tool. For wider first-job framing, see the entry-level interview page.

A week of preparation, and a mock interview

A workable plan is four short evenings: two on SQL drills, one on the company and its metrics, and one on a data analyst mock interview out loud.

On the SQL evenings, write queries instead of reading them. Create a small local database with three tables and solve the same four shapes repeatedly: aggregate with a filter, rank within a group, find the missing rows, reconcile two tables that should agree. Predict what each query returns before running it, because the shared-screen round asks exactly that.

On the company evening, work out how the business makes money and which numbers that implies. Subscriptions point at retention, churn and cohorts. Inventory points at stock turn, margin and returns. Save two questions that only someone who looked would ask; questions to ask the interviewer has more on that.

For the mock interview, record yourself on one case prompt and one stakeholder story, then watch only the first minute of each. Most data analyst interview tips stop at “practise out loud”. The thing to check is whether you stated the question and your assumptions before the detail.