50 Data Analyst Interview Questions, With Real Interview Examples

50 Data Analyst Interview Questions, With Real Interview Examples

There is no single data analyst interview process. Some companies run a SQL screen followed by a case study and an HR call. Others fold SQL and Excel into one technical round, test Python only for product-company roles, or spread behavioural questions across every conversation rather than saving them for a final round. A process with three rounds and one with six can both be entirely normal for the same job title.

What is consistent, across the documented interview reports this guide draws on, is not the number of rounds but the capabilities being evaluated: can you actually query a database, can you turn a messy spreadsheet into something usable, can you reason about whether a result is real or noise, can you structure an ambiguous business question, and can you communicate all of that to someone who doesn't share your technical background. This guide organises fifty questions around those capabilities rather than around an assumed sequence of rounds, so you leave knowing what to prepare rather than trying to predict exactly how many conversations you'll have.

How we selected these questions

Every question below falls into one of three evidence categories, labelled honestly rather than blurred together:

Reported means the question is documented in an actual candidate interview experience, typically shared directly on Glassdoor or in a first-hand account on a forum like Blind, with the company and role attached where the source supports it.

Common means the question appears repeatedly across credible interview-preparation resources, technical interview platforms, or aggregated candidate reports, but without a single clean first-hand attribution to one company and one candidate.

Practice means we could not find a documented report of the question being asked, and we've labelled it as such rather than pretending otherwise. It's included because it tests a capability that shows up constantly in the reported and common questions around it.

We prioritised reported and common questions wherever they existed, removed repetitive or weakly supported entries, and only fell back to a practice question when a skill area genuinely needed coverage the evidence didn't provide. Where a source documents a Data Scientist or Business Analyst interview rather than a Data Analyst one specifically, we've said so; the underlying question is directly relevant to analyst interviews too, and pretending otherwise would be less honest, not more.

Evidence labels used throughout this guide:

🟢 Reported: documented in a first-hand candidate interview experience, with the company and role named where the source supports it.

🔵 Common: appears repeatedly across credible interview-preparation resources or aggregated candidate reports, without a single clean first-hand attribution.

⚪ Practice: no documented report was found. Included because it tests a capability that shows up constantly in the reported and common questions around it.

How to use this guide

First pass: scan all fifty questions and mark the ones you can't answer confidently in under a minute. That's your actual preparation list, not the whole guide.

Second pass: answer each flagged question out loud or in writing before reading the guidance underneath it. The value is in noticing where your explanation breaks down, not in reading someone else's answer first.

Third pass: practise under the conditions you'll actually face. Write SQL without autocomplete. Say a case-study answer out loud with a timer running. Rehearse your two or three behavioural stories until they don't sound rehearsed.

Part 1: The initial conversation

Before any technical evaluation, most processes open with a conversation that tests communication and fit far more than depth. The interviewer here, often a recruiter without a technical background, needs to be able to summarise you accurately to whoever interviews you next.

1. Walk me through your background, or tell me more about yourself. What it's really testing: Whether you can summarise your own story clearly in under two minutes. How to approach it: Structure it as a short arc, where you started, what you learned, why you're moving toward this role, rather than reciting your resume line by line. Evidence: 🟢 Reported in a Senior Data Analyst interview at Traba, via Glassdoor.

2. Why do you want to work here? What it's really testing: Whether your interest is specific or generic. How to approach it: Reference something concrete about the company's product, data problems, or recent direction, not "I love data" without a reason attached. Evidence: 🟢 Reported in a Data Analyst interview at Workday, via Glassdoor.

3. What motivates you, or what inspires you in this kind of work? What it's really testing: Whether you have a genuine, specific relationship to the work, not just a job title you're chasing. How to approach it: Anchor it in something concrete, a project you enjoyed, a type of problem you like solving, rather than an abstract statement. Evidence: 🟢 Reported in a Senior Data Analyst interview at Traba, via Glassdoor.

4. What's your experience with SQL, and how have you used it? What it's really testing: Whether your resume claims match what you can actually discuss fluently. How to approach it: Be specific about real use cases rather than listing SQL as a skill with no context attached. Evidence: 🟢 Reported in a SQL Data Analyst interview at Keyrus, via Glassdoor.

5. How many years of experience do you have? What it's really testing: Whether you're a logistical fit before more rounds get scheduled. How to approach it: Answer directly. This is a filtering question, not an opportunity to oversell. Evidence: 🟢 Reported in Data Analyst interviews at Workday and at Vanguard, via Glassdoor.

Part 2: Core technical skills

Once basic fit is established, most processes move into whether you can actually do the work. SQL is the most consistently represented technical skill across the interview reports and sources reviewed for this guide, and Excel remains a frequent companion to it, whether tested together or separately. A Data Analyst interview report from Dandy (NY), via Glassdoor, describes a SQL window-function question paired directly with a follow-up Python question in the same technical round, with the candidate noting that working within the time allotted was the hardest part of both. The exact questions asked weren't recorded, so they aren't presented as standalone entries below, but the pairing itself is worth expecting.

SQL

6. Explain the different types of SQL joins, and what happens to unmatched rows. What it's really testing: Whether you can reason about the result, not just recite the four join names. How to approach it: Don't stop at naming INNER, LEFT, RIGHT and FULL. Explain what happens to rows with no match in each case. Evidence: 🟢 Reported in a Data Analyst interview at Citi, which included a scenario asking candidates to implement every join type against two tables and state the row count each would return, via Glassdoor.

7. If you want to filter for a range of numbers in SQL, what keyword would you use? What it's really testing: Basic fluency with filtering syntax under a slightly unusual phrasing. How to approach it: The answer is BETWEEN, but explain that it's inclusive of both endpoints, since that detail is often what the follow-up question checks. Evidence: 🟢 Reported in a Data Analyst interview at Vanguard, via Glassdoor.

8. Write a query to find the second-highest value in a column, such as the second-highest salary. What it's really testing: Whether you reach for a window function or fall back to a clunky nested query. How to approach it: SELECT salary FROM (SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk FROM employees) t WHERE rnk = 2; A window-function solution reads more cleanly than a nested MAX subquery and signals more current SQL fluency. Evidence: 🔵 Commonly documented across SQL interview guides, including DataCamp's SQL interview questions guide.

9. What's the difference between WHERE and HAVING? What it's really testing: Whether you understand query execution order. How to approach it: WHERE filters rows before grouping; HAVING filters groups after aggregation. Give a one-line example of each. Evidence: 🔵 Commonly documented, including in GeeksforGeeks' SQL questions for data analysts.

10. Explain RANK, DENSE_RANK and ROW_NUMBER, and how each handles ties. What it's really testing: Whether you understand the mechanics, not just the names. How to approach it: RANK leaves gaps after ties, DENSE_RANK doesn't, and ROW_NUMBER ignores ties entirely. Walk through a small tied example rather than just defining the terms. Evidence: 🔵 Commonly documented, including in Let's Data Science's SQL window functions guide.

11. How would you find duplicate records in a table? What it's really testing: Whether you can combine GROUP BY and HAVING correctly. How to approach it: Group by the columns that should be unique, then filter with HAVING COUNT(*) > 1. Evidence: 🔵 Commonly documented, including in GeeksforGeeks' SQL questions for data analysts.

12. What's the difference between UNION and UNION ALL? What it's really testing: Attention to a detail that affects performance. How to approach it: UNION removes duplicates and is slower because of that extra step; UNION ALL keeps everything and is faster. Default to UNION ALL unless duplicates genuinely need removing. Evidence: 🔵 Commonly documented, including in DataCamp's SQL interview questions guide.

13. How do NULLs behave inside aggregate functions like SUM, AVG and COUNT? What it's really testing: Whether you've been burned by this before. How to approach it: Most aggregate functions ignore NULLs rather than treating them as zero, which can silently skew an average if unaccounted for. Mention COALESCE as the usual fix. Evidence: 🔵 Commonly documented, including in GeeksforGeeks' SQL questions for data analysts.

14. Write a query to calculate month-over-month growth. What it's really testing: Whether you can combine a window function with date logic. How to approach it: Use LAG, partitioned appropriately and ordered by month, to pull the prior period's value into the same row, then calculate the percentage change directly. Evidence: 🔵 Commonly documented, including in Let's Data Science's SQL window functions guide.

15. Find the top two highest-grossing products within each category. What it's really testing: Whether you can combine PARTITION BY with a ranking function to solve a per-group top-N problem, which is a step up in difficulty from a single overall ranking. How to approach it: Use RANK or ROW_NUMBER with PARTITION BY category ORDER BY total_spend DESC, then filter to rank 2 or lower in an outer query or CTE, since window function results can't be filtered directly in a WHERE clause. Evidence: 🔵 Commonly documented as a specific intermediate-level problem, reported as appearing at a major e-commerce platform, in Let's Data Science's SQL window functions guide.

Excel

16. XLOOKUP versus VLOOKUP, what's the difference? What it's really testing: Whether you're current with the tool. How to approach it: XLOOKUP defaults to exact match and can return values from either side of the lookup column. VLOOKUP requires the lookup column to be on the left and, when its optional fourth argument is omitted, uses approximate matching, which causes silent errors. Evidence: 🔵 Commonly documented, including in InterviewQuery's Excel questions for data analysts.

17. What's the difference between SUMIF and SUMIFS? What it's really testing: Precision about single versus multiple conditions. How to approach it: SUMIF handles one condition; SUMIFS handles multiple conditions across multiple ranges, and the argument order differs slightly between the two. Evidence: 🔵 Commonly documented, including in InterviewBit's Excel interview questions.

18. When would you use a Pivot Table instead of a formula? What it's really testing: Whether you reach for the right tool for a full breakdown versus a single number. How to approach it: A formula is right for one summary figure; a Pivot Table is right when you need a full breakdown across multiple dimensions. Evidence: 🔵 Commonly documented, including in Indeed's Excel interview questions guide.

19. What's Power Query, and when would you use it? What it's really testing: Whether your Excel skills go beyond formulas. How to approach it: Describe it as turning a one-off cleaning task into a repeatable process, with a concrete example like consolidating several monthly files into one table. Evidence: 🔵 Commonly documented, including in InterviewBit's Excel interview questions.

20. How would you approach cleaning a genuinely messy dataset? What it's really testing: Whether you have a repeatable process, not just isolated tricks. How to approach it: Walk through it in order: check data types, handle duplicates, standardise text formatting, and decide deliberately how to treat missing values. Evidence: 🔵 Commonly documented, including in Springboard's Excel interview questions guide.

21. What's the difference between COUNT, COUNTA and COUNTIF? What it's really testing: Attention to a common source of small errors. How to approach it: COUNT counts numeric cells only, COUNTA counts any non-empty cell, and COUNTIF counts cells matching a specific condition. Evidence: 🔵 Commonly documented, including in this Excel-for-analysts breakdown on Medium.

22. How would you find duplicates in a large Excel dataset? What it's really testing: Whether you know more than one method. How to approach it: Conditional formatting for a quick visual check, Remove Duplicates for a fast fix, or COUNTIF for an auditable formula-based flag. Evidence: 🔵 Commonly documented, including in this Excel interview questions guide for data analysts.

23. How would you design a dashboard for a stakeholder who isn't technical? What it's really testing: Whether you think about audience, not just mechanics. How to approach it: Start from what decision the dashboard needs to support, lead with the headline number, and avoid burying the point under too many competing charts. Evidence: 🔵 Commonly documented, including in BrainStation's data analyst interview questions guide.

Part 3: Analytical and statistical thinking

Not every analyst role tests Python, but the reported interviews in this guide show it appearing consistently at product and tech companies, often paired with SQL in the same technical round. A Team Lead Business Analyst interview report from Paytm describes basic Pandas questions on grouping and filtering data, and a Data Analyst interview report from Huawei Technologies describes Python, Pandas, Java and SQL being tested together in one round, both via Glassdoor. Neither candidate recorded the exact question text, so they're referenced here as evidence of format rather than quoted as standalone questions. Statistics questions appear somewhat less consistently in reported analyst interviews specifically, but recur heavily in adjacent Data Science interviews that test the same underlying reasoning, which is why several of the sources below are labelled accordingly.

Python and Pandas

24. How would you filter a DataFrame to return only rows that meet more than one condition? What it's really testing: Basic Pandas fluency with boolean indexing, which is one of the two or three operations most often probed first in a Pandas round. How to approach it: Combine conditions with & and |, and stress that each condition needs its own parentheses, since that's the most common syntax mistake under time pressure: df[(df['spend'] > 1000) & (df['region'] == 'West')]. Evidence: 🔵 Commonly documented, including in this Pandas interview questions guide.

25. What's the difference between apply() and applymap() in Pandas, and when would you use each? What it's really testing: Whether you know Pandas beyond the basic groupby and filter operations, since this distinction only comes up once you've actually written non-trivial transformation code. How to approach it: apply() works on a Series or along an axis of a DataFrame; applymap() works element-wise across an entire DataFrame. Give a one-line example of a task each is suited to. Evidence: 🔵 Commonly documented, including in GeeksforGeeks' Pandas interview questions.

26. What's the difference between a Python list and a Pandas Series? What it's really testing: Whether you understand what Pandas actually adds. How to approach it: A Series is labelled, vectorised, and supports element-wise operations natively; a plain list has none of that. Evidence: 🔵 Commonly documented, including in this Pandas interview questions guide.

27. How do you handle missing values in a DataFrame? What it's really testing: Whether you have a decision framework, not just a method. How to approach it: Mention isna() to detect them, then explain the decision: drop, impute, or flag, depending on how much data is missing and whether the missingness itself is meaningful. Evidence: 🔵 Commonly documented, including in GeeksforGeeks' Pandas interview questions.

28. Explain groupby, and how it compares to SQL's GROUP BY. What it's really testing: Whether you can translate concepts between tools. How to approach it: They're conceptually identical: split the data by a key, apply an aggregation, and combine the results. Evidence: 🔵 Commonly documented, including in this Pandas interview questions guide.

29. What's the difference between merge and concat? What it's really testing: Whether you know when you're joining versus stacking. How to approach it: merge combines DataFrames based on shared column values, like a SQL join; concat stacks DataFrames without matching on a key. Evidence: 🔵 Commonly documented, including in this Pandas interview questions guide.

30. What's the difference between loc and iloc? What it's really testing: A common small-detail question that filters out surface-level familiarity. How to approach it: loc selects by label, iloc selects by integer position. Give a one-line example of each. Evidence: 🔵 Commonly documented, including in this Pandas interview questions guide.

31. How would you handle a Pandas script that's too slow on a large dataset? What it's really testing: Whether you think about performance, not just correctness. How to approach it: Mention avoiding row-by-row loops in favour of vectorised operations, checking data types for unnecessary memory use, and considering chunked reading for very large files. Evidence: ⚪ Practice question. No first-hand report of this exact question was found; it's included because performance reasoning recurs as a natural follow-up in the reported Python and Pandas questions above.

Statistics and experimentation

32. What is a p-value, and would your interpretation change with a much larger dataset? What it's really testing: Whether you understand what a p-value depends on, not just its textbook definition. How to approach it: The interpretation of what a p-value means doesn't change with sample size, a p-value is still just a statement about how surprising the result would be under the null hypothesis. What does change is the test's power: with a larger sample, standard error shrinks, so a real effect is more likely to produce a small p-value, and a p-value you do get is a more precise reflection of the true effect. Be careful not to imply a larger dataset makes any given p-value more "correct"; it changes the test's sensitivity, not the meaning of the number itself. Evidence: 🟢 Reported in a Data Science interview at State Farm, documented via StrataScratch. The role reported was Data Science rather than Data Analyst specifically, but the reasoning tested is directly relevant to analyst statistics rounds.

33. How would you explain a confidence interval to a non-technical audience? What it's really testing: Whether you can translate a technical concept into a plain-language analogy without losing accuracy. How to approach it: Use a concrete analogy tied to sample size and consistency of evidence, then connect it back to the idea that a wider interval reflects less certainty. Evidence: 🟢 Reported in a Data Scientist interview at Meta, via Glassdoor. The role reported was Data Scientist rather than Data Analyst specifically.

34. What's the difference between correlation and causation? What it's really testing: A frequently cited statistics interview question, testing analytical caution. How to approach it: Give a concrete example where two things move together without one causing the other, and name at least one alternative explanation, like a shared underlying cause. Evidence: 🔵 Commonly documented across statistics interview guides, including Let's Data Science's statistics and hypothesis testing guide.

35. How would you design an A/B test for a new feature? What it's really testing: Whether you think about the full experiment, not just the result. How to approach it: Cover defining the metric, calculating the needed sample size in advance, ensuring proper randomisation, and deciding the stopping point before the test begins. Evidence: 🔵 Commonly documented, including in this A/B testing interview questions guide.

36. What's the Central Limit Theorem, and why does it matter for an analyst? What it's really testing: Whether you understand why sample-based inference works at all. How to approach it: Explain that it's a large part of the reason the average of a reasonably sized sample behaves predictably even when the underlying data is messy, which is what makes confidence intervals and hypothesis tests usable on real business data. Evidence: 🔵 Commonly documented across statistics interview resources, including this data science interview question repository.

37. What's the difference between statistical and practical significance? What it's really testing: Whether you go beyond the p-value to the business decision. How to approach it: Statistical significance asks whether a result is likely more than noise; practical significance asks whether it's large enough, relative to the cost of acting on it, to actually matter. Evidence: 🔵 Commonly documented, including in Let's Data Science's statistics and hypothesis testing guide, which specifically warns against conflating a small p-value with a commercially meaningful effect.

Part 4: Business and problem-solving

Once an interviewer has established that you can work with data, the next question is whether you can turn that data into a business decision under ambiguity. This is the stage most candidates under-prepare for, precisely because there's no single correct answer to memorise. First-hand accounts of this stage at Meta and TikTok, shared on Blind, describe SQL and case-style business reasoning being tested in the same round, with an expectation that candidates offer multiple hypotheses when interpreting a chart or experiment result rather than committing to the first explanation. Neither candidate quoted a specific question, so that detail isn't presented as a standalone question below, but it's worth knowing that this combined format is what's actually reported at product companies.

38. A basic business case: given a per-unit cost, a sunk cost, a price and a fee, how many units need to be sold to break even? What it's really testing: Whether you can structure a quantitative business problem cleanly under time pressure. How to approach it: Set up the break-even equation explicitly before calculating anything, and state your assumptions as you go. Evidence: 🟢 Reported in a Data Analyst interview at Capital One, via Glassdoor.

39. Estimate how many people in a specific city would buy a particular product. What it's really testing: Whether you can structure a guesstimate logically rather than guessing a number outright. How to approach it: Break the population into segments, estimate a rough rate for each, and state your assumptions out loud as you go; the structure of the reasoning matters more than the precision of the final number. Evidence: 🟢 Reported in a Data Analyst interview at Citi, which specifically asked candidates to estimate BMW purchases in Bangalore and identify what data they'd need to answer it, via Glassdoor.

40. What's the market size for a given product or service in a given year? What it's really testing: The same guesstimate structuring skill as question 39, applied to a market-sizing rather than a purchase-volume framing, which shows up often enough to be worth practising separately. How to approach it: Anchor the estimate to a population or spend figure you can reason about, then narrow it down through a chain of stated assumptions rather than guessing the final number directly. Evidence: 🔵 A market-sizing question in this shape, phrased as a driverless-car market estimate, is documented with real candidate-submitted answers in Exponent's data analyst interview question bank.

41. If the p-value of an A/B test comes back at 0.06, what can you conclude? What it's really testing: Whether you treat 0.05 as a rigid cutoff or understand it as a convention, and whether you can talk about a borderline result without overstating or dismissing it. How to approach it: Explain that 0.06 doesn't clear the conventional 0.05 threshold, so the result doesn't meet standard statistical significance, but that this doesn't prove there's no effect either; discuss what you'd do next, such as extending the test or looking at the effect size and confidence interval. Evidence: 🔵 Commonly documented, including as a specific numbered question in this A/B testing interview questions guide.

42. Find the number of customers who placed more than three orders in the last month. What it's really testing: Whether you can translate a plain-language business question into a specific, filterable query or Pandas operation without over-complicating it. How to approach it: Identify the grouping key (customer), the count condition (orders in the period), and the threshold (more than three), then decide whether SQL or Pandas is the faster path to the answer given how the data is already stored. Evidence: 🔵 Adapted from a documented counting question in this shape, phrased around users making repeated calls, with real candidate-submitted answers in Exponent's data analyst interview question bank.

43. Design a workflow to flag issues in a risk report. What it's really testing: Whether you can structure an open-ended, ambiguous business process rather than a narrow calculation. How to approach it: Start by clarifying what counts as an "issue" and who acts on the flag, then describe the workflow in stages, data checks, thresholds, an escalation path, before mentioning any specific tool. Evidence: 🟢 Reported in a Data Analyst interview at Citi, via Glassdoor.

44. You have several urgent requests in your queue at the same time. How do you decide what to work on first? What it's really testing: Whether you have an actual mental model for prioritisation, not just good intentions. How to approach it: Name a concrete method, weighing urgency against business impact, and mention communicating trade-offs to whoever's asking rather than silently deciding on their behalf. Evidence: 🔵 Documented in this hiring-manager guide to data analyst interview questions, which frames this as a question interviewers use specifically to test whether a candidate has a working prioritisation model rather than a generic answer.

45. How would you explain a statistically significant A/B test result to a stakeholder with no statistics background? What it's really testing: Whether you can translate a technical result rather than just recite it. How to approach it: Ground the explanation in units the stakeholder cares about, like revenue or users, and lead with the recommendation before the supporting statistic, not the other way around. Evidence: 🔵 Documented in this hiring-manager guide to data analyst interview questions, which frames this as a specific test of translation skill, watching for whether a candidate reaches for a metaphor and a business unit rather than reciting a p-value definition.

Part 5: Communication and behavioural questions

Behavioural questions can appear at any point in the process, not only at the end, and they rarely test technical skill directly. What they test is whether you communicate honestly under a slightly uncomfortable question, and whether you'd be someone the team wants to work alongside.

46. Tell me about a time you made a mistake and how you recovered from it. What it's really testing: Whether you're honest about errors and how you caught them. How to approach it: Pick a real example, explain how you caught it, not just that you fixed it, and what changed in your process afterward. Claiming you've never made a mistake reads as dishonest, not impressive. Evidence: 🟢 Reported in a Data Analyst interview at John Deere, via Glassdoor.

47. Tell me about a time you helped resolve a conflict. What it's really testing: Whether you can hold a position without being purely combative or purely passive. How to approach it: Describe listening to the other position genuinely, checking whether it changed your view, and how you reached a resolution, rather than framing it as a win. Evidence: 🟢 Reported in a Data Analyst interview at John Deere, via Glassdoor.

48. Tell us about a time you had to overcome a problem. What it's really testing: Whether you have a genuine, specific story rather than a vague generality. How to approach it: Pick a problem with a clear before-and-after, and be specific about your individual contribution rather than describing what "we" did. Evidence: 🟢 Reported in a Data Analyst interview at Vanguard, via Glassdoor.

49. Tell us about a time you held a leadership position. What it's really testing: Whether you can demonstrate initiative even outside a formal management title. How to approach it: Leadership doesn't require a title; leading a project, mentoring a peer, or driving a decision all count, as long as you describe your specific role in it. Evidence: 🟢 Reported in a Data Analyst interview at Vanguard, via Glassdoor.

50. Walk me through one of your personal data projects, including your methodology, the tools you used, and the impact of the work. What it's really testing: Whether you can talk fluently and specifically about your own work, not just list tools. How to approach it: Structure it as the decisions you made and why, not a chronological tool-by-tool narration. This is usually the easiest question to over-prepare for in general terms and under-deliver on in specifics. Evidence: 🟢 Reported in a Data Analyst interview at Vanguard, which described an in-depth discussion of the candidate's personal data projects, focused specifically on methodology, tools used, and impact, via Glassdoor.

Common mistakes across every category

• Answering the literal question instead of what's being tested. Nearly every technical question here is really testing judgment, not memorised syntax. Explain your reasoning, not just the answer.

• Treating case-study and guesstimate questions like trivia. There's no single correct answer to a break-even calculation or a market-sizing question. Structure matters more than landing on the exact right number.

• Skipping the "why" behind a definition. "XLOOKUP is better than VLOOKUP" without explaining why sounds memorised. A brief reason makes the same answer sound understood.

• Over-preparing SQL and under-preparing business reasoning. SQL is the easiest area to drill for, which is exactly why many candidates over-invest there and get caught flat-footed by an ambiguous case question.

• Claiming experience you can't defend. If Python is on your resume, expect it to come up, as the Paytm and Huawei reports above show happening even at the basic-question level. An answer you can't back up under a follow-up question costs more credibility than being upfront about a gap.

• Undermining a strong technical answer with a weak communication one. An interviewer who can't follow your explanation will mark you down even if the underlying answer was correct.

How to actually prepare

SQL: work against a real database, not just definitions in your head. Writing the query for question 8 or 14 above from scratch is a different skill from recognising the right answer in a list.

Excel: practise on a genuinely messy dataset, not just formula examples on clean data, since real cleaning work is most of what the job involves.

Python: work with a real DataFrame and perform an actual exploratory analysis, rather than reading through Pandas syntax in isolation.

Statistics: practise explaining each concept in plain language to someone non-technical, since that translation, not the definition itself, is what several of the reported questions above are actually testing.

Case studies and guesstimates: practise structuring ambiguous questions out loud under light time pressure, timing yourself to a few minutes each. The process matters more than a specific correct conclusion.

Behavioural questions: write out three or four real examples in advance rather than improvising in the moment. It's the category most candidates under-prepare for, and it's rarely a coincidence when a strong technical candidate loses an offer here.

Where to go from here

If the SQL questions above felt like the weakest section, the SQL for Data Analysts guide covers the underlying concepts in more depth. If Excel needs work, the Excel for Data Analysis guide walks through the working set these questions draw from. If the statistics section felt shakiest, the full statistics guide goes deeper into hypothesis testing, confidence intervals and the Central Limit Theorem than this format allows.

For the case-study and guesstimate questions specifically, there's no substitute for practising on real ambiguous problems. Working through a few of the project ideas covered separately and practising explaining your reasoning out loud is one of the closer available substitutes for real interview repetitions.