On this page
- "Data" is four jobs, and you're interviewing for one of them
- What each branch actually tests
- The SQL round, and the second-highest-salary trap
- The stats and experimentation round, said plainly
- The ML round tests judgment, not vocabulary
- The case round: turn a vague question into a measurable one
- The failures that sink otherwise strong candidates
"Data" is four jobs, and you're interviewing for one of them
Who this is for
Anyone preparing for a data analyst, data scientist, ML engineer, or data engineer interview, especially career switchers and new grads who keep seeing "data" everywhere and aren't sure which loop they're actually in. If you don't know which of the four you're interviewing for, that is the first thing to fix.
The single biggest mistake candidates make happens before a single question is asked: they prep for "a data interview" as if it were one thing. It isn't. The title on the job post hides four genuinely different roles, and a panel for one will barely overlap with a panel for another. Read the job description for what it actually asks you to *do*, not the title, then prep for that.
- Data analyst lives in SQL, statistics, and business sense. The job is turning questions from the business into numbers people trust and act on.
- Data scientist lives in experimentation and modeling. The job is designing tests, building models, and reasoning carefully about whether a result is real.
- ML engineer lives in productionizing models and systems. The job is taking a model and making it serve traffic reliably, retrain, and not silently rot.
- Data engineer lives in pipelines. The job is moving and shaping data at scale so everyone else has something clean to work with.
Nobody fails the data interview. They fail the analyst interview while prepping for the scientist one, or ace the modeling round for a job that was really about pipelines.
What each branch actually tests
Here is the rough split. Every company blends these differently, and small teams expect one person to cover two columns, so treat this as a map of where the weight tends to land, not a rulebook.
| Branch | Core round | Also expect | Rarely asked |
|---|---|---|---|
| Data analyst | SQL plus stats reasoning | Business framing, dashboards, clear communication | Production code, distributed systems |
| Data scientist | Experiment design, modeling judgment | Stats depth, A/B testing, some SQL and coding | Low-latency serving, infra |
| ML engineer | Coding plus ML systems design | Serving, monitoring, drift, model lifecycle | Deep business framing, hand stats proofs |
| Data engineer | Pipelines, data modeling, SQL at scale | Batch and streaming, orchestration, data quality | Model math, experiment design |
Pro tip
If the loop has both a SQL screen and a take-home model, you are almost certainly in a data scientist or analyst track. If it has a coding screen plus a systems design round, it leans ML engineer or data engineer. The shape of the loop tells you the role.
The SQL round, and the second-highest-salary trap
Almost every analyst, scientist, and data engineer loop has a SQL screen. It is not testing whether you can recall syntax. It is testing whether you can think in sets, reach for joins and window functions without panic, and handle the edge cases that separate a working query from a correct one.
- Joins: know the difference between inner and left join in your sleep, and be ready to explain why a left join can inflate row counts when the right side has duplicates.
- Aggregation with GROUP BY and HAVING: know that WHERE filters rows before grouping and HAVING filters groups after.
- Window functions: ROW_NUMBER, RANK, DENSE_RANK, and running totals with SUM OVER. This is where strong candidates pull ahead, because most problems get clean with a window function and ugly without one.
The classic trap is "find the second highest salary." The naive answer is SELECT MAX(salary) FROM employees WHERE salary < (SELECT MAX(salary) FROM employees). It often passes the happy path and then breaks the moment the interviewer probes. Ask yourself: what if two people share the top salary? What if there is no second distinct value at all? A correct answer reasons about *distinct* values and decides, out loud, what should happen when there is no second one. That reasoning is the actual test.
The real question behind the trap
They do not care whether you memorized DENSE_RANK. They care whether you noticed ties and the empty case before they had to point them out. Say "I want the second distinct salary, and I should decide what to return if there isn't one" and you have already passed, whatever syntax you reach for next.
The stats and experimentation round, said plainly
This round filters hard, and it filters in a counterintuitive direction: people fail by sounding clever. Reciting that a p-value is the probability of observing data at least as extreme assuming the null is true wins nothing if you cannot then say what that means for the decision in front of you. Plain, correct, decision-focused beats textbook every time.
- P-value, plainly: if nothing were really going on, how surprising is a result this big? A small p-value means "this would be surprising by chance alone," not "this is important" and not "there is a 95% chance I'm right."
- A/B testing: you split traffic, change one thing, and measure. The hard parts are picking the metric before you look, choosing a sample size up front, and not peeking and stopping the moment it looks good, which manufactures false wins.
- Sampling bias: if the data you measured isn't representative of the population you care about, no amount of math fixes it. Survivors, volunteers, and weekend-only traffic all quietly lie.
- Correlation versus causation: ice cream sales and drownings rise together because both follow summer heat. Be ready to name a plausible confounder on the spot, because that is the question under the question.
The strongest answer in a stats round is usually the least fancy one. "Statistically significant" is not "true," and "we saw a lift" is not "we caused a lift." Say that out loud and mean it.
The ML round tests judgment, not vocabulary
For data scientist and ML engineer loops, the modeling round is less about whether you can name algorithms and more about whether you can be trusted with a model that touches real users. The questions look technical but they are probing for discipline.
- Bias and variance: high bias underfits and misses the pattern, high variance overfits and memorizes noise. Be able to say which way a given symptom points and what you would change.
- Overfitting and the train, validation, test split: train to learn, validation to tune, test touched once at the very end. The cardinal sin is letting test information leak into training, including tuning against the test set or scaling before you split.
- Why the metric choice matters: accuracy is a trap on imbalanced data. A model that always predicts "not fraud" can be 99.9% accurate and useless. Know when to reach for precision, recall, F1, or AUC, and tie the choice to the cost of each kind of mistake.
- Detecting model drift: a model that was good last quarter can quietly decay as the world shifts under it. You watch input distributions and output distributions over time, you track the live metric against a holdout or delayed labels, and you alert when either moves. Saying "I'd retrain on a schedule" is half an answer. The full answer is "I'd monitor for drift and retrain when it triggers."
Pro tip
When asked "how would you detect model drift," the trap is to jump straight to retraining. Detection comes first. Name what you'd monitor (input features, predictions, the live metric), how you'd compare it to a baseline, and only then talk about what you'd do when it fires.
The case round: turn a vague question into a measurable one
The business case round is where analysts and scientists are really sorted. The interviewer hands you something deliberately fuzzy, like "engagement is down, what would you do," and watches whether you can turn fog into something you can actually measure and act on. The worst move is to leap straight to a model or a chart. The best move is to slow down and define the problem before solving it.
- 1
Define the metric
Pin down what "engagement" even means here. Daily active users? Sessions per user? Time spent? Pick one primary metric and say why. A vague question has no answer until you make it specific.
- 2
Scope and segment
Is the drop everywhere or in one segment, platform, region, or cohort? Slicing first often turns a mystery into an obvious cause, like a broken Android release, before any modeling.
- 3
Form hypotheses
List a few plausible causes ranked by likelihood: a product change, seasonality, a tracking bug, a competitor, a pricing change. Name the cheap-to-check ones first.
- 4
Decide how you'd test each
For each hypothesis, say what data would confirm or kill it. Tie it back to a number. This is where you show you reason from evidence, not vibes.
- 5
State the action and how you'd measure it
End on what you would actually do and the metric that tells you it worked. A case answer that doesn't loop back to a measurable outcome isn't finished.
Jumped straight to a solution
Engagement is down, so I'd build a churn prediction model to figure out which users are going to leave, probably a gradient boosted model since those usually perform best, and then we could target them with re-engagement emails.
Defined the problem first
First I'd pin down the metric, let's say weekly active users, and confirm the size and timing of the drop. Then I'd segment: is it all users or one platform, region, or cohort? That alone often finds the cause. My top hypotheses would be a recent product or tracking change, seasonality, and an acquisition shift, and I'd check the cheap ones first, like whether a release date lines up with the drop. Only once I understood the driver would I decide on an action, and I'd define the metric up front that tells me whether it worked.
- The weak version names a model and even an algorithm before defining what "engagement" means or how big the drop is. That is the number-one failure in this round.
- The strong version makes the question measurable first, then segments, because slicing the data frequently solves the case with zero modeling.
- It treats a model as one possible action chosen after diagnosis, not the reflexive first move.
- It ends on a metric, so success is defined before any work starts.
The failures that sink otherwise strong candidates
| The failure | What it signals | What to do instead |
|---|---|---|
| Reaching for a fancy model first | You optimize for impressive, not useful | Start with the simplest thing that could work and earn the complexity |
| Ignoring data quality | You'll ship conclusions built on garbage | Ask about nulls, duplicates, and how the data was collected, out loud |
| No business framing | You can compute but can't decide | Tie every answer back to the decision and the metric it moves |
| Peeking at an A/B test early | You don't understand why the rules exist | Fix sample size and the metric up front, then wait |
| Confusing significance with importance | You'll over-trust noise | Separate "is it real" from "is it big enough to act on" |
Walk in knowing this
- Find out which of the four roles you're interviewing for and prep for that one, not "data" in general.
- In SQL, the second-highest-salary trap is about ties and the empty case. Reason about distinct values out loud.
- In stats, plain and decision-focused beats textbook. Significant is not true, and correlated is not caused.
- In ML, they test discipline: clean train, validation, test splits, a metric tied to the cost of mistakes, and drift detection before retraining.
- In the case round, make the vague question measurable first, segment, then act. Never lead with a model.
- Across all of it, the common thread is judgment over flash. The simple, honest, evidence-tied answer wins.
Reading is step one. Now do it for real.
When you're ready, the platform has live mock interviews and portfolio-grade capstone projects you can actually talk about.
Keep reading
This is general, educational career guidance, not legal, financial, immigration, or professional advice. Examples are illustrative and simplified. Norms vary widely by country, company, role, and over time, so always verify what applies to your own situation. Nothing here guarantees an interview, an offer, or any particular outcome.