Data Analyst Interview Questions & Answers (with Model Answers)

Model Answer

I analysed funnel drop-off for our signup flow and found a single verification step was losing nearly a third of users. I quantified the revenue impact and segmented to show it hurt mobile users most. I presented a clear recommendation to make the step optional, backed by the numbers. The team ran the change and conversion rose meaningfully, which validated leading with the actionable insight.

Model Answer

I start by clarifying the decision the metric will inform, because a metric with no decision behind it is vanity. I prefer metrics that are actionable, hard to game, and tied to real value rather than easy-to-collect proxies. I pair a primary metric with guardrail metrics so improving one does not quietly harm another. I always define it precisely so everyone interprets it the same way.

Model Answer

I clarify the question behind the request, because often the stakeholder needs a decision answered, not the literal number they asked for. If a metric could mislead, I explain the caveat and offer a more honest framing. I would rather slow down briefly than hand over a figure that drives a bad decision. This builds trust so people bring me the real question next time.

Model Answer

I reconcile my numbers against a trusted source of truth and sanity-check totals before publishing anything. I document my data sources, definitions, and any filters so results are reproducible and auditable. I build automated data quality checks that flag anomalies like sudden nulls or duplicate rows. I also have a peer review key analyses, because a second pair of eyes catches mistakes I am blind to.

Model Answer

I assess each request by the value of the decision it supports and its urgency, not by who shouts loudest. I clarify deadlines and the minimum useful answer for each, since a quick directional answer often beats a perfect late one. I make my queue visible so stakeholders understand the trade-offs. When everything is genuinely urgent I escalate to a manager to align on priorities rather than silently dropping work.

An INNER JOIN returns only rows with a match in both tables, while a LEFT JOIN returns all rows from the left table and matched rows from the right, with nulls where there is no match. LEFT JOIN is essential when you need to keep records that have no related row, such as customers with no orders. Choosing the wrong one is a common cause of silently missing or inflated counts.

I identify duplicates by grouping on the columns that should be unique and counting rows greater than one, or using a window function like ROW_NUMBER. Before deleting anything I investigate why duplicates exist, since they may signal an upstream join or ingestion issue. I then deduplicate deliberately, keeping the correct record based on a rule like the latest timestamp.

WHERE filters individual rows before any grouping or aggregation occurs. HAVING filters groups after aggregation, so it can use aggregate functions like SUM or COUNT. Using WHERE for row-level conditions and HAVING for aggregate conditions keeps queries correct and efficient.

Correlation means two variables move together, but that does not mean one causes the other, as a hidden third factor or coincidence can explain it. To claim causation you generally need a controlled experiment or a careful causal design that rules out confounders. I always flag when a finding is correlational so decisions are not built on a false assumption.

A window function performs a calculation across a set of rows related to the current row without collapsing them into a single output like GROUP BY does. It is useful for running totals, ranking, moving averages, and comparing a row to its group. For example, ROW_NUMBER partitioned by customer ordered by date finds each customer's first purchase.

A sales lead insisted my regional revenue figures were too low. I walked back through my pipeline and confirmed the logic, then discovered their reference report double-counted refunds. I presented the reconciliation calmly with the row-level evidence. They accepted the correction and we standardised the definition so the discrepancy could not recur.

I was rebuilding the same weekly sales report by hand, which took half a day. I rewrote it as a parameterised SQL query feeding a scheduled dashboard with automated refresh. I added data quality checks that alerted me if the source data looked wrong. The team got self-serve access and I reclaimed that day for deeper analysis.

While building a standard retention report I noticed a cohort that churned sharply at exactly thirty days. Digging in, I found a trial-to-paid conversion bug that silently cancelled accounts. I escalated with evidence to engineering, who confirmed and fixed it. The routine report ended up recovering a meaningful slice of lost revenue.

I needed to explain a multi-factor attribution analysis to the marketing team. I stripped out the modelling detail and led with a single chart showing where to shift budget. I used plain analogies for the method and kept the technical appendix available for the curious. The team acted on the recommendation and the simplicity got buy-in fast.