What do data analyst interviews actually test?

Who you're actually talking to at each stage

A data analyst process is rarely one conversation. It's usually three or four, each run by someone with a different job and a different thing they're checking.

The recruiter screen is not testing your analytical ability. It's confirming you can talk about your work in plain English, that your salary expectation and notice period line up with the role, and that you haven't misread the job title (analyst, analytics engineer and data scientist get used loosely, and adverts sometimes want one while titled as another).

The technical round is usually run by someone who does the job day to day — a senior analyst or an analytics manager, sometimes a data engineer if the role touches a lot of pipeline work. This is the SQL and stats round, and it's the one candidates under-prepare for because they assume seniority means less coding, which is backwards: the more senior the role, the more likely you're expected to write correct SQL under time pressure without a linter catching your mistakes.

The case study or "business problem" round is often run by someone from the team you'd actually support — a product manager, a marketing lead, a finance business partner. They are not grading your SQL syntax. They're checking whether you can take a vague question like "why did signups drop last month" and turn it into something measurable without being told how.

A final round with a hiring manager or director is usually about judgement and fit: how you handle disagreement with a stakeholder, how you prioritise when three people want conflicting analyses by Friday.

The technical assessment: what it actually looks like

For most data analyst roles in tech, expect one or more of:

• A live or recorded SQL test. Not trivia about syntax, but a query against a schema with duplicate rows, nullable foreign keys, or a many-to-many join that will silently inflate your counts if you get it wrong. Common asks: window functions (ROW_NUMBER() OVER (PARTITION BY ...) to deduplicate or rank), a self-join to compare a user's behaviour period over period, and a GROUP BY with a HAVING clause rather than a WHERE. If you can write a correct query but can't explain why you deduplicated before aggregating, that gap shows.
• A take-home with a real or realistic dataset. You'll usually be asked to answer a business question, not just produce charts. Interviewers read these for whether you stated your assumptions (how did you define an "active user"?), whether you flagged data quality issues instead of quietly working around them, and whether your recommendation follows from the numbers you showed or reads like it was decided beforehand.
• A tool walkthrough. If the job lists Looker, Tableau, Power BI or Mode, you may be asked to screen-share and build something live, or to critique an existing dashboard. This is checking whether you can choose a chart type that doesn't mislead, not whether you know every menu.
• Light statistics. For roles touching experimentation, expect questions on what a p-value actually means, how you'd size a sample for an A/B test, and what happens to your confidence when you run five metrics off one test and call the smallest p-value the win.

Some companies skip the take-home entirely and do all of this live, on a shared screen, because take-homes can be outsourced or take candidates six unpaid hours. Whether that's better for you depends on whether you think faster than you write; there's no consensus among hiring teams on which format is fairer, and you should expect either.

The questions that are really testing something

A handful of standard-sounding questions carry almost all the signal. Here's what they're actually checking.

"Walk me through an analysis that changed a decision." This is not asking for a project summary. It's checking whether you can trace a line from a specific number, to a specific person, to a specific action they took that they wouldn't otherwise have taken. If your answer ends at "and I found that conversion was lower on mobile," you've described an observation, not an outcome. The interviewer is listening for what happened after you sent the analysis.

"How would you measure whether this feature is working?" This tests whether you default to a metric or interrogate the question first. A strong answer asks what "working" means to the business before naming a metric, flags at least one plausible way the obvious metric could be misleading (a feature that boosts engagement by making something harder to find isn't a win), and names a guardrail metric alongside the headline one. A weak answer jumps straight to "I'd track daily active users."

"Tell me about a time your analysis was wrong, or you'd have done it differently." This is checking intellectual honesty, and it's harder to fake than people think because a rehearsed non-answer ("I don't think I've been wrong, but if I had to say something...") is instantly recognisable to anyone who's shipped analysis for a living. What they want is: what was wrong, how you found out, and what you changed about how you work as a result.

A live SQL problem with a twist — duplicate rows, a join that fans out, a date field with mixed formats. This tests whether you check your row counts before and after a join, out loud, without being told to. Analysts who've been burned by a fan-out join do this automatically. Analysts who haven't, don't, and the interviewer usually knows within thirty seconds which kind they're watching.

What a shallow answer sounds like

To someone who does this job, a few patterns give away a candidate who hasn't actually sat with the mess of real data.

Describing the tool instead of the decision — "I built a dashboard in Tableau with filters for region and date" — and stopping there. Nobody asked what the dashboard looked like; they asked what changed because of it.

Reciting the definition of a p-value without being able to say what it doesn't tell you. If someone can't explain, in their own words, why a statistically significant result on a tiny sample isn't automatically worth acting on, they've memorised the term rather than used it.

Jumping straight to a chart or a query in a case study without first asking what the business actually means by the term in the question — "engagement," "churn," "active" — mean different things at different companies, and analysts who've worked with real stakeholders know to ask before they build.

Claiming ownership of an analysis with no mention of anyone pushing back on it. Real analytical work involves someone in the room disagreeing with your number or your framing. An answer with no friction in it is either a very easy job or an edited story.

And in SQL specifically: writing a query that compiles but silently double-counts because of an unhandled join, and not noticing, and not checking.

What to actually do before the interview

Pick one project from your own history — ideally one with genuinely messy data — and rehearse explaining it in under a minute: the question, what you found, what changed. If you can't get it under a minute, you probably haven't finished separating the finding from the noise around it.

Practise SQL against a schema with duplicates and nulls, not clean tutorial data. Specifically drill self-joins, window functions for deduplication and ranking, and checking row counts before and after a join.

Prepare one honest story about being wrong, with the correction, not just the mistake.

Before a case-study round, write down two or three questions you'd ask a stakeholder before touching the data, and practise asking them out loud rather than jumping to a chart.

If you're sending out a lot of applications and getting little back, the interview stage above is usually not the bottleneck — it's getting invited to it. jobmarket.pro reads each advert against your actual profile and tells you where you genuinely fit before it prepares anything on your behalf.