GROUND TRUTH · DATA ANALYSIS

A Data Analyst Interview May Hand You a Business Problem, Not SQL

Getting the right rows out of a table is the easy half of the job.

A correct query isn't the same as understanding what the business needed to know.

By Prashanth Jakkula · Published 18 September 2026 · Researched from job postings, engineering references, and public practitioner accounts, then written and checked by the author before publication. AI tools may help with research and editing. See our Editorial Policy for how articles are produced and reviewed, or About HireSetu for who operates it.

A candidate preparing for a data analyst interview typically expects SQL questions: write a query to find the top five customers by revenue, join two tables and filter on a date range, calculate a running total with a window function. That preparation matters and does get tested. But a growing number of interviews, especially for roles closer to the business than to pure data engineering, open with something that does not look like a SQL question at all: "Sales dropped 15% last month. What would you do?" A candidate who has only practiced writing queries can be thrown by this, because there is no table schema in front of them and no obvious query to write. That reaction reveals exactly the gap the question is designed to find.

The query was never the hard part

Writing a technically correct SQL query is a bounded, learnable skill: join the right tables, filter correctly, aggregate correctly, and the database will return an accurate result. What the database cannot tell you is whether you asked it the right question in the first place. "Sales dropped 15%" is not itself a query-writable statement; it is a business observation that could have dozens of underlying causes, and a query written before understanding which cause is being investigated is likely to answer a question nobody asked. This is the real content of "business understanding" in a data-analyst role: not extra domain trivia, but the discipline of clarifying what decision the analysis is meant to support before touching a keyboard.

What candidates expect vs what a business-problem question tests

A 15% drop can mean several different things

A 15% revenue decline compared to what: last month, the same month last year, a forecast? Across every product, or concentrated in one region or category? Is it a drop in the number of transactions, a drop in average order value, or both? Did anything change in how the data itself is captured or reported during that period: a new tracking system, a change in how refunds are recorded, a data pipeline that partially failed? Each of these produces the same headline number, "sales dropped 15%," and each one points toward a completely different investigation and a completely different business response. An analyst who starts writing queries before narrowing down which of these is being asked about risks producing a technically correct answer to the wrong question, and a technically correct answer to the wrong question is, from the business's point of view, not correct at all.

What a strong response to this kind of question sounds like

A strong candidate does not panic at the absence of a schema. They start by asking clarifying questions out loud: is this compared to last month or last year, is the drop consistent across all products or concentrated somewhere, has anything changed in the data pipeline recently, is this revenue or units sold. Only after narrowing the scope does a reasonable candidate start describing what they would query: segment the drop by product category and region first to see where it is concentrated, then check whether it is a volume problem or a price/mix problem, then check for any known operational changes around that time window. This sequence, clarify, segment, investigate, then conclude, is what the interviewer is listening for, and it is a sequence that exists independently of any specific SQL syntax.

Two ways the same interview question can go

The correct rows and the correct conclusion are not the same thing

It is entirely possible to write a flawless query, correct joins, correct filters, correct aggregation, and still reach a wrong business conclusion, because the query answered a narrower or different question than the one that mattered. A query that shows "average order value dropped 15% in March" is accurate, but if March also happened to be a month with an unusually high number of small promotional orders that get counted differently, the "drop" may be a reporting artifact rather than a real change in customer behavior. Interpreting a number responsibly means asking what else could explain the pattern before presenting it as the explanation, and that habit of checking alternative explanations before committing to a conclusion is very hard to fake in an interview, which is exactly why interviewers who care about this skill reach for a business-scenario question instead of another syntax question.

The business-scenario question also tests how you handle being wrong

A less obvious part of what these interviews test is how a candidate responds when the interviewer pushes back on an early hypothesis: "actually, we already checked, it's not the pipeline; the pipeline is fine." A candidate who becomes defensive, or who abandons the systematic process entirely and starts guessing at other explanations, reveals something different than a candidate who absorbs the new information calmly and adjusts: "okay, if the pipeline is confirmed fine, the next thing I would check is whether this is a mix-shift issue, has the composition of what is being sold changed, even if total volume looks stable." Interviewers frequently build these correction moments into the conversation deliberately, because real analytical work is full of dead ends and revised assumptions, and a candidate's ability to update smoothly rather than defensively is a genuine preview of what working with them on a real ambiguous problem would be like.

Data quality is usually the first thing an experienced analyst checks, not the last

A candidate newer to the field often treats a data-quality problem as an edge case to consider only if the numbers look strange after the fact. An experienced analyst treats it as a default suspicion, checked early, precisely because pipeline issues are common and produce results that look completely plausible on the surface. A dashboard showing a sudden drop in signups is just as likely to reflect a broken tracking event that stopped firing correctly as it is to reflect a genuine drop in user interest, and both produce exactly the same visual pattern on a chart. Before proposing a business explanation for a change in a metric, a careful analyst checks whether the underlying event volume, the data pipeline's recent deploy history, and any known upstream changes could plausibly explain the pattern as an artifact rather than a real signal. Skipping this check and moving straight to a business narrative is one of the more common ways a confident-sounding analysis turns out to be built on a broken assumption.

A good answer states its own confidence level

A subtler skill that separates a strong response from an adequate one is being explicit about how confident the analysis is, rather than presenting every conclusion with the same flat certainty. "Revenue dropped because of fewer transactions in the enterprise segment" sounds definitive; "revenue dropped, and the pattern is concentrated in the enterprise segment specifically, though I would want to rule out a reporting change in how enterprise deals get logged before treating this as confirmed" is a more honest and, in most real workplaces, more useful answer, because it tells the person receiving the analysis exactly how much weight to put on the conclusion and what would need to be checked before acting on it. Interviewers who ask business-scenario questions are often specifically listening for this kind of calibrated honesty, because an analyst who always sounds equally certain is one whose confident-sounding wrong answers are harder to catch before they influence a real decision.

Preparing for a business-scenario interview question

• Practice pausing and asking two or three clarifying questions before proposing any analysis, even in a mock interview with no schema in front of you.
• For any metric you might be asked to investigate, list at least three different underlying causes that could produce the same headline number.
• Practice describing your investigation as a sequence, segment first, then narrow, then conclude, rather than jumping straight to a final number.
• When you do reach a conclusion, be ready to name what would make you doubt it.
• Remember that SQL fluency is still expected. This is an addition to query skill, not a replacement for it.

All Ground Truth articles · Career Insights · Discover jobs · Companies