Data analyst interview questions: SQL, case and stakeholder

SQL questions you will almost certainly face

SQL is tested in nearly every data analyst interview, either through a live coding screen, a take-home problem, or a whiteboard exercise. Most companies use LeetCode-style problems at the medium difficulty level, though some larger tech firms go harder.

The questions below come up repeatedly. Practice writing them from memory, not just reading solutions.

• Find the second-highest salary in a table (tests subqueries and DENSE_RANK)
• Calculate a 7-day rolling average of daily revenue (tests window functions and date arithmetic)
• Identify users who made a purchase in January but not in February (tests NOT EXISTS or LEFT JOIN with NULL filter)
• Return the top three products by sales in each category (tests PARTITION BY with RANK or ROW_NUMBER)
• Find duplicate rows and keep only the most recent one (tests CTEs and ROW_NUMBER)

How to answer SQL questions under pressure

Before writing a single line, restate the problem in your own words and confirm the table structure. This buys you thinking time and shows you do not make assumptions about data.

Work from the output backwards. Ask yourself what the final result set should look like, then decide which joins, filters and aggregations get you there. Write a rough skeleton first, then fill in the details.

If you get stuck on syntax, say so and keep moving. Writing pseudocode or describing the logic clearly is far better than going silent. Most interviewers will give you a hint rather than watch you freeze.

Case study questions and how to structure your answer

Case questions test whether you can turn a vague business problem into a structured analysis. A common prompt is something like: 'Our checkout conversion rate dropped 15 percent last week. How would you investigate?'

Use a four-step structure: clarify, hypothesise, analyse, recommend. First, ask one or two scoping questions (which platform, which user segment, did anything change in the product or marketing). Then list two or three hypotheses ranked by likelihood. Next, describe the data you would pull and the queries or metrics you would check. Finally, explain how you would present findings and what action you would suggest.

Interviewers are not looking for the right answer. They are looking for a methodical thinker who does not jump to conclusions. Saying 'I would first rule out a data pipeline issue before assuming user behaviour changed' signals good instincts.

1. Clarify scope: platform, time window, affected segment
2. State two or three hypotheses before touching any data
3. Describe the specific metrics and queries you would run
4. Explain how you would validate your conclusion
5. Recommend a next step or experiment

Stakeholder and communication questions

Analysts spend a large part of their time explaining findings to people who do not read SQL. Interviewers test this with questions like 'Tell me about a time you disagreed with a stakeholder about what the data showed' or 'How do you handle a request you think is the wrong question to ask?'

Use the STAR format (Situation, Task, Action, Result) but keep the situation brief. Spend most of your answer on what you actually did and what happened. Vague answers like 'I communicated clearly' tell the interviewer nothing.

A strong answer to the disagreement question might sound like: 'The marketing team wanted to report on clicks, but I thought conversion rate was the right metric because clicks were inflated by a retargeting campaign. I pulled both metrics side by side and showed that clicks were up 40 percent while conversions were flat. They agreed to switch the primary metric for that report.' That is specific, shows judgment, and shows you can influence without authority.

• Describe a time you simplified a complex finding for a non-technical audience
• How do you prioritise competing data requests from different teams?
• Tell me about a time your analysis led to a decision you later found out was wrong
• How do you push back on a request without damaging the relationship?

Questions about tools, metrics and domain knowledge

Most job postings list specific tools. Expect questions about whichever ones appear in the job description. Common ones in 2026 include dbt, Looker, Tableau, BigQuery, Snowflake and Python with pandas.

You will also be asked to define metrics on the spot. Know the standard definitions cold: DAU, MAU, retention rate, churn rate, LTV, CAC, conversion rate, and cohort analysis. If the role is in e-commerce, add AOV (average order value) and return rate. If it is in SaaS, add MRR, ARR and net revenue retention.

Domain questions are often used to test curiosity rather than knowledge. If you are asked about an industry you are less familiar with, it is fine to say 'I have not worked in that vertical, but here is how I would approach learning the key metrics quickly.' That answer is often better than a half-remembered definition.

How to use an interview assistant during the actual interview

If you are interviewing remotely and want real-time support, Break-In Bad's interview assistant listens to the interviewer's questions and shows suggested answers only you can see, even on a shared screen. Omar, the AI assistant, surfaces relevant SQL patterns, case frameworks and metric definitions as the conversation unfolds.

This is most useful for the moments when a question catches you off guard, such as an unexpected metric definition or a domain-specific case you did not prepare for. It is not a replacement for preparation, but it reduces the cost of a blank moment.