Data Analyst Interview Questions and Answers

I start by asking which number they expected and where they saw it, because the mismatch is usually a filter, a date range or a definition rather than a broken table. I reproduce their exact view, then query the source table directly and compare row counts and totals for the same period. If the source matches, I check the dashboard refresh time, timezone settings and any calculated field that behaves differently once a filter is applied. If the source does not match, I trace back to the upstream load and look for a partial refresh. Either way I reply with the specific cause rather than a quietly corrected chart, and I log the issue so the same question does not return next month.

When I define an active user I start from the decision the metric is meant to support, because a log-in and a meaningful action are very different things. For a product with web and mobile surfaces I would count a user as active on a given day if they complete at least one core action, such as creating a document or sending a message, and I would tie the identifier to the account rather than the device so one person is not counted twice. I would write the definition down, state the edge cases including internal accounts, bots and trials, and circulate it to the teams who use the number so we do not end up with three competing versions of the same word.

I would start by restating the question as a grain: one row per customer, revenue summed over the period, ranked from highest to lowest. Then I would inspect the orders table for how refunds, canceled orders and test accounts are stored, because those usually need excluding before any total is trustworthy. The query would join customers to orders on the customer key, filter the order date to the month in question, group by customer, sum the revenue column and order the result descending, with a limit so the output stays readable. Before I shared it I would run a total-revenue check against the finance report to confirm my filters match theirs.

Before a report goes out I check it in layers. First the arithmetic: does the total of the parts equal the whole, and does this month reconcile with last month's published figure. Then the logic: are the joins one to many where I assumed one to one, and did the date filter accidentally include or drop the boundary day. Then the presentation: is every metric labeled with its definition and period, and would a reader who missed the meeting understand the takeaway. Finally I ask a colleague to read it cold, because a second pair of eyes catches the assumption I stopped seeing hours ago.

I treat missing data as a finding rather than a nuisance to hide. First I quantify it: what share of rows are null or left at a default, and is the gap random or concentrated in one source, region or time window. If it is small and random I document the exclusion and note it in the report. If it is systematic I go back to the system that generates the field, because a broken capture process usually explains it, and I would rather delay a number than publish one built on a biased subset. Where a field is genuinely optional I report the metric with an explicit denominator and state the coverage so nobody over-reads the result.

A window function lets me calculate across a set of related rows without collapsing them, which is exactly what ranking and running totals need. If I want each customer's largest order shown alongside every order row, I partition by customer, order the rows by amount, use a ranking function and keep the top row. The same pattern gives month-over-month change with a lag function, or a cumulative total with a sum over an ordered window. The part I always check is the partition and the frame, because forgetting to partition produces a global rank and an unintended default frame quietly changes the running total.

I keep one visible queue and score requests on decision impact, deadline and effort rather than on who asked loudest. A question tied to a decision happening this week, or to a number an executive will quote publicly, goes to the top, while an exploratory request with no decision attached goes into a backlog with an honest estimate. When two teams clash I ask them to agree the priority between themselves, which usually resolves it faster than me arbitrating. I also look for the third option: if three requests are really the same question, I build one small self-serve view instead of answering it repeatedly.

I start with the decision, not the method. I would say what changed, how much it moved, over what period, and what I believe is driving it, in plain language and with one chart rather than a dense table. I avoid statistical vocabulary unless it changes the interpretation, and I state the caveat that matters, such as a tracking change, a seasonal effect or a small sample, in the same breath as the headline instead of burying it at the end. Then I stop talking and let them ask questions, because those tell me which part of the explanation landed and what they need to decide next.

I first ask whether the metric definition or the tracking changed, because a logging release explains more sudden movements than most business events do. If the instrumentation is stable I look at whether the change persists over several periods and whether an independent metric moved in the same direction, since a real shift usually shows up in more than one place. I check seasonality against the same period in prior cycles, and I look at the distribution rather than just the average, because a mean can move because of one unusually large account. If the movement is still ambiguous I say so and propose the smallest test that would settle it.

I once published a churn readout that looked like a product problem when the real cause was a billing migration that had canceled and recreated accounts. I had validated the query logic but not the underlying account history, so I caught it only when a colleague asked why long-tenured customers were leaving in a single week. I retracted the number the same day, corrected the definition to exclude migrated accounts, and reissued the analysis with the revision clearly noted. After that I added a step to every readout where I sanity-check the biggest movers against a known event calendar before presenting anything.

Reconcile totals against a trusted source, check row counts before and after each join, and test the filter boundaries before you share the output.

Report the median and a spread alongside the mean, and split the data by segment when a small group of large accounts drives the total.

Turn repeated questions into a filtered dashboard or a documented query that the requesting team can run, then retire the manual report once they adopt it.