Data Analyst Interview Questions — SQL Gets You In, Judgment Gets You Hired

Data analyst interview questions come in two halves, and almost everyone over-prepares the first one. The technical screen — joins, window functions, group-by logic, sometimes a spreadsheet or Python task — is a gate. It filters you out; it does not get you hired. The offer is decided in the case round, when someone says "this metric dropped 20% last week, what do you do?" and listens to how you think.

The two halves of an analyst loop

Most analyst loops run three to five stages: a recruiter screen, a technical assessment, a case interview, a behavioral round about stakeholders, and sometimes a take-home. Startups often collapse the case and take-home into one conversation.

Here is the split that matters. The technical stage is pass/fail. The case stage is ranked. Two candidates can both write correct SQL; only one can explain why the number moved.

Most candidates grind queries and improvise the case. That is backwards. For the full map of what gets asked across a loop, start with our guide to interview questions.

The SQL topics that actually recur

Technical screens are narrower than the internet suggests. The same handful of patterns recur, usually against two or three small tables you have never seen.

• Joins and row counts. LEFT JOIN versus INNER, and what a one-to-many join does to your totals. Fan-out is the most common silent error.
• Aggregation logic. GROUP BY with HAVING, and why HAVING is not WHERE.
• Window functions. ROW_NUMBER to dedupe, RANK for top-N per group, LAG for period-over-period, SUM OVER for running totals.
• Date handling. Truncating to week or month, cohort alignment, last-7-days versus prior-7-days.
• NULL behavior. NULLs vanishing from aggregates, NOT IN returning nothing, COUNT of a column versus COUNT of star.
• Readability. CTEs instead of nested subqueries. Interviewers read your query as writing.

One habit separates strong candidates: say the grain of the table out loud before you type. "One row per order line, so a user with three items counts three times unless I dedupe." That sentence tells the interviewer you have been burned by real data.

The case question — a metric dropped 20% last week

This is the round that decides the offer, and it has a reliable shape: a metric moved, you get almost no context, and you have fifteen minutes. You are not being graded on the right answer. You are being graded on whether your search is ordered.

Five moves, in order:

1. Clarify the metric. What exactly is counted, over what window, against what baseline? Half of all "drops" are definition changes, tracking breaks, or a shifted week boundary.
2. Segment before you hypothesize. Cut by platform, geography, channel, new versus returning, device. A drop in one segment is a different problem than one spread evenly.
3. Form ranked hypotheses. Instrumentation and data quality, product releases, traffic mix, seasonality, external events — say which you check first and why.
4. Name the data you would pull. "Daily events by app version, joined to the release calendar" beats "I would look at the data."
5. State what would change your mind. "If the drop is flat across every segment and event volume is intact, I stop blaming the product and look at the pipeline."

The stakeholder question — explaining a result nobody wants

Expect some version of "how do you explain a result to someone who does not want to hear it?" The interviewer is testing whether you can hold a finding under pressure without becoming a pushover or a jerk.

A strong answer has three parts: lead with the conclusion, show the uncertainty honestly, and offer the next decision rather than just the bad news. "The campaign did not move retention, the confidence interval crosses zero, and here is the cheapest test that would settle it" beats a deck of caveats.

Bring one real story where you disagreed with someone senior and stayed factual — our STAR method examples show how to compress it into ninety seconds. Never tell a story where you quietly changed the chart to make someone happy.

The portfolio question — why "I cleaned the data" is a weak headline

When you walk through a project, the headline should be the decision, not the labor. "I cleaned the data" describes effort. "We stopped spending on a channel that looked profitable and was not" describes value. Cleaning is table stakes.

Structure each project walkthrough this way:

• The question someone actually had, and who was waiting on the answer.
• One or two real tradeoffs — a definition you chose, a source you rejected, a shortcut you took and why.
• The result, with a number if you can share one honestly.
• What you would redo — where candidates gain credibility instead of losing it.

The same rule governs your written materials — vague inputs produce vague pages, the trap covered in how to write resume bullet points.

Round by round — what each stage is really testing

How to prepare for data analyst interview questions in two weeks

Split your prep the way the loop is actually weighted, not the way it feels scary.

• Days 1–5. Twenty query problems, no more — dedup, top-N per group, period-over-period, funnels, cohort retention. Rewrite each for readability once it works.
• Days 6–9. Ten case prompts, spoken aloud and timed. Record yourself once; you will hear the gaps.
• Days 10–12. Two project stories, ninety seconds each, decision as the first line.
• Days 13–14. Your questions for them, and a plain answer to "what do you want to work on." Both signal seniority faster than another window function.

The question underneath all of this is usually "how technical do I need to be?" Technical enough to clear the screen without stalling. After that, the difference is judgment, ordering, and how clearly you think out loud. Prepare for the case round like it is the interview, because it is.

If you want that whole sequence — positioning, resume, applications, interview prep — as one system with copy-ready prompts, Land the Offer with AI walks through it on one firm rule: AI is an amplifier, not a ghostwriter — everything on your resume has to survive the interview.

Frequently asked questions

Do I need Python for a data analyst interview?

Often no, but it varies widely by employer. Many analyst roles screen on SQL and spreadsheets only; product- and growth-analytics teams may add a pandas exercise. Read the job description literally — if Python sits under requirements rather than nice-to-haves, expect it.

What should I do if I get stuck on the SQL question?

Say what you are stuck on, out loud, in one sentence. Then state the approach you would take with more time, and write the simpler version that gets partial credit. Interviewers pass candidates who narrate a stall and recover; they rarely pass four minutes of silence.

How technical is the case round?

Less than people expect. Cases stay at the level of "what would you pull and why" rather than exact syntax. The failure mode is not weak math — it is jumping to a conclusion before defining the metric or checking whether the data itself broke.

Should I use AI to prepare for data analyst interviews?

Yes, for drilling and pressure-testing your reasoning — have it generate case prompts, then argue with your answer. Do not let it write claims you cannot defend. Anything AI helps you say has to hold up when a human asks the follow-up.