Data Analyst interview practice

Data Analyst interview at a glance

Rounds

Usually three — a screen, a SQL or case round, and a stakeholder round

Length

30–60 minutes; the SQL round is often live and shared-screen

The round that fails most people

Not SQL. Explaining a result to someone who will act on it

SQL that actually appears

Joins, group-by, window functions. Rarely anything more exotic

Almost always asked

A metric definition question — "how would you measure this?"

Prep that pays

Rehearsing one analysis you have done, told to a non-technical listener in two minutes

What actually happens in a Data Analyst interview

1. 1

   Screen~20 min

   Tools you use daily, the size and shape of the data you have handled, and who consumed your output. The last one matters more than candidates expect — an analyst whose work went to a director is doing a different job from one whose work went into a shared folder.

2. 2

   Live SQL~45 min

   A shared screen, a small schema and three or four questions of rising difficulty, ending in a window function or a self-join. The interviewer is watching whether you check the grain of the table and whether you notice nulls before they bite, not whether you type quickly.

3. 3

   The metric question~30 min

   "How would you measure whether this feature worked?" There is no correct answer waiting to be found. You are being scored on whether you convert a vague business ask into something countable, name what would confound it, and say what you would do if the number moved the wrong way.

4. 4

   Case or take-home walkthrough~45 min

   Either a dataset to interpret live or a discussion of work you brought. The failure mode is narrating what you did step by step instead of leading with what you found and what should change because of it.

5. 5

   Stakeholder round~30 min

   Frequently with the manager who will consume your analysis rather than an analyst. They are checking whether you can be trusted in front of a business audience, and whether you push back when asked for a number that would mislead.

What this interview assesses

Sample Data Analyst interview questions

A feel for the kind of questions you’ll face. The real interview reacts to your answers with live follow-ups — these are examples, not the exact set.

1. 1.Sign-ups dropped 15% last week. How would you find out why?

   What lands: Structure it — segment by channel, device, geography, time — before guessing a cause. Rule things out; don't jump to the first story.

2. 2.You're handed a dataset with missing values and obvious duplicates. What do you do first?

   What lands: Understand why the data is messy before you clean it. Say how you'd handle nulls and dupes, and what you'd check before trusting the result.

3. 3.A stakeholder asks for 'the conversion rate.' Why is that not a simple request?

   What lands: Define it — over what window, which denominator, which events. The good answer surfaces the ambiguity instead of returning one number.

4. 4.Your analysis suggests something leadership won't want to hear. How do you present it?

   What lands: Lead with the finding and your confidence in it, show the method, and don't soften the number into meaninglessness. Honesty is the job.

5. 5.How do you make sure a dashboard you built is actually correct?

   What lands: Point to real checks — reconcile to a known total, spot-check rows, test edge cases — not just 'I review it'.

The job description it’s built around

The free taster rehearses against this realistic Data Analyst posting. In a full rehearsal you can paste the exact job you’re targeting instead.

Data Analyst (0–3 yrs) · Analytics Team · Bengaluru

About the role
We're hiring a data analyst to help the business make decisions with evidence instead of instinct. You'll pull the data, find what matters in it, and explain it to teams that don't speak SQL.

What you'll do
- Query and clean data from our databases and tools (SQL + spreadsheets)
- Build dashboards and reports that people actually use
- Investigate "why did this number move?" questions end to end
- Define metrics precisely so teams argue about decisions, not definitions
- Present findings and a clear recommendation to non-technical stakeholders
- Sanity-check your own work before it ships

What we're looking for
- Any graduate with strong quantitative reasoning; 0–3 years, freshers welcome
- Comfort with SQL and spreadsheets; a BI tool (Power BI/Tableau/Looker) a plus
- The instinct to question a number before trusting it
- Clear written and spoken communication
- Curiosity — you chase the "why", not just the "what"

Nice to have
- Python/pandas exposure
- A portfolio or project analysing a real dataset

Data Analyst interview — the specifics worth knowing

The SQL asked in analyst interviews is narrower than the SQL people revise. Joins, aggregation, and window functions cover the overwhelming majority; recursive queries and query planning almost never appear.

How we know: Interviewers ask what the job uses daily, and analyst work is dominated by aggregation over event and transaction tables. Look at the queries in your own recent work for confirmation.

Checking the grain of a table before joining is scored, even when the candidate never says the word. Silently producing double-counted rows is the most common way a live SQL round is failed.

How we know: Fan-out on a join is the classic analytics bug and it produces plausible-looking wrong numbers rather than an error. State what one row represents before you join and the problem cannot happen unnoticed.

The metric-definition question has no right answer and is not looking for one. It is looking for a countable definition, the confound you anticipated, and what you would do if the result contradicted the plan.

How we know: The prompt is open by design. If a single correct metric existed the company would already be using it and would not need to ask.

Leading a walkthrough with the finding rather than the method is the difference between a competent answer and a strong one, and interviewers rarely say so out loud.

How we know: The audience for real analysis is a decision-maker with limited time. The interview mirrors the job, so the structure that works in a meeting is the structure that scores.

You will usually be asked what you would do if a stakeholder wanted a number presented in a way you thought was misleading, and the expected answer involves saying so rather than complying quietly.

How we know: Analysts sit between data and decisions, so this pressure is part of the role. Any real example, however small, answers it better than a hypothetical stance.

Dashboard tools matter less than they appear to. Naming the tool is a screen question; what is assessed later is whether anyone changed a decision because of what you built.

How we know: Tools are learnable in weeks and are treated that way by hiring managers. Prepare one example of a decision that moved and the tool question answers itself.

Nulls, duplicates and timezone handling are the three data-quality traps most often planted deliberately in a live round.

How we know: They are the errors that survive review because they produce output rather than failures. Say aloud that you would check for them and you have already passed the part being tested.

Statistical significance comes up but rarely in depth for an analyst post — being able to say plainly what a p-value does and does not tell you is usually the whole requirement.

How we know: The depth expected scales with the title; a data-scientist loop probes further. Plain, correct phrasing outperforms a half-remembered formal definition.

Common mistakes — and what to do instead

• Joining tables in a live round without saying what one row represents.

  State the grain of each table first. It takes eight seconds and it prevents the double-counting that quietly fails the round.

• Walking through an analysis chronologically, from data pull to conclusion.

  Open with the finding and the decision it should drive, then explain how you got there. Chronology is how you did the work, not how anyone wants to hear it.

• Answering a metric question with one number and stopping.

  Give the metric, the thing that would confound it, and one guardrail you would watch alongside it. A single number with no counterweight is what produces the dashboards nobody trusts.

• Listing every tool you have touched.

  Name what you use daily, then spend the time on a decision your analysis changed. Tool lists are the least differentiating thing in an analyst interview.

Preparation checklist

• Rehearse joins, group-by and one window function against a small schema
• Practise saying the grain of a table out loud before writing a join
• Prepare one analysis told finding-first, in two minutes, with no jargon
• Prepare a metric definition with its confound and a guardrail
• Have one example where an analysis of yours changed a decision
• Have one example where you pushed back on how a number was going to be presented
• Be able to say plainly what a p-value does not tell you
• Check your own recent queries for the null and duplicate cases you handled

Data Analyst interview — FAQs

Related interviews

• Data Scientist
• Business Analyst
• Financial Analyst
• Capgemini Interview

How to rehearse this exact thing

• Explaining a result to someone who will act on it

  The rehearsal makes you say it aloud to a listener who asks the follow-ups a business stakeholder asks. The report shows whether you led with the finding or with the method.

• The open metric question

  Asked without a correct answer waiting, the way it is asked in the room. The report flags whether you named a confound or gave a bare number.

• Pushing back on a misleading framing

  Practised as a spoken exchange, because the difficulty is tone rather than content. The report tells you whether you held the position or softened it away.