What skills are tested in a data analyst interview?

SQL first: joins, aggregation, window functions and multi-step queries with CTEs. Then a BI tool such as Tableau or Power BI, including its data model and how filters and calculations interact. Then applied statistics (averages versus medians, significance, A/B test basics) and a business case where you define a metric or explain why one moved. Python with pandas appears in some loops, usually for data cleaning.

How hard is the SQL in a data analyst interview?

The syntax is ordinary: joins, GROUP BY, window functions, CTEs. The difficulty is correctness on realistic data. Interviewers check that your join does not duplicate rows, that your aggregate is at the grain the question asked for, and that NULLs and ties do not silently change the answer. A correct query written slowly beats a fast one that double-counts.

How long does it take to prepare for a data analyst interview?

One to two weeks if you already use SQL at work. Spend most of the first week writing queries against a realistic dataset with several related tables, a few days on your BI tool's data model and calculations, and the rest on metric definition and explaining results out loud. If SQL is new to you, plan for a month and practise every day.

Do data analysts need to know Python?

Increasingly, but less than SQL. Many analyst loops include a short pandas task: load a CSV, clean missing values, group and aggregate, merge two tables. You rarely need machine learning. If the job description mentions Python, expect cleaning and reshaping questions rather than algorithms.

What is the difference between a data analyst and a data scientist interview?

Analyst interviews focus on SQL, BI tools, metric definition and communicating results to business stakeholders. Data scientist interviews add more statistics, experiment design and often modelling. The overlap is large at product companies, where a 'data scientist, product analytics' loop looks much like a senior analyst loop with harder statistics.

How to Prepare for a Data Analyst Interview in 2026

Every data analyst interview asks the same underlying question in three formats: is your number right? The SQL screen checks it on a query, the BI round checks it on a dashboard, and the case round checks it on a metric you define yourself. Candidates rarely fail on syntax. They fail because a join duplicated rows, an aggregate was computed at the wrong grain, or a filter ran before the calculation it was supposed to follow.

That makes preparation more focused than it first looks. Data analyst interview questions cluster into five areas:

Joins and grain - what one row means, before and after every join
Window functions - rankings, running totals and shares without losing rows
Multi-step queries - CTEs, subqueries, and the order in which SQL evaluates a query
Your BI tool's data model and filters - what the tool does before it draws anything
Calculations and level of detail - aggregates that ignore, or respect, what is in the view

The article covers each area, then statistics and the business case, and closes with a 7-day plan. Start by finding your gaps.

Start here: a 5-question self-check

Five questions from squizzu's question bank, one for each of the five areas above. The last two use Tableau, the most common tool in analyst job postings; if you use Power BI, the concepts carry over even where the names differ. Answer each one, then read the explanation and the in-depth breakdown.

SQL • Joins & Relationships

Question 1 / 5

A university database models the many-to-many relationship between students and courses with a junction table enrollments(student_id, course_id). You need to list each student's name alongside the titles of the courses they are enrolled in. What is the correct join structure?

The question that catches most experienced analysts is the running total. Everyone has written a window function; fewer people know where in the query it is evaluated, and that decides where a filter on its result is allowed to go. The filter-order question is the BI equivalent: the same idea, inside a tool. If the many-to-many join caught you, start with area 1; window functions are area 2, the running total area 3, filter order area 4 and FIXED area 5.

What a data analyst interview looks like

Recruiter screen. Tools you use and the decisions your analysis changed. "Built dashboards" is weaker than "found that 40% of churn came from one onboarding step".
SQL screen. Live, 30 to 60 minutes, usually two or three questions of rising difficulty on a small schema.
BI or take-home. Build a dashboard from a dataset, or walk through one you built. Expect questions on the data model and on why a number is what it is.
Case round. Define a metric, explain a drop, or design a simple A/B test.
Behavioural. A stakeholder who disagreed with your numbers, an analysis that turned out wrong.

Area 1: SQL joins and grain

The most important habit in analyst SQL is saying what one row means before you write the query. "One row per order", "one row per customer per day". Then check that every join preserves it.

A join on a key that is unique on one side keeps the grain of the other side. A join on a key that repeats on both sides multiplies rows, and every SUM after it is inflated. That is the most common silent error in analytics, and the reason interviewers love schemas with a junction table between two entities.

Be fluent in LEFT JOIN versus INNER JOIN, what happens to unmatched rows, and why a condition in WHERE on the right-hand table can turn a left join back into an inner one. Know composite keys: when a row is identified by two columns together, the join has to match on both.

Question: Revenue per customer looks too high after you join orders to a promotions table. What happened?

Short answer: The join key is not unique in promotions, so each order appears once per matching promotion and its amount is summed several times.

Explanation: Check with a count: the number of rows after the join should equal the number of orders. If it is higher, aggregate promotions to one row per key first, or pick the single relevant promotion with a window function, and only then join.

What the interviewer is testing: Whether you verify the grain instead of trusting the output. Analysts who check row counts after each join catch this in a minute; analysts who don't present it to a VP.

Common follow-up: "How would you find which orders were duplicated?"

Area 2: SQL window functions

Window functions compute across related rows without collapsing them, which is exactly what most analyst questions need: rank within a group, compare to the previous period, compute a share of a total, keep a running sum.

Know the pieces of OVER (...): PARTITION BY restarts the calculation per group, ORDER BY defines sequence, and the frame clause decides which rows count. Know ROW_NUMBER, RANK and DENSE_RANK and what each does with ties. Know LAG and LEAD for period-over-period. Know that an aggregate with an empty OVER () runs across the whole result.

Question: How do you get the top three products by revenue in each category?

Short answer: Rank products within each category with a window function partitioned by category and ordered by revenue descending, then keep ranks up to three in an outer query.

What the interviewer is testing: Tie handling. ROW_NUMBER returns exactly three rows per category and drops ties arbitrarily; RANK and DENSE_RANK keep ties and can return more. Saying which one you chose and why is the answer.

Common follow-up: "Now show each product's revenue as a percentage of its category."

Area 3: Multi-step SQL queries and CTEs

Real questions need several steps: filter events, compute per-user metrics, then aggregate those. CTEs make each step readable and testable, and interviewers notice when you build a query in stages rather than as one nested block.

The concept underneath is logical evaluation order. SQL is written SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY, but evaluated roughly FROM, WHERE, GROUP BY, HAVING, window functions, SELECT, ORDER BY. That order explains why WHERE cannot reference an aggregate, why HAVING can, and why you cannot filter on an alias defined in the same SELECT in most databases.

Question: What is the difference between WHERE and HAVING?

Short answer: WHERE filters rows before grouping; HAVING filters groups after aggregation, so it can reference aggregates such as COUNT(*).

What the interviewer is testing: Whether you know the order or just the rule. A candidate who can explain the evaluation order can also answer the next three questions about it.

Common follow-up: "Find users whose first purchase was over $100." (A window function or a MIN per user in a CTE, then an outer filter.)

Area 4: BI tool questions: data model and filters

BI rounds rarely ask where a button is. They ask why a number on a dashboard is wrong, and the answer is almost always in the data model or the filter order.

The data model. In Tableau, know the difference between a join, which combines tables into one at row level before analysis, and a relationship, which keeps tables separate and joins them per view at their own level of detail. Power BI has the same question in the form of relationships, cardinality and filter direction in the model view. Either way, the risk is the one from area 1: a model that duplicates rows makes every measure on top of it wrong.

Filters. Tools apply filters in a fixed order, and a filter can only affect what is computed after it. That decides whether a "top 10" filter respects a region filter, and whether a total excludes rows you hid. Learn your tool's order well enough to predict, before you click, what a filter will do.

Question: A dashboard total does not match the same number computed in SQL. How do you track down the difference?

Short answer: Rebuild the number step by step. Check the data source row count against the table, check every filter and its place in the order, then check whether the measure aggregates at the grain you expect.

What the interviewer is testing: A debugging method for a tool you cannot read like code.

Common follow-up: "When would you use an extract rather than a live connection?"

Area 5: Calculations and level of detail

Every BI tool has a way to compute an aggregate at a level different from the view. In Tableau these are level of detail expressions: FIXED, INCLUDE and EXCLUDE. In Power BI it is CALCULATE with filter modifiers such as ALL and ALLEXCEPT. These power the questions analysts actually get: "each customer's first order date", "each region's share of the total", "average order value per customer, then averaged across customers".

The interview test is whether you understand granularity: the dimensions in the view decide what a plain aggregate means, and a level-of-detail calculation lets you pin it elsewhere. Know also that you cannot nest one aggregate directly inside another, and what to use instead.

Question: How do you show average revenue per customer when the view is broken down by month?

Short answer: First compute revenue per customer at the customer level, then average those values in the view. In Tableau, a FIXED expression on customer; in Power BI, AVERAGEX over customers.

What the interviewer is testing: Whether you notice that the "obvious" average (total revenue divided by orders) answers a different question.

Common follow-up: "Why might that number differ from total revenue divided by distinct customers?"

Statistics and metrics questions

No quiz question above covers this, but every case round does. Expect applied questions:

Averages versus medians. Revenue, session length and order value are skewed. A mean can move because of a few large accounts while the typical user stays put.
Significance in plain words. A p-value is the probability of data at least this extreme if there were no real effect. It is not the probability that the effect is real.
A/B test basics. One primary metric chosen in advance, a sample size estimated before launch, and a guardrail metric that would catch a harmful win.
Explaining a moved metric. Before theorising, cut by platform, country, new versus returning users and release date, and check whether tracking changed. Broken instrumentation explains more drops than user behaviour does.

Python and pandas questions

If the posting mentions Python, expect a short pandas task. It is usually cleaning, not modelling: find and fill missing values, drop duplicates, fix types, group and aggregate, merge two frames. The same grain discipline from area 1 applies to merge.

A 7-day preparation plan

Use one realistic dataset with at least four related tables, such as an e-commerce sample with customers, orders, order items and products. If you only have two days, spend them on day 1 and day 6: a grain error is the most common way to fail the SQL screen, and explaining a result clearly is what the case round scores.

Day 1: Joins and grain. Write ten queries. Before each one, write down the grain of the result; after each join, check the row count.
Day 2: Window functions. Top N per group, running totals, period-over-period change, share of total. Do each with ties in the data.
Day 3: Multi-step queries. Rewrite your longest query as a chain of CTEs. Write out the evaluation order from memory.
Day 4: BI data model and filters. Load the same dataset into your BI tool, build one dashboard, and reconcile every number with SQL.
Day 5: Calculations. Build three level-of-detail calculations and explain each one in a sentence.
Day 6: Metrics and the case. Define a success metric for a feature, then list three reasons it might drop and how you would check each.
Day 7: Answer out loud. Go through each section's questions in under two minutes each, then revisit what the self-check exposed.

How ready are you?

The self-check gave you five data points. The SQL set behind it works the same way at a larger scale: answer, then read why every option is right or wrong.

Practise SQL and BI questions on squizzu, with an explanation and an in-depth breakdown for every question.

Aiming at a product analytics role at a large company? 20 Meta data scientist interview questions covers the SQL shapes those screens reuse, from outer joins that collapse into inner joins to percentiles over a window. For indexes, query plans and constraints, see SQL interview questions for 2026.