The Data Analyst Interview Process: SQL Tasks, Case Questions and Take-Homes

If you have a data analyst interview coming up, the questions themselves are only half the preparation. The other half is knowing which format you will face. Most employers test analysts in some mix of three ways: a live SQL task, a spoken case question, and a take-home assignment you complete in your own time. Each one rewards different habits, and candidates often lose marks by treating them the same way.

This guide walks through the data analyst interview process stage by stage, with real examples that companies have published, what reviewers look for at each step, and a time plan for the take-home. If you want practice on statistics, cleaning and dashboard questions, or on SQL concepts such as joins and window functions, those are better treated as separate topics; here the focus is on the exercises and how to perform in them.

What the data analyst interview process looks like at real companies

There is no single standard, so it helps to see how named employers describe their own processes. Three published examples:

Both blog posts say their processes were a snapshot at the time of writing, so treat them as examples, not current rules. The pattern is still useful: almost every process combines a conversation about your past work, at least one technical exercise and at least one exercise where you explain a finding to non-analysts.

Your first job is to find out which formats you face. Ask the recruiter directly: “Will there be live SQL, a take-home or a case? Which database and BI tools does the team use?” The answer changes what you should practise this week.

Format 1: the live SQL task

Live SQL usually happens in a shared editor or document while an interviewer watches. You get one or two tables and a business question. The interviewer is scoring three things at once: whether the result is correct, whether you check it, and whether you can explain what you are doing while you type.

A typical task, worked through

Illustrative prompt: “We have an orders table with order_id, customer_id, order_date and amount. For each month, how many customers placed their first ever order?”

A strong candidate says the plan out loud before writing: “First I’ll find each customer’s first order date, then count customers by the month of that date.” Then writes something like this (PostgreSQL syntax):

WITH first_orders AS (
  SELECT customer_id, MIN(order_date) AS first_order_date
  FROM orders
  GROUP BY customer_id
)
SELECT DATE_TRUNC('month', first_order_date) AS month,
       COUNT(*) AS new_customers
FROM first_orders
GROUP BY 1
ORDER BY 1;

Then checks it: “The sum of new_customers across all months should equal COUNT(DISTINCT customer_id) in the orders table. If cancelled orders are in this table, I’d want to know whether a cancelled first order counts.”

That last sentence is often worth more than the query. It shows you think about definitions, which is what an analyst does all day.

Habits that score well in live SQL

• Restate the question and ask about edge cases first: duplicates, NULLs, refunds, time zones, test accounts.
• Build in small steps. Run the first common table expression on its own, look at a few rows, then add the next step.
• Sanity-check totals against a simple count you can reason about.
• Say when you are unsure of syntax. “In PostgreSQL I’d use DATE_TRUNC; in other databases the date function differs” is a perfectly good answer.

Format 2: the analytics case interview

An analytics case interview is a conversation, not a coding test. You are given a business situation and asked how you would investigate or measure it. Two prompts come up again and again in some form: “A key metric dropped; what do you do?” and “How would you measure whether this new feature worked?” The incident.io post describes exactly this kind of hypothetical and says the interviewers care about how you reason about what you should and should not measure.

Management-consulting case interviews are a different format, focused on market sizing and strategy. The analytics version is narrower: it is about metrics, data and decisions.

Worked example: “Weekly orders fell 12% last week”

The figures and company here are illustrative. A structured answer moves through four layers, in this order:

1. Is the drop real? Check the data before the business. Was there a tracking change, a delayed data load, a pipeline failure or a definition change? Compare against a second source, such as payments.
2. Is it expected? Compare with the same week last year and recent weeks. Public holidays, Ramadan timing, school holidays and pay cycles can all move order volumes.
3. Where is it concentrated? Split the metric by platform (app, web), country or city, new versus returning customers, acquisition channel and product category. A drop that sits entirely in one app version points somewhere very different from a drop spread evenly everywhere.
4. What changed at the same time? Releases, price changes, marketing spend cuts, competitor promotions, outages.

Then close with what you would recommend and how you would confirm it: “If the drop is all on the latest Android release, I’d raise it with the mobile team today and track the conversion rate on that version daily until a fix ships.”

Measuring a feature launch

For the second common prompt, structure the answer around three types of metric:

• Primary metric: the one outcome the feature was built to move, agreed before launch.
• Guardrail metrics: things that must not get worse, such as refunds, support contacts or page load time.
• Adoption metrics: who used the feature and how often, which tells you whether a flat result means “it didn’t work” or “nobody found it”.

Say how you would compare: a randomised test if one is possible, otherwise a before-and-after comparison with its weaknesses stated plainly.

Format 3: the data interview take-home

A data interview take-home gives you a dataset and an open question, and you return an analysis by a deadline. Reviewers treat it as a sample of your actual work. The Monzo post says its take-home approaches are deliberately vague so that the decisions you make are visible. In other words, the ambiguity is part of the test.

A two-hour plan

If the employer gives a time guide, respect it. incident.io’s guidance was one to two hours, with an emphasis on quality over quantity. Here is one way to spend two hours:

What separates a strong submission

The basics are the same as for any analytical work sample: the answer up front, a handful of clearly labelled charts, and claims that match the evidence (“associated with”, not “caused”, unless the design supports a causal claim). Two habits are what reviewers most often find missing:

• Data issues are documented, not hidden. “Around 3% of rows had no sign-up date; I excluded them, and including them doesn’t change the conclusion” is the kind of line reviewers look for (the percentage here is illustrative).
• You say what you would do next with more time or data. That shows judgement without breaking the time limit.

When a take-home seems too big

If a brief looks like it would take several days, it is reasonable to ask the recruiter how long they expect it to take and what they will assess. A polite question about scope is normal in hiring and tells you a lot about how the team works. If you do go ahead and run short of time, finish the core question well and list the rest as next steps.

Format 4: presenting your work

Many processes end with a presentation of your take-home or case, often to a panel that includes people outside the data team. Monzo’s final stage, for example, included an interview with someone such as a product manager or engineer. Expect three kinds of questions:

• “Why did you do it that way?” Have a one-sentence reason for each major choice: the metric definition, the exclusions, the chart type.
• “What if…?” They will change an assumption. Say how the answer might move and how you would check, rather than guessing a number.
• “So what should we do?” End every presentation with a recommendation and the next step, in plain words.

Keep it short. Ten minutes of presentation with plenty of room for questions usually goes better than twenty minutes of slides.

Preparing for the whole process in one week

1. Day 1: Ask the recruiter which formats and tools to expect. Re-read the job description and mark every tool and metric it mentions.
2. Days 2 and 3: Do timed live SQL practice out loud, ideally with someone watching. Practise checking your own results.
3. Day 4: Practise two cases aloud: one “metric dropped” and one “measure a launch”. Record yourself and listen for structure.
4. Day 5: Do a mock take-home on a public dataset with a strict two-hour limit, then write a one-page summary.
5. Day 6: Prepare two past projects you can explain in depth: the question, your method, the result and what changed because of it.
6. Day 7: Prepare your questions for the panel and rest.

Before you apply, make sure your CV shows the same evidence the interview will test: tools, datasets, and decisions your analysis changed. A data analyst resume builder can help you structure those bullet points, and an ATS resume score check will show whether the tools named in the advert actually appear in your CV. For broader questions about CVs and applications, see our resume questions hub.

Frequently asked questions

How many stages does a data analyst interview process usually have?

It varies by employer. Published examples from Monzo and incident.io describe four or five stages: a recruiter or talent call, a technical call or initial interview, a take-home task, and final interviews that include a case or a review of your take-home.

How long should a data interview take-home take?

Follow the employer’s guidance. incident.io, for example, designed its task to take one to two hours. If no guide is given and the brief looks very large, ask the recruiter what they expect.

What is an analytics case interview?

It is a spoken exercise in which you are given a business situation, such as a fall in a key metric or a new feature launch, and asked how you would investigate or measure it. Interviewers score your structure and your reasoning about metrics, not memorised answers.

Can I use Python instead of SQL in the take-home?

Often yes, but check the brief. Some take-homes ask for your SQL specifically. If the choice is open, use the tool that matches the team’s stack and that you can explain clearly.

What if I cannot finish the live SQL task?

Explain the remaining steps in words and how you would check the result. Interviewers often give credit for a clear plan and good checks, even if the final query is incomplete.

Sources

• Data hiring at Monzo: The interview process (Monzo)
• Our data interview process (incident.io)
• Data Analytics job family (GitLab Handbook)