Data Scientist Interview: Explaining a Notebook Aloud

Data Science Interview · Explain Aloud

Data Scientist Interview: Explaining a Notebook Aloud

SECTION 01Why interviewers ask you to explain a notebook aloud

A notebook is the perfect interview probe. It has a question that may or may not be well-framed, data that is definitely messier than it looks, features that leak if you are careless, a model that may be overfit, and metrics that can be cherry-picked. All of that in one file.

What the interviewer is actually scoring:

• Framing: can you state the decision the analysis informs, not just the target variable?
• Rigour: do you know where your data could leak, and how you split it?
• Judgement: can you defend your model and metric choices — and name what they cost?
• Honesty: can you say "this result is fragile" without falling apart?

Notice what is not on that list: memorising sklearn signatures, or how many models you can name.

SECTION 02Pass 1: Frame the problem and check the data

Start with the question, not the imports. The interviewer has no map yet, so give them one: what decision this notebook informs, and what data you were given.

What to say about the problem:

• The decision — "this notebook helps the retention team decide who gets an outreach call this week".
• The target and the metric — "churn in the next 30 days; I'm optimising recall at a fixed precision because a missed churner costs more than a wasted call".
• The population — "active subscribers with at least one billing cycle, excluding trials".

What to say about the data:

• The shape and sources — "about 180k rows across three tables, joined on user ID; a 6-month window".
• The checks you ran — nulls, duplicates, date ranges, and one sanity check against a known total.
• The split strategy — "time-based split, not random, because random would leak future behaviour into training".
• The leakage risk — "the cancellation_reason column is only populated after churn, so I dropped it".

SECTION 03Pass 2: Explain features and model choices

Once the map exists, talk about why you engineered the features you did and why the model is the right size for the problem. The interviewer is listening for reasoning, not library names.

Feature engineering — what to explain:

• Why each feature exists — "days_since_last_login captures engagement decay better than raw login counts".
• How you handled categoricals — target encoding with cross-fitting to avoid leakage, not plain one-hot on 400 levels.
• What you dropped and why — "I dropped the free-text support notes; the signal was there but the pipeline couldn't reproduce it reliably".

Model choice — what to explain:

• The baseline first — "I started with logistic regression and a majority-class baseline so I knew what 'good' looked like".
• Why the next model — "gradient boosting gave a meaningful lift on recall, and the data was tabular with mixed types".
• Why not something fancier — "a neural net would not beat GBM at this data size, and the interpretability cost is real for the retention team".

SECTION 04Pass 3: Evaluate with the right metric and a baseline

Evaluation is where most candidates hand-wave. The strongest ones name the metric, the baseline, the confidence range, and what the number would look like if the model were useless.

Metric — what to say:

• The metric and why — "recall at 60% precision, because a missed churner is more expensive than a wasted call".
• The baseline — "a majority-class baseline gets 92% accuracy and 0% recall, which is why accuracy is the wrong metric here".
• The lift — "the model gets 71% recall at that precision, versus 34% for the current heuristic".

Confidence and stability — what to say:

• A range, not a point — "0.71 recall with a 95% bootstrap interval of 0.68–0.74".
• A time-based holdout — "the number on the last 3 months is 0.69, which is within the interval and consistent".
• What would break it — "if the retention policy changes next quarter, the feature distributions shift and I'd want to re-fit".

SECTION 05Pass 4: Name the trade-offs and caveats

This is the pass that separates mid-level from senior. Do not recite "best practices" — name the caveat, the cost, and the condition under which you would revisit.

Caveats worth naming out loud:

• Correlation vs causation — "the outreach probably helps, but this notebook measures who would have churned, not the causal effect of the call; an A/B test would settle it".
• Distribution shift — "if pricing changes next quarter, the features move and I'd want to retrain and re-validate".
• Fairness — "I checked error rates across the two largest cohorts and they were within 3 points; a smaller cohort has too few rows to judge".

Trade-offs worth naming out loud:

• Interpretability vs lift — "I chose GBM for the lift and added SHAP explanations for the retention team, at the cost of a slower explanation workflow".
• Precision vs recall — "I optimised recall at 60% precision; if the call centre shrinks, I'd raise the precision threshold".
• Freshness vs cost — "a nightly retrain is cheaper but staler; weekly gives a better number at ~3× the training cost".

SECTION 06Mistakes that sink the explanation

These are the habits that make a competent data scientist sound unprepared. Every one of them is fixable with one rehearsal.

• Starting with the imports — "here I import pandas" tells the interviewer nothing about the analysis.
• Narrating syntax — reading code out loud is not reasoning out loud.
• Skipping the data checks — no mention of nulls, leakage or the split strategy. This is the single most common gap.
• No baseline — reporting accuracy or F1 without saying what a trivial model would score.
• No confidence range — presenting a single number as if it were a fact.
• No trade-offs — everything is "best practice", which means nothing was a decision.
• Pretending to know an API — guessing a function signature and getting it wrong costs more than saying "I'd check the docs for that".
• Vanishing down one cell — twenty minutes on a single chart and never finishing the story of the notebook.

How to rehearse:

• Do a three-minute run of the whole four-pass structure. If you can't finish in three minutes, you're too deep.
• Record yourself once and listen back. Filler words and missing structure are obvious on playback.
• Explain it to someone who doesn't write code. If they can follow the decision logic, so can the interviewer.

SECTION 07Test yourself — explaining a notebook aloud

SECTION 08Frequently asked questions

SECTION 09Related reads