Data Analyst Interview Questions

Data Analyst interviews look easy on paper — SQL, a dashboard, maybe a case study — and that's exactly why so many strong candidates get rejected at the final round. The role isn't about running queries correctly. It's about knowing which question to ask before you run one, and knowing when a clean-looking number is hiding a dirty problem. Interviewers are testing judgment under ambiguity, not tool proficiency. This bank covers the scenarios that separate candidates who get an offer from candidates who get a polite rejection after "we went with someone with more experience."

What Data Analyst Interviews Test

• Diagnostic thinking — can you trace a confusing number back to its root cause instead of taking it at face value
• Statistical judgment — do you know the difference between a result that's statistically significant and one that's actually worth acting on
• Communication under pressure — can you turn a technical finding into a decision a non-technical stakeholder can act on in under two minutes
• Data skepticism — do you question the data before you trust it, especially when it conveniently supports what someone wants to hear
• Prioritization — can you triage competing, equally "urgent" requests without burning out or dropping the one that actually matters

Question 1: Reconciling a Metric Mismatch

Marketing's dashboard says signups are up 18% this month. Your dashboard, built off the same underlying event data, says signups are flat. Both dashboards are "live" and both teams have already reported their numbers upward — Marketing to the CMO, you to the Head of Data. You have two hours before a joint meeting where someone will have to explain the gap. What do you do?

Why interviewers ask this

Every analyst eventually inherits two "true" numbers that disagree. Weak candidates panic and start re-running their own query defensively, assuming they're wrong or assuming Marketing is wrong. Strong candidates treat it as a definitions problem first and a data problem second — because in practice, most mismatches come from different filters, not different facts.

Example strong answer

"Before touching any code, I'd get the exact definition each dashboard is using: what counts as a 'signup' — email capture, verified account, or first login? What date range and timezone? What user segments are included or excluded, like test accounts or bot traffic? Nine times out of ten, the gap is here, not in the pipeline. If definitions genuinely match, I'd pull both queries and diff them line by line rather than trusting either dashboard's summary view, since dashboards often apply silent filters a user didn't set. I'd also check for double-counting or dedup logic differences — if Marketing's tool counts by session and mine counts by unique user, that alone can produce an 18-point gap. Once I isolate the actual cause, I wouldn't walk into the meeting saying 'my number is right.' I'd walk in with a one-line explanation both teams can agree on: 'Marketing's dashboard counts email captures, ours counts verified signups — real signups are flat, top-of-funnel interest is up 18%.' That reframes a conflict into two consistent, useful facts instead of a fight over whose number wins. If I can't resolve it in two hours, I'd say so honestly and give a time-boxed plan rather than presenting a rushed, possibly wrong reconciliation just to look prepared."

Follow-up questions

• What if both teams insist their number is the one going to the board, and you only have ten minutes left?
• What if you find the mismatch is actually a real data pipeline bug, not a definitions issue — how does your recommendation change?

Question 2: Shipping an Ambiguous A/B Test

An A/B test on checkout flow shows a 2.1% lift in conversion for the new design, but the p-value is 0.14 — not statistically significant at the standard 0.05 threshold. The PM wants to ship it because "it's clearly working" and the team is under pressure to show a win this sprint. What's your recommendation?

Why interviewers ask this

This tests whether a candidate can hold a position under organizational pressure, and whether they understand statistics as a decision tool rather than a checkbox. The weak answer is a flat "no, it's not significant, don't ship." The strong answer engages with the actual business trade-off.

Example strong answer

"I wouldn't just cite the p-value and stop there — that's technically correct but not useful to the PM. I'd first check if the test was underpowered: what sample size did we plan for, and did we hit it? If the test ran short on traffic, a 0.14 p-value with a positive trend is genuinely inconclusive, not evidence against the change — it just means we don't have enough data yet, and I'd propose running it two more weeks rather than making a permanent call on incomplete evidence. If we did hit planned sample size and it's still not significant, I'd separate the decision into two questions: is this change risky, and is it reversible? A checkout redesign with no negative signals in secondary metrics — bounce rate, error rate, support tickets — is a low-risk, reversible change. In that case, I'd tell the PM: 'I can't say with confidence this design is better, but I also don't see evidence it's worse, and it's easy to roll back. If shipping matters for momentum, that's a reasonable business call — just don't report it externally as a proven 2.1% lift, because that number isn't reliable yet.' If it were a pricing change or something hard to reverse, I'd push back harder and recommend waiting, because the cost of being wrong is asymmetric. The core point I'd make to the PM: statistical significance and business decision aren't the same question, but conflating them either way — shipping on false confidence or blocking on excessive caution — is the actual mistake."

Follow-up questions

• The PM ships it anyway and reports the 2.1% lift to leadership as confirmed. What do you do?
• How would your answer change if this were a pricing test instead of a UI test?

Question 3: Diagnosing a Sudden Revenue Drop

It's 9:50 AM. The CEO messages: "Revenue dropped 22% yesterday vs. the same day last week. Board call is at 10:15. What happened?" You have ten minutes before you need to say something.

Why interviewers ask this

This simulates the highest-pressure, lowest-information scenario an analyst faces. It tests triage speed and, just as importantly, whether the candidate knows the difference between "I have an answer" and "I have a hypothesis I'm confident enough to share."

Example strong answer

"In ten minutes I'm not solving this, I'm triaging it. First move: check if this is a data problem before assuming it's a business problem — is the reporting pipeline delayed, did a currency conversion break, is a major customer's data missing from yesterday's batch? That's a five-minute check and it's the single most common cause of a scary-looking overnight number. If the data looks clean, I'd segment fast along the two or three dimensions most likely to explain a swing this size: is the drop concentrated in one product line, one region, or one customer tier? A 22% aggregate drop driven by losing one enterprise account looks completely different from a broad decline across the customer base — one is a single relationship problem, the other might signal a real demand issue. I'd also do a same-day sanity check: was yesterday a holiday, a known outage, or a day we paused a campaign? By 10:15 I wouldn't have a root cause — I'd have a scoped, honest update: 'We've ruled out a data pipeline issue. The drop is concentrated in the SMB segment in the EU region, which points to either the pricing change we rolled out Tuesday or the payment processor issue support flagged yesterday. I'll have a confirmed answer by end of day.' That's more useful to a CEO on a board call than a guess dressed up as certainty, and it also protects me from having to walk back a wrong answer later."

Follow-up questions

• The CEO pushes back: "The board wants a number, not a process update." How do you respond?
• What if, by 10:10, you find two plausible causes and can't distinguish between them yet?

Question 4: Handling a Dataset With Heavy Missing Data

You're asked to analyze customer churn drivers. When you pull the dataset, 30% of rows are missing the "reason for cancellation" field, and it's not random — enterprise customers are far more likely to have it filled in than self-serve customers. What do you do?

Why interviewers ask this

This tests whether a candidate understands that missing data is rarely "missing at random," and whether they'll quietly drop rows in a way that silently biases the conclusion — a mistake that produces a confident, wrong answer that looks clean.

Example strong answer

"The first thing I would not do is drop the 30% and analyze the rest, because the missingness isn't random — it's correlated with customer segment, which means dropping those rows would systematically under-represent self-serve churn and skew every conclusion toward enterprise-specific reasons. Instead, I'd start by asking why the field is missing: is it a broken exit survey for self-serve users, a support process gap, or are self-serve users churning without ever talking to anyone? That's actually a finding on its own — if self-serve customers churn silently, that tells us something about the product experience even before we know the specific reason. I'd analyze the two segments separately rather than pooling them: for the 70% with reason data, I'd break down stated churn drivers normally. For the 30% missing it, I'd use proxy signals — last feature used, support ticket history, usage decline pattern before cancellation — to infer likely drivers rather than guessing blindly. I'd present both analyses side by side and flag the limitation explicitly in the summary: 'These findings are reliable for enterprise churn. For self-serve churn, we're inferring from behavioral data because exit reasons aren't captured — recommend fixing that data gap before the next review cycle.' That's more credible than presenting one blended number as if it represents the whole customer base, and it turns a data quality problem into an actionable recommendation instead of hiding it."

Follow-up questions

• Leadership wants one clean churn-driver ranking for a slide, not two separate analyses. How do you handle that?
• How would you decide whether the missing data itself is worth investigating as a process fix?

Question 5: Translating a Regression Model for a Non-Technical VP

You built a regression model showing that onboarding email opens, not signup source, is the strongest predictor of 90-day retention (coefficient significantly larger than any other variable, p < 0.01). You have one slide and three minutes with a VP who does not know what a regression coefficient is. Walk through what you'd say.

Why interviewers ask this

Technical correctness is table stakes; this question tests whether the analysis actually changes what someone does on Monday morning. A candidate who explains the model instead of the implication has failed the real test.

Example strong answer

"I would not put the word 'regression' or 'coefficient' anywhere on the slide. I'd lead with the action-relevant finding: 'Customers who open at least one onboarding email in their first week are roughly twice as likely to still be active at 90 days, and this matters more than which channel they signed up from.' That's the headline, in plain language, with the practical magnitude stated as a comparison, not a coefficient. Underneath, I'd show one simple visual — a bar chart comparing 90-day retention for email-openers vs. non-openers — because a picture of the effect is more convincing than the statistic that produced it. Then I'd immediately go to 'so what': 'Our current onboarding email open rate is 34%. If we can raise that to 50% through better subject lines or timing, we'd expect a meaningful lift in 90-day retention based on this relationship' — being careful to say 'associated with' rather than guaranteeing causation, since I haven't run a causal test yet. I'd close with a specific ask: 'I'd like to run an A/B test on onboarding email subject lines next sprint to see if we can move the open rate and confirm this isn't just correlation with an engaged-user type.' That gives the VP a decision to make, not a statistics lecture. If they ask a technical follow-up, I'd answer it — but I wouldn't lead with the mechanism, because the goal of the three minutes is a decision, not a demonstration of my modeling skill."

Follow-up questions

• The VP asks, "So email opens cause retention?" How do you correct that without sounding like you're hedging on your own analysis?
• How would you design a follow-up test to move from correlation to a causal claim?

Question 6: Prioritizing Competing Stakeholder Requests

On the same morning, Sales asks for a win-rate breakdown "needed for a client call in an hour," Product asks for a feature-usage report "for a roadmap meeting tomorrow," and your manager asks for a data quality audit "whenever you get a chance." You can't do all three well today. How do you decide what to do?

Why interviewers ask this

Analysts get more requests than hours in the day, and this tests whether the candidate can triage by actual business stakes rather than by who asked loudest or most recently.

Example strong answer

"I'd start by getting real information instead of guessing at urgency — I'd ask Sales what specifically they need for the call, because 'win-rate breakdown' in an hour might mean a full analysis or might mean three numbers I can pull in ten minutes. Often the loudest request is also the fastest to satisfy once you scope it down. Then I'd triage by a combination of true deadline and business impact: the Sales request has a hard external deadline — a client call can't be rescheduled — so if it's genuinely quick, I'd knock it out first even if small. The Product report has a deadline tomorrow, which gives me room, but roadmap decisions affecting the next quarter are high-stakes, so I'd block real time for it today rather than tomorrow morning. My manager's data quality audit has no deadline stated, which usually means it's important but not urgent — I'd message back with a specific time I'll deliver it rather than letting it silently slip, because 'whenever you get a chance' from a manager often means 'this matters, I'm just being polite.' I'd also proactively communicate the plan to all three people rather than silently deciding and hoping no one notices — something like 'Sales numbers by 10am, Product report by end of day, audit by Thursday — flag me if any of these timelines don't work.' That turns a silent prioritization call into a visible, negotiable one, which protects me if someone's expectations were different from what I assumed."

Follow-up questions

• Your manager says the audit is actually blocking a compliance deadline you didn't know about. How does that change your plan?
• What do you do if all three genuinely need to be done in full today, with no room to scope any of them down?

Question 7: Debugging a SQL Join That's Duplicating Rows

You write a query joining orders to customers to get total revenue per customer. The total comes out 3x higher than the number in the finance system. What's your debugging process?

Why interviewers ask this

This is a deliberately common, deliberately unglamorous bug, and it tests whether the candidate has a systematic debugging process or just guesses randomly until something looks right.

Example strong answer

"A number that's roughly a clean multiple too high — 3x specifically — is almost always a join fan-out, not a calculation error, so I'd start there before checking the math. I'd check the cardinality on both sides of the join: if the customers table has multiple rows per customer — say, one row per address, or a slowly-changing-dimension table with historical versions — then joining orders to customers would multiply each order by the number of customer rows that match, silently inflating revenue. I'd verify by running a count of distinct customer IDs vs. total rows in the customers table before doing anything else; if those numbers don't match, I've found it. If the join keys look clean, I'd check for duplicate rows in the orders table itself, which can happen from a pipeline that reprocesses data without deduplication, or from a source system that logs an order multiple times across status changes. I'd isolate a single customer, manually verify their real order history against the finance system, and trace exactly where the extra rows appear in my query's intermediate output rather than only looking at the final aggregate — debugging a JOIN from the final number backward is much slower than checking each step forward. Once I find the cause, I'd fix it properly, either by deduplicating before the join or by joining to a filtered, one-row-per-customer version of the table, and I'd also flag it to whoever owns that table, because if I hit this bug, other analysts querying it will too."

Follow-up questions

• What if the discrepancy isn't a clean multiple, like 3x, but an odd number like 1.4x — does your process change?
• How would you build a check into your workflow to catch this kind of error before it reaches a stakeholder?

Question 8: Building a New KPI From Scratch

The company just launched a collaboration feature with no existing metrics. Leadership wants "a KPI to track if it's working" by next week. How do you approach defining it?

Why interviewers ask this

This tests whether a candidate can operate without a pre-built dashboard to lean on, and whether they understand that a bad KPI, once adopted, is worse than no KPI because it drives decisions in the wrong direction.

Example strong answer

"Before picking a metric, I'd get clear on what 'working' actually means to leadership — are they trying to prove the feature drives retention, drives revenue, or just gets adopted at all? Those are different questions requiring different KPIs, and skipping this step is how teams end up optimizing a vanity metric that doesn't match the actual goal. Say the goal is genuine engagement, not just trial. I'd avoid a metric like 'number of times the feature was opened,' because that rewards accidental clicks and doesn't distinguish real usage from noise. Instead I'd define something like 'percentage of active teams with at least 3 collaborative actions in a 7-day window,' because it requires repeated, intentional use and it's team-level, which matches how a collaboration feature actually gets adopted — one person doesn't collaborate alone. I'd also define a secondary metric to catch a false positive: if usage is high but concentrated in a tiny number of power-user teams, that's a different story than broad adoption, so I'd track the distribution, not just the average. Before finalizing, I'd sanity-check the definition against edge cases: does a bot or test account count, does re-opening the same document count as a new action, what's the right time window given the feature just launched and doesn't have a full week of data yet. I'd deliver the KPI with its exact definition written down and one sentence on what it will and won't tell us, so leadership doesn't over-interpret it in three months when someone asks 'is this feature succeeding' and expects the metric to answer questions it was never built to answer."

Follow-up questions

• Leadership wants the KPI to also predict revenue impact. How do you handle that expectation?
• Two weeks in, the metric shows high adoption but support tickets about the feature are rising. Does that change how you report the KPI?

Question 9: Defending Your Conclusion Under Pushback

You present an analysis showing that a popular feature is actually not driving upgrades — upgrade rates are the same with or without it. A senior stakeholder who championed the feature says, "I don't buy this, run it again." What do you do?

Why interviewers ask this

This tests composure and intellectual honesty under social pressure — whether the candidate caves to seniority, digs in defensively, or engages the pushback as useful signal.

Example strong answer

"I wouldn't take 'I don't buy this' as just resistance — I'd treat it as a request for more rigor and ask what specifically seems off to them, because senior stakeholders often have context I don't, like a customer segment or timing detail that could genuinely explain a real flaw in the analysis. If they can point to something concrete — a cohort that should be excluded, a confound I didn't control for — I'd rerun it accounting for that, and I'd be glad to, because a wrong conclusion presented confidently is worse for everyone than taking an extra day to get it right. If their objection is more like 'it just doesn't feel right' with nothing specific, I'd walk back through my methodology with them step by step rather than re-running the same analysis and hoping for a different number, which wouldn't actually address their concern and would just waste time. I'd also proactively pressure-test my own finding before they ask again: did I control for customers who had access to the feature but never used it, is there a lagging effect where upgrades happen months after feature exposure, is the sample large enough to detect a real but modest effect. If, after all that, the finding holds, I'd say so clearly and respectfully: 'I've checked for the confounds we discussed and the result holds — I understand it's not what we expected, and I'm happy to have someone else review my methodology if that would help build confidence.' Offering a second reviewer isn't defensive, it's confidence — it shows I trust the analysis enough to have it checked rather than just insisting I'm right."

Follow-up questions

• What if a second analyst reviews it and gets a slightly different number — how do you reconcile that publicly?
• How do you handle it if the stakeholder has the authority to just ignore your finding and proceed anyway?

Question 10: Forecasting With Limited Historical Data

Finance needs a Q3 revenue forecast for a product that launched five months ago — you have five months of data, all from before the biggest sales push starts. How do you build a forecast you'd actually stand behind?

Why interviewers ask this

This tests whether a candidate will produce a falsely precise number to satisfy the request, or communicate uncertainty honestly while still being useful — a common failure mode is either refusing to forecast at all, or forecasting with unwarranted confidence.

Example strong answer

"Five months of data, especially pre-sales-push, isn't enough to trust a single trendline extrapolation, so I wouldn't just fit a growth curve and report one number. I'd start by building a range instead of a point estimate: a conservative case assuming growth continues at the current pace, and an upside case incorporating the expected impact of the sales push, benchmarked against how similar pushes affected comparable products historically if that data exists. I'd be explicit about which assumptions drive the biggest swing between the two — probably the sales team's ramp speed and close rate on the new push — so Finance knows exactly what to watch to know which scenario is playing out. I'd also flag the specific risks a simple trendline would miss: seasonality we haven't observed yet since we only have five months, the possibility that current growth is driven by early-adopter demand that won't sustain, and any known one-time spikes in the existing data that shouldn't be extrapolated forward. Rather than delivering 'Q3 revenue will be $X,' I'd deliver 'Q3 revenue is likely between $X and $Y, with our best estimate at $Z, and here are the two things most likely to move us toward the high or low end.' I'd also commit to revisiting the forecast once we have a few weeks of actual sales-push data, since a forecast built on pre-launch data has a natural expiration date. Finance can still plan with a range — what they can't safely do is plan with a false-precision number that collapses the moment a key assumption turns out wrong."

Follow-up questions

• Finance says they need one number, not a range, for the board deck. How do you respond?
• The sales push underperforms in week one of Q3. Do you revise the forecast immediately or wait for more data?

Preparation tip

Across every question in this bank, the common thread isn't technical skill — it's whether the candidate treats a number as the end of the analysis or the start of it. The candidates who get offers are the ones who instinctively ask "why might this be misleading" before they ask "what does this tell us," and who can say "I don't know yet, here's my plan to find out" without it sounding like a weakness. Practice narrating your reasoning out loud, not just your conclusion — interviewers are grading the path, not the destination.