Data Analyst Interview Questions (2026)

Lead with what the new role offers (scope, technology, mission, team) that your current role does not. Acknowledge what is good about your current job. If the truthful answer involves a problem at your current company, state it neutrally and do not dwell. Avoid blaming your manager or the company.

Always have at least three questions ready. For an analyst peer: what is the analytics stack, where are the rough edges, how does the team prioritize ad-hoc requests vs longer-term work. For a manager: what does success in the first 90 days look like, how is the team measured, what is the team's relationship with the product and engineering orgs. Skip questions easily answered by the company website.

Use SUM(amount) OVER (PARTITION BY customer_id ORDER BY transaction_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW). Mention the alternative ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW vs RANGE for non-unique dates. State the time complexity (O(n log n) due to the sort) and mention you would add an index on (customer_id, transaction_date) for production use.

Use LAG(purchase_date) OVER (PARTITION BY user_id ORDER BY purchase_date) to get the prior purchase per user, then filter for rows where purchase_date - prior_purchase_date > 30 days. Return DISTINCT user_id. Walk through your logic out loud while writing it; interviewers value the narration as much as the final query.

Start with EXPLAIN ANALYZE (or your warehouse equivalent — Snowflake query profile, BigQuery execution details). Look for sudden table scans where there used to be index seeks, joins on rebuilt or unindexed columns, or estimated-vs-actual row count mismatches indicating stale stats. Common culprits: a recent schema change broke an index, table grew past a threshold and the planner switched strategies, or someone deployed a broken view. Mention you would also check whether the warehouse autoscaling or warehouse size changed.

INNER returns only rows present in both tables. LEFT returns all rows from the left table, with NULLs where the right has no match. FULL OUTER returns all rows from both tables, NULLs on the unmatched side. Mention the common mistake: using LEFT JOIN with a WHERE clause on the right table, which silently turns it into an INNER JOIN. Walk through a quick example if you have time.

Statistical significance: p-value below your pre-set threshold (typically 0.05) given sufficient sample size. Practical significance: is the lift large enough to matter for the business — a 0.3% lift on a checkout funnel might be statistically significant but not worth shipping if it adds operational complexity. Mention CUPED or stratified sampling for variance reduction. Mention multiple-comparisons correction if running many tests in parallel.

First quantify the issue: how many customers are affected, what percentage of total revenue, what date range. If the affected segment is small and known, exclude it and add a footnote in the analysis. If it is large, scope the analysis to a metric that is robust to deduplication (e.g., transaction-level metrics rather than customer-level), and call out the limitation. Avoid pretending the data is clean when it is not.

Pick an analysis where the recommendation was non-obvious before the work. Open with the question you were asked, the analysis you did (with one or two methodological choices that mattered), the insight you surfaced, and what changed downstream. End with what you learned about how this organization receives data-driven recommendations.

Pick a dashboard where you were involved beyond the initial build — ideally one you still maintain. Describe who uses it and how often, what decisions it supports, and how the v1 differed from the v2. Mention the dashboards you killed or consolidated; the discipline of removing dashboards is a senior signal.

Lead with the one-sentence takeaway: "Customers who hit error X are 3.4x more likely to churn within 30 days." Follow with the most relevant chart, then the one or two methodology details that affect interpretation. Save details and edge cases for an appendix or follow-up. Test the takeaway by asking yourself: if the stakeholder reads only the first sentence, will they make the right decision?

Pick a real example with substance. State your position, the stakeholder's position, the inputs each side was weighting, and how the disagreement resolved. Be honest if you were wrong (or partially wrong) in retrospect. The most important quality the interviewer is looking for is intellectual humility paired with clear reasoning.

Pick a real moment when the data overturned your prior belief, ideally one with material business consequence. Describe what you expected, what you found, why the surprise was real (not just a measurement artifact), and what you did about it. Bonus points if the surprise led you to question a methodology you had been using.

Acknowledge the deadline and ask one or two clarifying questions to scope the request: what is the decision the number will inform, what level of precision is needed, what is the acceptable error bar. Often the number does not need to be perfect; it needs to be right to the nearest 10%. If you have to ship a rough estimate, label it as such and follow up with a refined version after the meeting. Avoid both refusing to ship and shipping a misleading number.

Identify whether the conflict is about the data definition, the metric calculation, or the conclusion drawn from the same numbers. Usually it is the first or second. Schedule a 15-minute walkthrough with both stakeholders, surface the precise definition mismatch, and update the dashboard to make the choice explicit. If the disagreement is genuinely about interpretation, escalate to a decision-maker with a written summary of the two positions.

Communicate first: post in the relevant Slack channel that the dashboard is broken and you are investigating. Triage: figure out the scope of the breakage, whether the underlying data is also affected or just the dashboard. Fix the dashboard if it is a quick repair; if not, post a workaround query for affected stakeholders and follow up when the fix is in. Postmortem after: how did the schema change ship without alerting the analytics team, and what guardrails would prevent a recurrence.