ChannelPulse
Which interview are you actually in
One title covers at least four jobs, and every company's loop tests a different mix of them. This lesson maps the rounds to the jobs, shows how to identify which mix you are facing before the first question, and covers the take-home — the stage with the highest rejection rate and the least feedback.
What you'll be able to do
- Name the four jobs hiding under the title, and which rounds test each
- Identify the mix a specific loop is testing from the job posting and the recruiter call
- Recognise the two failure modes that get take-homes rejected regardless of modelling skill
- Decide what to prepare when you cannot tell which version you are facing
There is a specific failure that only happens in data-science loops. A candidate prepares hard, answers competently, and is rejected for being "not quite the right fit" — because they prepared for a different job than the one being hired for. The title did not tell them, and they did not ask.
"Data scientist" is at minimum four jobs:
| The job | What the day looks like | What the loop leans on |
|---|---|---|
| Product analytics | Define metrics, diagnose movements, size and read experiments | SQL, experiment design, a product case |
| Experimentation / inference | Run the testing platform, causal estimates when a test isn't possible | Statistics depth, power and MDE, quasi-experimental methods |
| Machine learning | Train, evaluate and ship models | ML theory, evaluation, ML system design, coding |
| Data / analytics engineering | Pipelines, models, the tables everyone else queries | SQL depth, warehouse modelling, software engineering |
The same eight-ish round types get shuffled across those four, and the shuffle is the whole thing:
- SQL — nearly universal, and the round with the highest elimination rate because it is pass/fail in a way the others are not.
- Probability and statistics — conditional probability, distributions, estimators, and the interpretation questions that catch people who can compute but not explain.
- Experiment design — power, minimum detectable effect, what to do about peeking and about twenty simultaneous metrics.
- ML theory — bias–variance, regularisation, what breaks when you deploy.
- ML system design — the recommender or fraud-detection design round; the ML sibling of a system-design interview, and scored the same way.
- Product case — "engagement dropped 8%, what do you do", or "how would you measure success for this feature".
- Coding — usually lighter than a software loop, usually pandas or plain Python rather than graph algorithms.
- Take-home — a dataset and a vague question, two to eight hours, and the highest silent rejection rate of any stage.
Reading the mix before you're in it
Three signals, in increasing order of reliability.
The posting's verbs. "Partner with product to define metrics and measure launches" is analytics. "Build and deploy models serving X" is ML. "Design experiments and develop causal methodology" is inference. "Own the semantic layer" is data engineering. The nouns are marketing copy; the verbs are the job.
Who you report to. A data scientist inside a product org does product analytics. One inside an ML platform team does ML. One inside a central data-science org may do either, and that is the case where you should ask directly.
The recruiter call. Ask, in these words: "What are the rounds, and what should I brush up on for each?" This is a routine question with a routine answer, and recruiters generally answer it accurately because their incentive is for you to pass. You will typically get the round list and sometimes the format of each. That single question is worth more than a week of untargeted study.
Take-homes are graded on things nobody tells you about — how you frame the question, what you leave out, and whether the writeup can be read by someone who will not run your notebook. This is the clearest walkthrough of that in public, and it maps directly onto the section below.
The take-home, where preparation goes to die
Take-homes reject more people than any other stage, and the rejections are rarely about modelling. Reviewers describe two dominant failure modes, and neither is statistical.
Answering a different question than the one asked. The prompt is deliberately underspecified — "here is transaction data, tell us something interesting" — and the failure is producing a tour of the dataset instead of a decision. What reviewers look for is a stated question, a stated answer, and the reasoning between them. A notebook with forty cells of exploration and no conclusion reads as someone who cannot finish.
Treating it as a modelling exercise when it is a communication exercise. The most common concrete mistakes are all presentation: no summary at the top, no statement of assumptions, results that cannot be reproduced by running the notebook top to bottom, and a model reported without a baseline to compare it against. A logistic regression with a stated baseline and an honest limitations section beats a gradient-boosted ensemble with neither, and it beats it consistently.
Two more things worth doing because they are cheap:
- State the time you spent, and what you would do with more. If the brief says four hours and you took four hours, say so and list what got cut. It converts an incomplete analysis from a gap into a scoping decision.
- Put a baseline in. Predict the majority class, or last week's value, and report your model against it. Without a baseline, no accuracy number means anything, and reviewers know that even when candidates forget it.
When you genuinely cannot tell
Some loops won't tell you, and generalist postings are honestly generalist. In that case the priority order is not "everything equally":
- SQL. It appears in every version of this job, it is the fastest to improve, and it is pass/fail. Window functions, multiple joins, cohort and funnel shapes.
- Experiment reading and sizing. Nearly every version has to interpret a test, and the arithmetic is small and learnable.
- Metric definition and diagnosis. The "a number moved, what now" case appears in analytics, inference and ML loops alike.
- Evaluation. Precision, recall, and what a threshold costs. Even non-ML roles get asked this, and it is where confident wrong answers are most common.
The next three lessons are exactly items 2, 4 and 3, in that order — the arithmetic first, because it is the one you cannot bluff.
What's next
Start with the round nobody can improvise: a question about a test's size or its significance has a right answer that follows from four numbers. We will do that arithmetic, reproduce a published worked example to confirm it, and then look at the part of the calculation almost every candidate skips.