Data Scientist Interview: Explaining a Portfolio Aloud

Data Science Interview · Explain Aloud

Data Scientist Interview: Explaining a Portfolio Aloud

SECTION 01Why interviewers ask you to explain a portfolio aloud

A portfolio is the perfect interview probe. It has a question that may or may not be well-framed, data that looks cleaner in the README than it actually was, a model chosen for reasons you might not remember, and a result that can be presented honestly or inflated. All of that in one repository.

What the interviewer is actually scoring:

• Framing: can you state the decision the project 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: the leaderboard position, the number of models you tried, or how neat the notebook looks.

SECTION 02Pass 1: Frame the problem and the user

Start with the question, not the libraries. The interviewer has no map yet, so give them one: what decision this project informs, and who would act on it.

What to say about the problem:

• The decision — "this project helps a support team decide which tickets to escalate first".
• The target and the metric — "predict escalation within 24 hours; I'm optimising recall at a fixed precision because a missed escalation costs a customer".
• The population — "tickets from paying customers only, excluding internal and spam tickets".

What to say about the data:

• The shape and sources — "about 90k tickets across three years from one helpdesk export".
• The checks you ran — nulls, duplicates, date ranges, and one sanity check against a known monthly total.
• The split strategy — "time-based split, not random, because random would leak future tickets into training".
• The leakage risk — "the resolution_text column is only populated after a ticket closes, so I dropped it".

SECTION 03Pass 2: Explain the method and the checks

Once the map exists, talk about the choices: the features, the baseline, 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 — "hours_since_first_reply captures support responsiveness better than raw reply counts".
• How you handled categoricals — target encoding with cross-fitting to avoid leakage, not plain one-hot on 200 categories.
• What you dropped and why — "I dropped the free-text subject line; the signal was there but the pipeline couldn't reproduce it reliably for new tickets".

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 transformer would not beat GBM at this data size, and the latency cost is real for a support queue".

SECTION 04Pass 3: Present the result with a range, not a point

Results are 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 70% precision, because a missed escalation is more expensive than a wasted review".
• The baseline — "the majority-class baseline gets 88% accuracy and 0% recall, which is why accuracy is the wrong metric here".
• The lift — "the model gets 62% recall at that precision, versus 29% for the current heuristic".

Confidence and value — what to say:

• A range, not a point — "0.62 recall with a 95% bootstrap interval of 0.58–0.66".
• A time-based holdout — "on the last 3 months the number is 0.60, which is within the interval and consistent".
• The business value — "at the current ticket volume, that lift catches roughly 340 more escalations a month, and the support lead estimated the saved cost at around ₹4–5 lakh a month".

SECTION 05Pass 4: Name the trade-offs and the next step

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 — "this project predicts which tickets will escalate; it does not measure whether a faster response prevents escalation — an experiment would settle that".
• Distribution shift — "if the support product changes next quarter, the features move and I'd want to retrain and re-validate".
• Coverage — "the model was trained on one helpdesk export, so I wouldn't assume it transfers to a second product line without checking".

Trade-offs and next steps worth naming:

• Interpretability vs lift — "I chose GBM for the lift and added SHAP explanations for the support leads, at the cost of a slower explanation workflow".
• Precision vs recall — "I optimised recall at 70% precision; if the review team shrinks, I'd raise the precision threshold".
• The next step — "the highest-value next step is an experiment: route a random slice of predicted escalations to fast review and measure whether the outcome actually improves".

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 project.
• Narrating the notebook — reading cell by cell is not reasoning, it's transcription.
• 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 business value — a great model with no story about who uses it and what it saves.
• No trade-offs — everything is "best practice", which means nothing was a decision.
• Vanishing down one chart — twenty minutes on a single plot and never finishing the story of the project.

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 portfolio aloud

SECTION 08Frequently asked questions

SECTION 09Related reads