Data Analyst Interview Questions and Answers: 20 Questions You'll Actually Face

"When our product team asked why trial-to-paid conversion dropped last quarter, I started by clarifying the metric definition—were we measuring first-time conversions or including reactivations? Once aligned, I identified three tables: users, subscriptions, and events. I noticed our events table had logging gaps during a migration window, so I excluded that period. The query joined users to subscriptions with date filters, grouped by signup cohort, and calculated conversion rates. The output showed mobile signups converted at half the rate of desktop, which led us to discover a broken payment flow in the iOS app."

"It depends on why the data is missing and how much. For a recent churn analysis, 8% of customers had missing industry data. I investigated and found it correlated with signup source—self-serve signups skipped that field. That's not random, so simple mean imputation would bias results. Instead, I built a classifier to predict industry based on company size and website domain, achieving 84% accuracy. For the remaining uncertainty, I ran sensitivity analyses with different assumptions to ensure conclusions held."

"We found that users who used our mobile app had 40% higher retention than desktop-only users. The correlation was strong. But correlation isn't causation—maybe mobile users were already more engaged, and the app didn't cause anything. To test causation, we ran an experiment: we prompted a random subset of desktop users to download the app. The treatment group's retention improved by 12%, confirming the app had a causal effect, though smaller than the correlation suggested. The remaining 28% gap was selection bias—engaged users self-selected into mobile."

"I start with a clear hypothesis and success metric. For a recent checkout flow test, we hypothesized that reducing form fields would increase completion rate. I calculated sample size using our baseline conversion rate and minimum detectable effect—we needed 15,000 users per variant for 80% power. We randomized at the user level to avoid spillover, ran for three weeks to capture weekly patterns, and analyzed with a chi-square test. The variant won with p=0.02 and a 7% lift, but I also calculated confidence intervals and checked for heterogeneous effects across segments before recommending rollout."

"Recently I inherited a dashboard query that took 45 minutes. The execution plan showed a full table scan on a 500M row events table. The WHERE clause filtered by date, but there was no index on the date column. Adding a composite index on (event_date, user_id) reduced runtime to 3 minutes. I then noticed we were joining to a user table before filtering, so I restructured to filter the events CTE first, then join. Final runtime: 40 seconds."

"Our monthly revenue report showed a 15% spike that the sales team celebrated. The number felt wrong—nothing in the pipeline suggested that growth. I dug into the underlying data and found that a pricing table update had been applied retroactively, double-counting some subscription changes. The actual growth was 4%. It was uncomfortable to correct, but we caught it before the board presentation. I implemented a validation check comparing new reports against historical baselines to flag anomalies automatically."

"I start by asking what decisions the dashboard will inform. For our CEO dashboard, the answer was: where to allocate next quarter's budget and which products need intervention. That framed everything. I limited it to six metrics total—two per product line—with traffic-light indicators for targets. Drill-down exists for those who want it, but the default view answers 'is anything on fire?' in five seconds. I also added automated commentary explaining significant changes, so executives didn't have to interpret raw numbers."

"My core stack is SQL for querying, Python with pandas for transformation and analysis, and Tableau for visualization. For SQL, I've worked primarily in PostgreSQL and Snowflake—Snowflake's separation of compute and storage made it better for our variable workloads. I use Python when I need statistical analysis beyond SQL's capabilities or when building reproducible pipelines. Tableau works well for stakeholder-facing dashboards, though I've used Looker and find its semantic layer useful for ensuring metric consistency. The tools matter less than understanding when each is appropriate."

"I follow a consistent process. First, structural understanding: what tables exist, how they relate, what each row represents, what the grain is. Second, quality assessment: check for nulls, duplicates, date ranges, obvious outliers. Third, univariate exploration: distributions of key fields, looking for unexpected patterns. Fourth, bivariate relationships: correlations, cross-tabs, potential confounders. I document findings as I go, because exploration without documentation is wasted work. This usually takes a few hours and surfaces 80% of the 'gotchas' I'll encounter later."

"A p-value answers the question: if this marketing campaign had no real effect, how likely is it we'd see results this extreme just by chance? When we say p=0.03, we're saying there's only a 3% chance the results are random noise. That's not proof the campaign worked, but it's strong enough evidence to act on. Think of it like a courtroom—we're not proving innocence or guilt beyond all doubt, we're deciding if the evidence is strong enough to make a decision."

"Our marketing team planned to cut podcast advertising because CAC looked 3x higher than paid search. I was skeptical because attribution for podcasts is notoriously difficult. I built a time-series model correlating podcast ad timing with branded search volume and direct traffic, controlling for other campaigns. The analysis showed podcast was driving 40% of our branded search conversions, which were being attributed to paid search. When I included this halo effect, podcast CAC was actually lower than paid search. Marketing reversed the decision and increased podcast spend by 25%."

"The VP of Sales asked for a dashboard showing which leads were 'most likely to close' updated hourly. The request had issues: our lead scoring model was trained on weekly data and would perform poorly at hourly granularity, plus the sales team's process couldn't actually act on hourly updates. Instead of just saying no, I dug into the underlying need—he was frustrated with lead prioritization. I proposed a weekly lead score with daily updates for leads that changed significantly. That addressed his real problem without building something that would mislead users."

"I evaluate requests on three dimensions: business impact, urgency, and effort required. High-impact, time-sensitive, and low-effort requests come first. But I've learned that perceived urgency often isn't actual urgency, so I ask clarifying questions: what decision does this inform, when do you need it, what happens if it's delayed? I maintain a simple prioritization log that's visible to stakeholders so they understand where their request sits and why. Transparency reduces 'why isn't this done yet' conversations significantly."

"I built a customer segmentation model that I was proud of—technically elegant, good statistical properties. But adoption was near zero. Product managers found the segments unintuitive and didn't trust them. I'd optimized for statistical validity without considering usability. The failure taught me to involve stakeholders in defining segments upfront, even if it means sacrificing some technical purity. My next segmentation project started with workshops to understand how teams conceptualized customers, and adoption was immediate."

"I balance structured and informal learning. For structured: I complete one significant course per year—last year was a causal inference specialization that directly improved our experimentation practice. For informal: I follow a curated list of practitioners on Twitter, read Towards Data Science selectively, and participate in our internal analytics guild where we review each other's work. The most valuable source is actually peer code review—seeing how experienced analysts approach problems teaches more than any course."