Top 45 Data Analyst Interview Questions (2026)

An INNER JOIN returns only rows with a match in both tables. A LEFT JOIN returns every row from the left table plus matches from the right, with NULLs where there's no match. A RIGHT JOIN does the mirror. A FULL OUTER JOIN returns all rows from both sides, matched where possible.

In practice, most analyst work uses INNER and LEFT joins. The LEFT JOIN is the one to reach for when you want to keep all your base records and see which ones are missing related data, like customers with no orders.

WHERE filters individual rows before any grouping happens. HAVING filters groups after GROUP BY has aggregated them, which is why HAVING can reference aggregate functions like COUNT(*) or SUM(amount) and WHERE can't.

The rule of thumb: filter rows with WHERE, filter aggregates with HAVING. Using both in one query is common and correct.

GROUP BY collapses rows that share the same value in the grouped columns into a single row, so you can compute one aggregate per group. The common functions are COUNT, SUM, AVG, MIN, and MAX.

The rule that trips people up: every column in the SELECT must either be in the GROUP BY or wrapped in an aggregate. Otherwise the database can't decide which row's value to show.

A window function computes a value across a set of rows (the window) while keeping every individual row, unlike GROUP BY, which collapses them. You define the window with OVER (PARTITION BY ... ORDER BY ...).

The everyday uses: ranking rows within a group (ROW_NUMBER, RANK), running totals (SUM over an ordered window), and pulling the latest or top record per group. Getting the most recent order per customer without a messy subquery is the classic example.

Not the order you write it. The logical execution order is FROM and JOIN first, then WHERE, then GROUP BY, then HAVING, then SELECT, then ORDER BY, and finally LIMIT.

This explains two common confusions: why you can't use a SELECT alias in WHERE (SELECT runs later), and why HAVING can filter on aggregates while WHERE can't.

Group by the columns that define a duplicate and keep the groups with a count above one. That tells you which values repeat and how many times.

If you need to see the actual duplicate rows (not just the keys), a window function with ROW_NUMBER partitioned by those columns lets you flag every copy after the first.

NULL means unknown, not zero or empty. Any arithmetic or comparison with NULL returns NULL, which is why WHERE column = NULL never matches. You test with IS NULL and IS NULL, and aggregate functions like SUM and AVG skip NULLs, but COUNT(column) does too while COUNT(*) counts the row.

To handle them, use COALESCE to substitute a default, or filter them out explicitly. The gotcha to name: NULLs silently drop rows out of INNER JOINs and can skew an AVG if you assumed they were zeros.

Both let you build a query in steps. A subquery is nested inside another query. A CTE (common table expression, the WITH clause) is named and defined up front, then referenced by name, which usually reads far cleaner for multi-step logic.

CTEs also let you reference the same intermediate result more than once and can be recursive. For a two-line filter, a subquery is fine; for anything a reviewer has to trace, a CTE wins on readability.

A JOIN combines columns from two tables side by side based on a matching key, making the result wider. A UNION stacks the rows of two result sets on top of each other, making the result taller, and it requires the same number and types of columns.

Quick rule: JOIN to add related fields, UNION to append similar records. Also worth knowing: UNION removes duplicates while UNION ALL keeps them and runs faster.

Look at the query plan first to see where the time goes, usually a full table scan or an expensive join. The common fixes: add an index on the columns used in joins and WHERE clauses, filter rows earlier and select only the columns you need, and avoid functions on indexed columns in the WHERE clause because they block the index.

Beyond that, replacing correlated subqueries with joins or window functions, and materializing a heavy intermediate result, often helps. The honest answer starts with measure, don't guess.

SQL wins when the data lives in a database, is large, or the analysis needs to be repeatable and auditable. Excel wins for small, ad hoc datasets, quick pivots, and sharing something a non-technical colleague will open and edit.

The practical workflow many analysts use: pull and aggregate in SQL, then export a manageable result to Excel or a viz tool for the last mile. Knowing where each tool stops being the right one is the point of this question.

Pivoting turns row values into columns, like turning a month column into twelve monthly columns. In SQL you do it with conditional aggregation (CASE inside SUM) or a PIVOT clause where supported. Unpivoting does the reverse, collapsing wide columns back into rows, which is often needed to load data into a viz tool.

In spreadsheets this is a PivotTable, and in pandas it's pivot_table and melt. The concept matters more than the exact syntax.

The mean is the average, the median is the middle value when sorted, and the mode is the most frequent value. The mean is the default for symmetric data. The median is the honest choice when there are outliers or skew, because it isn't dragged around by extreme values.

Classic example: for salaries or house prices, report the median. A few very high values pull the mean up and make it a misleading 'typical' figure.

a shape check: row count, count of nulls per column, and the range (min and max) to catch impossible values comes first. For numeric columns, the mean, median, and standard deviation together tell you center and spread and hint at skew. For categorical columns, the distinct count and the most frequent values.

This first pass is really data-quality triage: it surfaces missing data, outliers, and duplicates before you trust any downstream number. Skipping it is how analysts ship wrong conclusions.

Standard deviation measures how spread out values are around the mean. A small standard deviation means values cluster tightly near the average; a large one means they're widely dispersed. It's in the same units as the data, which makes it easier to talk about than variance.

Why it matters in practice: two datasets can share a mean but behave completely differently. Average delivery time of three days means one thing at low spread and something much worse when the spread is huge.

Correlation measures how strongly two variables move together, from -1 to +1. A value near +1 or -1 is a strong linear relationship; near 0 is weak. It says nothing about why they move together.

Causation can be reversed, or a hidden third variable can drive both. Ice cream sales and drowning deaths correlate, but hot weather causes both. In an interview, always separate 'these move together' from 'this causes that,' and mention that an experiment is how you establish causation.

A normal distribution is the symmetric bell curve where most values sit near the mean and fewer sit in the tails. Roughly 68% of values fall within one standard deviation of the mean, 95% within two.

It matters because many statistical methods and confidence intervals assume approximate normality, and the central limit theorem means averages of large samples tend toward it even when the raw data isn't normal. That's the theoretical backing for a lot of A/B testing.

You split users randomly into a control group (A, the current experience) and a variant group (B, the change), show each group its version, and compare a chosen metric like conversion rate. Random assignment is what lets you attribute a difference to the change rather than to who happened to see it.

Then you check whether the observed difference is statistically significant, meaning unlikely to be chance, before rolling the winner out. The three things that make a test trustworthy: a single clear metric decided up front, a large enough sample, and enough runtime to cover normal variation like weekends.

A p-value is the probability of seeing a result at least this extreme if there were truly no difference (the null hypothesis). A small p-value, conventionally below 0.05, means the result is unlikely to be chance, so you reject the null and call the result statistically significant.

Two honest caveats to mention: significance isn't the same as importance (a tiny effect can be significant with a huge sample), and a p-value is not the probability that your variant is better. Interviewers respect candidates who state those limits.

Too small a sample and a real effect hides in the noise (a false negative), or random luck looks like a real difference. A large enough sample gives the test the power to detect an effect of the size you care about.

You decide sample size before running, based on the baseline rate, the smallest effect worth acting on, and the confidence you want. Running until you 'see something' instead is p-hacking, and it produces results that don't replicate.

First investigate rather than delete. An outlier is either a data error (a typo, a sensor glitch, a duplicated order) or a real extreme value, and the two get handled differently. Errors get fixed or removed; genuine extremes usually stay, because they're part of the truth.

If a few extremes distort an average, report the median alongside it, or use a method that's less sensitive. The wrong move is silently dropping any point that looks inconvenient, which quietly biases the result.

A confidence interval is a range around an estimate that expresses uncertainty. A 95% confidence interval means that if you repeated the sampling many times, about 95% of the intervals you built that way would contain the true value.

For a non-technical audience, the useful translation is 'our best estimate is X, and the plausible range is between these bounds.' A wide interval means low certainty, often from a small sample. It's a more honest report than a single point estimate.

Selection bias is when the data you analyze isn't representative of the population you want to conclude about, so the results don't generalize. Survey responses only from your happiest customers, or a test that accidentally excluded mobile users, both bias the answer.

You spot it by asking how the data was collected and who's missing. The tell is a mismatch between the sample and the target population. Naming this risk in practice, especially in an A/B test or survey question, is a strong signal.

Start from what you're trying to show, not from the chart. Trend over time is a line chart. Comparison across categories is a bar chart. Part-to-whole is a stacked bar or, sparingly, a pie with few slices. Relationship between two numeric variables is a scatter plot. Distribution is a histogram or box plot.

The guiding rule: pick the chart that makes the specific comparison you care about the easiest one for the eye to make. If someone has to squint to get the point, the chart is wrong.

A pie chart falls apart with more than a few slices or when the slices are close in size, because people compare angles far worse than they compare lengths. Two slices at 24% and 26% look identical in a pie; in a bar chart the difference is obvious.

Use a pie only for a simple part-to-whole story with two or three clearly different segments. For ranking or precise comparison, a sorted bar chart almost always reads faster.

A good dashboard answers a specific set of questions for a specific audience, and it puts the most important number where the eye lands first, usually top-left. It uses consistent, restrained formatting, filters that let people self-serve, and no chart that doesn't earn its space.

The most common failure is cramming every metric onto one page. A useful dashboard has a point of view about what matters. Before building, the right question is 'who uses this, and what decision does it drive?'

Both build interactive dashboards from connected data. Tableau is known for polished, flexible visualizations and is popular where visual analysis is the priority. Power BI is tightly integrated with the Microsoft stack (Excel, Azure), tends to cost less, and is common in Microsoft-heavy companies.

For an interview, the honest answer is that the concepts transfer: connect data, model it, build visuals, share. Pick the one the job lists and go deep, because interviewers test whether you can defend a chart choice, not which tool you prefer.

Lead with the answer and the decision it supports, then give the one or two numbers that back it, and leave the method for follow-up questions. Drop the jargon: say 'customers who use the mobile app buy 30% more often,' not 'the coefficient on the app-usage dummy is significant.'

Anchor to something the person already cares about, usually money or time, and end with a clear recommendation. The test is whether they can repeat your point to their boss without you in the room.

Sample answer: "When I found that a confusing checkout step was costing us sales, I didn't open with the funnel analysis. I told the head of product one sentence: 'One in five people who reach checkout drop at the shipping screen, and that's roughly $40,000 a month.' Then I showed a single bar chart of drop-off by step and recommended we test a simpler shipping page. He got it in ten seconds and greenlit the test that afternoon. The detailed SQL and the exact funnel were in an appendix he never needed to open."

The usual culprits: a truncated y-axis that exaggerates small differences, inconsistent scales across a set of charts, cherry-picked date ranges, dual axes that imply a relationship, and 3D effects that distort proportions. Most of these overstate an effect that's barely there.

You avoid them by starting bar charts at zero, keeping scales consistent, showing the full relevant time range, and choosing the simplest chart that tells the truth. An analyst's credibility depends on not doing these, even by accident.

Work backward from the decision or goal. A good metric is tied to something the business acts on, is clearly defined so two people compute it the same way, and moves when the underlying thing changes. Vanity metrics like raw page views look impressive but rarely drive a decision.

It also helps to pair a headline metric with a guardrail: track conversion rate, but watch refund rate too, so you don't optimize one number while quietly breaking another.

Give them the honest version and explain why. Don't just refuse, and don't quietly hand over the misleading figure. Show the number they asked for alongside the one that actually answers their question, and say plainly what the difference is and why it matters.

Most of the time the stakeholder wanted the underlying answer, not the specific cut, and framing it as helping them avoid a bad decision keeps the relationship intact.

Sample answer: "A sales director once asked me for our 'average deal size,' planning to quote it to the board. The mean was skewed by two enormous enterprise deals, so I showed him both: the mean at $48,000 and the median at $19,000, and explained that the median was the honest 'typical deal.' He used the median in the board deck and thanked me for catching it before it became a promise the team couldn't keep."

It means shaping an analysis into a clear narrative that leads an audience from a question to a recommendation, instead of dumping charts and letting them figure it out. A story has a point: here's what we asked, here's what the data shows, here's what we should do.

In practice that's ordering your visuals to build one argument, annotating the chart so the takeaway is on the page, and cutting anything that doesn't advance the point. The analysis found the insight; storytelling is what gets it acted on.

Straight, early, and with evidence. Bury a bad result and it costs more later, so lead with the finding, show the data cleanly, and separate the fact from any blame. Then pivot to what it means and the options, because stakeholders can handle bad news paired with a path forward.

Tone matters: present it as shared problem-solving, not an accusation. 'The campaign didn't hit target, here's what the data suggests and two things we could try' lands far better than a wall of red numbers with no next step.

Spreadsheets are still core to the job, so a strong coverage names specifics: PivotTables for fast aggregation, VLOOKUP or INDEX/MATCH (or XLOOKUP) for joining tables, conditional formatting to surface patterns, and functions like SUMIFS and COUNTIFS for conditional aggregation.

The honest framing is that spreadsheets are ideal for small, ad hoc, shareable analysis, and you switch to SQL when the data outgrows them or the work needs to repeat. Naming that boundary shows judgment, not just tool knowledge.

Pick one real project and tell it as a story: the business question, the data you pulled and how you cleaned it, the analysis, what you found, and the decision it drove. Interviewers care most about the framing at the start and the impact at the end, not every SQL step in the middle.

The strongest version has a number attached to the outcome and shows your judgment, not just your tool use: an assumption you had to make, a data-quality problem you caught, a result that changed what the team did.

Sample answer: "Our support team thought ticket volume was just growing with the customer base, and I was asked to confirm it. Pulling six months of tickets, I joined them to the product-area table and found something different: 40% of the growth traced to one confusing billing screen, not to headcount. The data was messy, plenty of tickets had no product tag, so I built a keyword classifier to fill the gaps and validated it against a hand-labeled sample. I presented one chart of tickets by root cause, recommended a redesign of that screen, and after it shipped, billing tickets dropped by about a third. That project is why I now always check the composition of a trend before accepting the obvious explanation."

Cleaning is most of the job, so pick a real example and walk through the specific problems: missing values, inconsistent formats, duplicates, impossible values, mismatched keys across tables. Show the decisions, not just the mechanics. What you dropped, what you imputed, what you flagged, and why each call was defensible.

The evaluated part is judgment. Silently deleting anything inconvenient is the wrong instinct; documenting your cleaning choices so someone could audit them is the right one.

Sample answer: "A sales export I inherited had dates in three different formats, revenue stored as text with currency symbols, and about 8% duplicate rows from a botched sync. I standardized the dates, stripped and cast the revenue to numbers, and deduplicated on order ID while keeping the most recent record. The impossible values, a handful of negative quantities, I didn't just delete: I traced them to a returns process and split returns into their own flag. I kept a short log of every transformation so the finance team could trust the cleaned table, and they ended up adopting it as the source of truth."

This screens for impact, not activity. Pick an analysis where your finding actually moved something: a feature that got built or killed, a budget that shifted, a process that changed. Show that you didn't just report a number, you connected it to a decision and followed through on getting it acted on.

The best versions include mild resistance you had to work through, because insights rarely get adopted on the first slide.

Sample answer: "Marketing was about to double spend on a channel that looked like our top performer by last-click attribution. Digging in, I found those conversions overlapped heavily with users who'd already seen three other touches, so the channel was mostly taking credit, not creating demand. I built a simple first-touch versus last-touch comparison to show it. The head of marketing pushed back at first, understandably, so I proposed a two-week holdout test on that channel. Conversions barely moved without it. We redirected the budget, and that reallocation is credited with part of the next quarter's efficiency gain."

Turn the fog into a specific question before touching the data. Ask what 'down' means (which metric, over what period, versus what baseline), what decision the answer feeds, and by when they need it. Then form a small set of hypotheses, seasonality, a specific region or product, a pricing change, and check the cheapest one first.

The instinct being tested is whether ambiguity triggers investigation or paralysis. Jumping straight into a giant query without scoping the question is the failure mode.

Sample answer: "When a director asked me to 'figure out why revenue dropped,' I didn't open a query. I asked three questions and learned he meant a 12% drop in one region, month over month, and he needed it for a Friday review. That scoped everything. I listed likely causes, split it by product line first, and within an hour saw the drop was almost entirely one discontinued SKU, not a broad decline. I gave him that answer Thursday. Ninety percent of the value was in narrowing the question, not in the SQL."

They want a real error you owned, caught (or had caught), and fixed, plus what you changed so it wouldn't recur. The evaluated sequence is detection, disclosure, repair, prevention, and disclosure speed matters most, because they're predicting what you'll do the first time you ship a bad number at their company.

Pick a genuine mistake, not a humble-brag. A double-counted join, a wrong date filter, a metric defined differently than the stakeholder assumed.

Sample answer: "I once reported a 15% jump in active users that turned out to be a join fanning out: a one-to-many relationship I'd treated as one-to-one, counting some users multiple times. I caught it two days later when the number didn't reconcile with another report, and I flagged it to my manager immediately with the corrected figure, which was a modest 3% gain, before it reached the exec deck. Then I added a row-count sanity check to my query template that compares against the base table. That check has caught two similar fan-outs since."

Build in checks rather than trusting the first result. Reconcile totals against a known source, sanity-check row counts after every join to catch fan-outs, spot-check a few individual records by hand, and question any result that looks too good. If a number surprises you, assume a bug until proven otherwise.

Having a second person The query for anything high-stakes is cheap insurance matters. The mindset the question needs is healthy distrust of your own output.

Prioritize by impact and deadline, not by who asked loudest. Get each request's actual decision and timeline, rank by which unblocks the biggest call soonest, and make the trade-off visible to the people whose request is waiting rather than silently dropping it.

For recurring asks, the higher-impact move is often building a self-serve dashboard so the requester stops needing you for the same question every week.

Sample answer: "Three teams needed reports the same week, all marked urgent. I asked each what decision the number fed and when. One was for a board meeting Friday (immovable), one could wait a week, and one turned out to be a question a dashboard could answer permanently. So I built the dashboard first (an hour that saved recurring interruptions), delivered the board number next, and told the third team their exact delivery time. All three were fine once the reasoning was visible."

The evaluated skill is your learning method under a deadline, not the specific tool. The constraint, the deliberate path you chose, and the checkpoint that proved it worked. Interviewers use this to predict your first month, so make the method sound reusable.

Data analyst work changes tools often, so this comes up a lot.

Sample answer: "Our team switched from Tableau to Power BI with about three weeks' notice, and I owned the weekly executive dashboard. I gave myself a tight loop: an hour each morning on the fundamentals, then afternoons rebuilding one existing Tableau view in Power BI until I could reproduce it exactly. I rebuilt the real dashboard in parallel, checking every number against the old one before switching over. By week three the Power BI version was live with zero discrepancies. It wasn't elegant DAX at first, but it was accurate, and I refactored it over the next month."

Lead with curiosity, not confrontation. First double-check your own analysis, because the stakeholder's intuition often reflects context you're missing. If the data holds up, present it as a puzzle to solve together: here's what I'm seeing, here's how I measured it, help me understand where this diverges from your experience.

Sometimes you're both right about different things (their gut is about one segment, your number is the overall). Framing it as reconciling two views, rather than proving them wrong, keeps the finding usable.

Sample answer: "A regional manager was sure his territory was our best performer, but my numbers ranked it fourth. Instead of leading with 'you're wrong,' I walked him through my definition of performance, revenue per rep, and asked how he saw it. Turned out he was thinking of raw revenue, where his large team did rank first. Once we agreed on per-rep as the fair measure, he accepted the ranking, and it actually helped him make the case for a smaller, more efficient team structure."

Pick something with genuine difficulty, ambiguous requirements, messy or huge data, a hard deadline, or a result that mattered, and walk through how you broke it down. The story should show structured thinking under real constraints, not just that the topic was complex.

Land on what you learned or what the analysis changed, so the difficulty pays off in an outcome.

Sample answer: "The hardest was untangling why our customer churn number disagreed across three teams, each quoting a different figure to leadership. The real problem wasn't the data, it was that nobody had agreed on what churn meant: some counted downgrades, some only full cancellations, some used a 30-day window and others 90. I documented all three definitions, showed how each produced its number, and facilitated a decision on one standard. The technical work was moderate; the challenge was the ambiguity and the politics. We ended with a single churn definition the whole company now uses."

Answer with something specific and true, tied to how you actually work, not a generic love of numbers. the check is that what the job offers daily, querying, finding patterns, informing decisions, is what genuinely engages you, because a wrong-but-impressive answer wins you a job you'll dislike.

it connects to a concrete moment where analysis you did led to a decision, then to why this role gives you more of that.

Sample answer: "What hooks me is closing the loop from a messy question to a decision someone acts on. In my last role I noticed a cluster of support tickets nobody had connected, traced them to one root cause, and watched the fix cut the volume in half. That arc, spot the pattern, prove it, see it change something, is what gets me in early. This role sits closer to product decisions than my current one, which means more of exactly that, and the data infrastructure here means less time fighting bad exports and more time actually analyzing."