Data analyst mock interview — practice with AI

Data analyst interviews look easy on paper — SQL, some stats, a chart or two — and ambush people in the room. The questions are short. The expectations are not. A SQL screen with three problems can take 45 minutes; a single A/B test discussion can run an hour. Practicing the format with AI mocks turns ambush questions into routine ones.

The shape of a data analyst loop

Most analyst loops have four moving parts. A recruiter screen. A SQL technical screen (live or take-home), usually 45–60 minutes with two or three problems of increasing difficulty. A product/business case round, where the interviewer hands you an ambiguous metric question and watches how you reason. And a behavioral/cross-functional round, which checks whether you can talk to non-data people without making them feel stupid.

Senior analyst and analytics engineer loops add a fifth round: a system or experimentation design question. "Design an A/B testing framework for our recommendations team" or "design a metrics layer for our finance org". These are the highest-variance questions in the whole loop — they reward structured thinking and punish people who jump to dashboards before they've defined the metrics.

AI mocks handle three of the four well. SQL screens you should practice in a real SQL editor with a real dataset (LeetCode SQL, StrataScratch, Mode tutorials are all fine). Everything else — verbal SQL walkthroughs, case studies, A/B test reasoning, behavioral — is exactly what AI mocks were built for.

SQL screens: where most candidates lose points

The SQL screen filters more candidates than any other round, and it doesn't filter for the reason most people assume. The bar isn't "can you write a join". It's "can you write a clean, correct, efficient query for a slightly ambiguous problem, and can you explain what you wrote out loud while another human watches?". The second half is where mocks help.

Topics that will absolutely come up

• Window functions — row_number, rank, lag, lead, partitioned aggregates.
• CTEs and recursive CTEs (less often, but they appear for senior).
• All four join types, with edge cases (NULLs on either side, self-joins, anti-joins via NOT EXISTS).
• Aggregations with GROUP BY + HAVING, including conditional aggregates (COUNT(CASE WHEN ...)).
• Date arithmetic — last 7 days, retention cohorts, week-over-week comparisons.
• Deduplication patterns (which row do you keep, why).

Classic question patterns: "find the top N by some metric within each group", "calculate week-over-week retention", "find users who did X but not Y", "find the second most recent event per user". If those don't have automatic muscle memory, drill them for a week before any real interview.

A/B test reasoning

A/B test questions decide whether you go to the next round. They're the closest thing to "product judgment" the interviewer can test in 45 minutes. The format is always similar: a vague feature, a vague goal, your job is to design the experiment cleanly out loud.

The chain you need to walk through

1. Define the change. What exactly is the treatment? "We're showing a new banner" is too vague. "We're showing a banner on the home page that links to the upgrade page, for users who have been free for >30 days" is precise.
2. State the hypothesis. Direction and magnitude. "We expect upgrade rate to increase by 2 percentage points among treated users." Specific. Falsifiable.
3. Pick the primary metric. One. Not three. "Upgrade rate within 7 days of treatment." Defend why that one and not the obvious alternatives.
4. Pick guardrail metrics. What must not get worse. "Free-user engagement, session length, support ticket volume." If the treatment moves the primary but blows a guardrail, you don't ship.
5. Estimate sample size and runtime. Based on baseline rate, minimum detectable effect, alpha and power. You don't need to do the math live — just show you understand the inputs.
6. State the decision rule. What threshold of evidence ships the feature. What you do if results are inconclusive.

Interviewers will follow up with traps: novelty effects, network effects (especially in social products), interference between concurrent experiments, peeking. Be ready to name each by name and explain why it matters.

Dashboards and case studies

Case studies are conversation rounds with no data on the screen. A typical prompt: "DAU dropped 5% last week. What do you do?". The interviewer is not looking for the answer (there isn't one without data). They're looking for: do you decompose the problem cleanly, do you ask the right clarifying questions, do you prioritize hypotheses by likelihood and impact, and do you know what data you'd pull and what query you'd run.

A clean framework: start with clarifying questions (which product, which definition of DAU, which segments, is this a known data pipeline issue), then segment hypotheses into external (seasonality, marketing, competitor launch), internal product (recent deploy, feature change, A/B test), and instrumentation (logging bug, schema change). Rank by likelihood. For the top two or three, say what you'd pull and what you'd look at.

Dashboard design questions are more concrete. "You're building a dashboard for the head of growth — what's on it?". Don't list 40 metrics. Pick 5–8 that map to decisions the head of growth actually makes (acquisition, activation, retention, monetization, referral — the AARRR loop or your company's variant). For each, say what threshold triggers action.

How to set up an AI mock for analyst roles

Set the role to "Data Analyst" or paste the JD if you have one. For the first session, pick "Tech Screening" mode and 10 questions — that gives you a roughly even split of SQL walkthroughs, A/B reasoning, and one or two case studies. For deeper drill sessions, use standalone mode and tell the AI to focus on one area: "spend the whole session on SQL window functions and conditional aggregates" or "spend the whole session on A/B test design with traps".

One useful pattern for analysts specifically: after the AI mock, take the SQL questions and actually write the queries in a SQL playground. The mock surfaces whether you can explain the approach; the playground confirms you can ship the code. Both matter.

Frequently asked questions