The BLS projects data science and analyst roles will grow 34 percent between 2024 and 2034 – roughly ten times the average for all occupations. There’s no shortage of prep lists. There is a shortage of honest ones that explain why candidates who know SQL still get rejected. They can write queries. They can’t explain what the query is actually answering.<\/p>\n
This is not a list of 40 surface-level questions. It’s 14 that interviewers actually use to separate candidates who’ve memorized syntax from candidates who understand data.<\/p>\n
SQL shows up in nearly every data analyst role. The 2025 Stack Overflow Developer Survey<\/a> found 58.6% of all respondents use SQL regularly – third only to JavaScript and HTML\/CSS. Being common doesn’t make it easy to interview on.<\/p>\n The trap is “top 5 by revenue.” Most candidates write an INNER JOIN and exclude zero-order customers without noticing. The correct approach: LEFT JOIN on orders, COALESCE to handle NULL revenue, then order descending and LIMIT 5. Interviewers are watching for whether you catch the edge case before they point it out. Don’t wait for the hint.<\/p>\n WHERE filters rows before aggregation. HAVING filters groups after GROUP BY runs. You can’t use aggregate functions like SUM() in a WHERE clause. In practice: use WHERE to narrow your dataset early (it’s faster), and HAVING to filter on computed group metrics. Candidates who say “they’re basically the same” are done.<\/p>\n LAG(revenue, 1) OVER (ORDER BY month) gives you last month’s revenue in the current row. Growth rate is (current – previous) \/ previous. The follow-up is always about interpretation: “Growth jumped 40% in March – what do you check first?” Good answers mention seasonality, a product launch, or a tracking change. Bad answers say “that’s good news.”<\/p>\n COALESCE is the function. But the real answer is: it depends on what NULL means. A NULL in a revenue column for a trial user might correctly be zero. A NULL in an order_date might mean the order never shipped. Replacing every NULL with zero is sometimes exactly wrong. Interviewers want to hear you ask “what does NULL represent here?” before you reach for COALESCE.<\/p>\n Pattern-detection problem. One approach: ROW_NUMBER() partitioned by customer_id and ordered by purchase month, then compute the difference between the actual month number and the row number. Consecutive months produce the same difference. Group by customer and that difference, filter where count >= 3. Shows up in interviews because it’s genuinely useful for churn work.<\/p>\n You don’t need a stats PhD to work as a data analyst. You do need to know enough to avoid confidently wrong conclusions. A\/B testing questions are where interviewers discover who learned stats versus who absorbed it.<\/p>\n The memorized answer is “probability the null hypothesis is true,” which is wrong. The accurate version: a p-value is the probability of seeing results at least as extreme as yours, assuming the null hypothesis is true. A p-value of 0.03 doesn’t mean “there’s a 3% chance we’re wrong” – it means “if there were really no difference, we’d see a result this large only 3% of the time by chance.” Most analysts confuse these. Saying the correct version out loud in an interview is memorable.<\/p>\n Type I is a false positive: you concluded the treatment worked when it didn’t. Type II is a false negative: the treatment worked but you missed it. In A\/B testing, a Type I error might mean you shipped a change that hurt revenue. Type II means you killed a feature that would’ve helped. Which is worse depends on stakes. Good candidates ask “what’s the cost of each error?” rather than reciting textbook definitions.<\/p>\n Four inputs: baseline conversion rate, the minimum detectable effect you care about, desired statistical power (usually 80%), and significance level (usually 0.05). Testing whether checkout conversion improved from 10% to 12% requires roughly 4,000 visitors per variant. The number most candidates get wrong is the MDE – they set it too small and propose six-month experiments that’ll never run. Match the MDE to a change your team would actually ship.<\/p>\n Ice cream sales correlate with drowning deaths. Summer causes both. In a product context: users who visit the help center might show higher 30-day retention. That doesn’t mean routing more users to the help center improves retention – engaged users just do both. The interviewer wants this skepticism baked into your instinct, not recited as a rule.<\/p>\n Every technical question is also a business question in disguise. Candidates who treat them as separate categories answer one half correctly and miss the other.<\/p>\n What we see on LastRoundAI mock interviews<\/p>\n Candidates practicing mock data analyst interviews<\/a> on LastRoundAI consistently go further on SQL and stats questions than on business framing ones. The most common failure: finishing a technically correct answer and stopping there, without connecting the result to a decision. Interviewers notice when you don’t close that loop.<\/p>\n<\/div>\n<\/div>\n Start by ruling out a tracking bug before drawing conclusions. Check whether the metric definition changed, whether instrumentation fired correctly, whether it’s isolated to one platform or geography. Once the drop is confirmed real: segment by acquisition channel, device, user cohort, and feature usage to find where it lives. Cross-reference with product or marketing changes in the same window. “I’d look at the data” isn’t an answer. Interviewers want the diagnostic sequence.<\/p>\n Lead with the decision, not the analysis. Executives don’t need to know you ran a regression – they need to know what to do Monday. Structure it as: here’s what we found, here’s what it means for the business, here’s my recommendation, here’s my confidence level. That last part is what most candidates skip. Saying “I’m fairly confident this is directionally right, but the sample was small” is more credible than presenting everything with equal certainty.<\/p>\n Four dimensions: completeness (what % of rows have values per field?), accuracy (are values in expected ranges?), consistency (do IDs join cleanly across tables?), and freshness (when was this last updated?). Then document what you find. A dataset with 12% NULLs in a critical field is usable if everyone running analyses knows about it. It’s a trap if they don’t.<\/p>\n SQL is faster for aggregation and filtering on structured relational data. Python is better for statistical modeling, machine learning, or multi-step transformations that don’t fit neatly into a query. In practice: do heavy data prep in SQL close to the warehouse, pull a reasonably sized result set, then do modeling or visualization work in Python. The 2025 Stack Overflow Survey<\/a> shows Python at 57.9% developer adoption, up 7 points year-over-year. Learning both isn’t optional in 2026.<\/p>\n The answer depends on stage and feature type – and I’ll admit the right heuristics for early-stage companies with thin usage data aren’t obvious to me either. Generally: frequency of the pain point across your user base, correlation between workaround behavior and retention, support ticket volume, and revenue at risk from the gap. If you have a proxy metric like “users who complete X have 2x 12-month retention,” build the case around that. Interviewers mostly want to see you ask the right questions first.<\/p>\n Interviewers reject technically correct candidates regularly. Hired candidates answer the question, then add “here’s what I’d verify before acting on this.” That instinct – connecting analysis to a decision and hedging honestly – is what separates analysts from people who can run queries.<\/p>\n The BLS projects 23,400 analyst and scientist openings per year through 2034<\/a>. The supply of candidates who’ve memorized the standard questions is growing too. Practicing until the reasoning becomes reflex, not recall, is the real edge. Machine learning interview questions<\/a> and software developer interview questions<\/a> cover adjacent territory for data-adjacent technical roles.<\/p>\n1. Top 5 customers by revenue, including those with zero orders<\/h3>\n
2. What’s the difference between WHERE and HAVING?<\/h3>\n
3. Calculate month-over-month growth using a window function<\/h3>\n
4. How do you handle NULL values?<\/h3>\n
5. Find customers who purchased in three or more consecutive months<\/h3>\n
Statistics and A\/B testing: where most candidates lose<\/h2>\n
6. What does a p-value actually mean?<\/h3>\n
7. Type I vs Type II errors<\/h3>\n
8. How do you determine sample size for an A\/B test?<\/h3>\n
9. Correlation vs causation – give a real example<\/h3>\n
Business framing: what actually separates hired from rejected<\/h2>\n
10. Daily active users dropped 20% overnight. Walk me through your investigation<\/h3>\n
11. How do you explain a finding to a non-technical stakeholder?<\/h3>\n
12. Assess data quality in a dataset you’ve just been handed<\/h3>\n
13. When do you use Python vs SQL for analysis?<\/h3>\n
14. What data would you use to prioritize which feature to build next?<\/h3>\n
The pattern in every hired candidate<\/h2>\n