About Data Analyst interviews
Data Analyst interviews typically run across three or four stages and are designed to test whether you can move fluently from a business question to a defensible answer using data. Expect an initial recruiter screen covering tooling (SQL, Excel, a BI tool like Tableau, Power BI or Looker, and increasingly Python or R), followed by a hiring manager conversation that probes how you scope problems, work with stakeholders and prioritise competing requests. The technical stage is usually the make-or-break round: a live SQL test (joins, window functions, CTEs, aggregation logic) and often a take-home case study where you're given a messy dataset and asked to produce insights, visualisations and a recommendation. A final round tends to focus on stakeholder communication, business acumen and culture fit, sometimes with a presentation of the case study to non-technical interviewers. The most common stumbles are candidates who can write SQL but can't explain why a metric moved, those who jump to dashboards before clarifying the question, and those who present analysis without a clear 'so what'. Hiring managers are screening for analytical rigour paired with commercial judgement — they want someone who challenges a vague brief, picks the right level of statistical depth, and translates findings into language a product manager or commercial lead can act on.
Typical stages
- Recruiter screen
- Hiring manager interview
- SQL / technical assessment
- Case study or take-home
- Final stakeholder / values round
Common formats
- Behavioral STAR
- Live SQL coding
- Take-home case study
- Dashboard or portfolio review
- Stakeholder roleplay
- Metrics deep-dive
What hiring managers screen for
- Fluency in SQL beyond basic SELECTs — comfort with joins, window functions and query optimisation
- Ability to translate an ambiguous business question into a structured analytical plan
- Storytelling with data: choosing the right chart, the right metric, and a clear recommendation
- Stakeholder management — pushing back on bad briefs without losing the room
- Commercial curiosity — understanding why a KPI matters, not just how to calculate it
Red flags to avoid
- Producing charts without interrogating data quality or sample size
- Memorised SQL patterns but no ability to debug or explain trade-offs
- Reporting numbers without a 'so what' or recommendation
- Defensive responses when interviewers challenge methodology
- Treating every request as a ticket to execute rather than a problem to scope
Primary questions (14)
Behavioural
Tell me about a time you delivered an analysis that changed a business decision.
Why this comes up: Hiring managers want evidence you produce analysis with commercial impact, not just outputs.
Prep pointers
- Pick an example where the decision would genuinely have gone the other way without your work — vague 'informed the team' stories fall flat.
- STAR Situation: name the business context and the decision on the table. Task: clarify why this analysis was needed and who the stakeholder was.
- STAR Action: walk through your analytical approach briefly, but spend more time on how you framed and communicated the insight.
- STAR Result: quantify the outcome — revenue, cost saved, conversion lift — and name the decision-maker who acted on it.
- Avoid technical deep-dives that obscure the business value; the interviewer is testing commercial judgement, not SQL.
Technical
Walk me through how you'd write a SQL query to find the second-highest salary per department, and how you'd optimise it on a large table.
Why this comes up: This tests window functions, edge-case handling and query performance — staples of any data analyst screen.
Prep pointers
- Be ready to discuss DENSE_RANK vs RANK vs ROW_NUMBER and why the choice matters when ties exist.
- Talk through how you'd handle departments with only one employee — don't assume the data is clean.
- On optimisation, mention indexing on the partition column, avoiding SELECT *, and considering whether a correlated subquery would be slower than a window function.
- Verbalise your thinking as you write — interviewers score reasoning, not just the final query.
- Common failure: jumping straight to syntax without confirming whether ties should be treated as one rank or distinct.
Technical
How would you investigate a sudden 15% drop in a key metric, for example daily active users?
Why this comes up: Root-cause analysis is a daily reality for analysts and a strong test of structured thinking.
Prep pointers
- Start by verifying the data itself — broken pipeline, tracking change, or timezone issue before assuming a real drop.
- Segment the drop: by platform, geography, user cohort, acquisition channel, app version — show you have a mental decision tree.
- Mention correlating with external events: releases, marketing changes, outages, seasonality, competitor moves.
- Be explicit about hypothesis-driven analysis rather than 'I'd look at everything'.
- Avoid the trap of jumping to a conclusion before ruling out instrumentation issues.
Technical
Explain the difference between correlation and causation, and how you'd communicate this to a non-technical stakeholder pushing for a causal claim.
Why this comes up: Analysts are constantly under pressure to make causal claims from observational data — this tests rigour and diplomacy.
Prep pointers
- Have a concrete example ready (e.g. ice cream sales and drowning) but also a work example where you held the line.
- Mention confounders, reverse causality and selection bias in plain language — no jargon dump.
- Be ready to explain when an A/B test, quasi-experiment or diff-in-diff would be needed to make a causal claim.
- Show you can say 'no, but here's what we can say' rather than just refusing the request.
- Common failure: being technically correct but politically tone-deaf with the stakeholder.
Behavioural
Describe a time you had to push back on a stakeholder's request.
Why this comes up: Analysts who only execute become report-monkeys; managers want someone who shapes the question.
Prep pointers
- Choose an example where pushback led to a better outcome, not just a saved-you-time outcome.
- STAR Action should detail how you reframed the request — what you asked, what you offered as an alternative.
- Emphasise the relationship: did the stakeholder come back to you for the next project?
- Avoid stories that paint the stakeholder as foolish — interviewers read this as a culture warning.
- Show curiosity about the underlying business need, not just the literal ask.
Situational
You're given a messy CSV with inconsistent date formats, missing values and obvious duplicates. Walk me through your first hour with it.
Why this comes up: Data cleaning is 60-70% of the job and interviewers want to see disciplined habits.
Prep pointers
- Start with profiling: row counts, column types, distributions, null percentages — show you don't dive into analysis blind.
- Talk through how you'd decide whether to drop, impute or flag missing values based on context.
- Mention documentation: how you'd record assumptions so the analysis is reproducible.
- Reference tools you'd actually use — pandas profiling, dbt tests, SQL checks — be specific.
- Common failure: skipping straight to the 'fun' analysis and missing data quality issues that invalidate it.
Situational
A senior leader asks for a dashboard by end of day for a board meeting. What do you do?
Why this comes up: Tests prioritisation, scoping and pressure handling — all daily realities.
Prep pointers
- Lead with clarifying questions: what decision is the dashboard supporting, who is the audience, what 3-5 numbers actually matter.
- Show you can negotiate scope down to what's achievable while still useful.
- Discuss the trade-off between a polished dashboard and a clean one-pager — sometimes the latter is better for a board.
- Mention reusing existing data models rather than building from scratch under time pressure.
- Avoid sounding like you'd silently grind for 8 hours without asking questions.
Competency
How do you decide which visualisation to use for a given dataset and audience?
Why this comes up: Chart choice is a visible signal of analytical maturity and audience awareness.
Prep pointers
- Anchor your answer in the question being asked: comparison, composition, distribution, relationship, trend.
- Mention audience: executives want one number with context; analysts want distributions and confidence intervals.
- Be ready to critique a bad chart — pie charts with 12 slices, dual-axis traps, truncated y-axes.
- Reference principles (Cleveland, Tufte, or pre-attentive attributes) without being pretentious.
- Common failure: defending a chart because the BI tool made it easy, not because it answered the question.
Behavioural
Tell me about a time you made a mistake in an analysis. How did you handle it?
Why this comes up: Errors happen; interviewers want to see ownership, communication and process improvement.
Prep pointers
- Pick a real mistake with real consequences — not 'I once misspelled a column name'.
- STAR Action: focus on how quickly you flagged it, who you told, and how you communicated the correction.
- STAR Result: what process changed afterwards — peer review, dbt tests, a checklist?
- Show emotional maturity — no blaming the data team, the stakeholder or the tool.
- Avoid the humblebrag mistake ('I was just too thorough').
Competency
How do you define a good metric, and can you give an example of a metric you've seen abused or misinterpreted?
Why this comes up: Metric design is increasingly part of an analyst's role, especially in product and growth contexts.
Prep pointers
- Cover the criteria: actionable, comparable, hard to game, tied to a business outcome.
- Have a concrete example of a vanity metric you've challenged (e.g. raw signups vs activated users).
- Mention input vs output metrics and leading vs lagging indicators.
- Discuss Goodhart's Law in plain English — when a measure becomes a target, it ceases to be a good measure.
- Show you think about metrics as a system, not in isolation.
Behavioural
Describe a project where you had to learn a new tool or technique quickly to deliver.
Why this comes up: The data tooling landscape moves quickly and analysts need to demonstrate learning agility.
Prep pointers
- Pick a tool that's genuinely relevant — dbt, a new BI platform, Python for a specific library — not just 'I learned VLOOKUP'.
- STAR Action: describe your learning approach (docs, peers, a small POC) rather than just 'I figured it out'.
- STAR Result: emphasise that you delivered the work, not just that you learned the tool.
- Mention how you've since shared or scaled that knowledge — a brown bag, documentation, template.
- Avoid examples that suggest you only learn when forced.
Situational
Two stakeholders bring you conflicting data requests with the same deadline. How do you handle it?
Why this comes up: Resource conflicts are constant and the answer reveals prioritisation logic and political instincts.
Prep pointers
- Avoid the trap of 'I'd just work harder' — interviewers want to see prioritisation, not martyrdom.
- Show you'd surface the conflict explicitly rather than silently picking one stakeholder.
- Talk about prioritisation criteria: business impact, reversibility of the decision, deadline rigidity.
- Mention involving your manager when the conflict is above your pay grade — that's good judgement, not weakness.
- Show you'd document the trade-off so it's visible and learnable.
Culture fit
What kind of data team and culture do you do your best work in?
Why this comes up: Tests self-awareness and whether you'd thrive in their specific environment — centralised vs embedded, hands-on vs strategic.
Prep pointers
- Research the company's data org structure beforehand — embedded analysts in product teams feels very different to a central insights team.
- Be honest about what energises you, but frame it in ways that align with what you've learned about the role.
- Mention concrete preferences: code review culture, proximity to decision-makers, autonomy vs collaboration.
- Avoid generic answers like 'I work well anywhere' — that signals low self-awareness.
- Have a question ready to turn it into a dialogue about their actual culture.
Competency
Walk me through how you'd structure an analysis to evaluate whether a recent product feature was successful.
Why this comes up: Feature evaluation is a core analyst deliverable and tests end-to-end analytical thinking.
Prep pointers
- Start with defining success — whose definition, against what baseline, over what time window.
- Discuss whether an A/B test was run; if not, what quasi-experimental approach you'd use.
- Mention guardrail metrics: a feature can boost one metric while quietly harming another.
- Cover segmentation: average effects often hide that the feature helped one cohort and hurt another.
- End with how you'd present findings and what recommendation framing you'd use (ship, kill, iterate).
More practice questions (14)
Technical
What's the difference between an INNER JOIN and a LEFT JOIN, and when would using the wrong one silently corrupt your analysis?
Why this comes up: Tests whether you understand joins as a source of data quality bugs, not just syntax.
Technical
How would you detect and handle outliers in a sales dataset?
Why this comes up: Outlier handling reveals statistical judgement and awareness of context.
Technical
Explain what a CTE is and when you'd use one instead of a subquery.
Why this comes up: Common SQL fluency check that also tests readability and maintainability awareness.
Technical
How would you calculate month-over-month retention in SQL?
Why this comes up: Cohort and retention queries are bread-and-butter for product and growth analysts.
Behavioural
Tell me about a time you presented analysis to a non-technical audience.
Why this comes up: Stakeholder communication is half the role; this tests storytelling instinct.
Behavioural
Describe a project where the data didn't tell the story you expected.
Why this comes up: Tests intellectual honesty and how you handle uncomfortable findings.
Situational
Your dashboard shows numbers that contradict another team's dashboard. What do you do?
Why this comes up: Conflicting sources of truth are endemic and reveal investigative discipline.
Situational
A stakeholder asks for 'just a quick number' that you know requires significant analysis. How do you respond?
Why this comes up: Tests scoping skills and ability to manage expectations diplomatically.
Competency
How do you document your analyses so others can reproduce or build on them?
Why this comes up: Reproducibility separates juniors from analysts who can scale their impact.
Competency
What's the difference between mean, median and mode, and when have you deliberately chosen one over another?
Why this comes up: Sanity check on statistical fundamentals plus applied judgement.
Competency
How do you decide when an analysis is 'done enough' to share?
Why this comes up: Tests pragmatism and avoidance of analysis paralysis.
Culture fit
What's a recent dataset or data story in the news that caught your attention, and why?
Why this comes up: Reveals genuine curiosity about data beyond the day job.
Behavioural
Tell me about a time you automated or streamlined a recurring analytical task.
Why this comes up: Automation mindset is a strong signal for senior potential.
Technical
Explain how you'd approach building a forecasting model for monthly revenue, even at a high level.
Why this comes up: Tests whether you can speak credibly about predictive work without overclaiming.
Get a prep pack tailored to your experience
describe.me matches these questions against your real work history,
flags your prep priorities, and gives you a STAR scaffold per question.
Start free →