Interview Insights · ML Engineer Notebooks
Why Every ML Engineer Should Practice Explaining Their Notebook Aloud
Quick summary — Notebook walkthrough
A notebook walkthrough tests whether you can tell the story of your work, not whether you can scroll. Interviewers ask you to share a notebook to see how you think, in order. If the notebook has no structure, hidden state or charts with no purpose, even good work looks messy. Practising the walkthrough aloud pushes you to add a summary at the top, make sure it runs from a clean restart, and connect every chart to a decision. Then you can guide the interviewer instead of hunting for cells.
In this guide you will learn:
- How to structure a notebook so it explains itself on screen
- Why hidden state ruins live walkthroughs and how to prevent it
- Commands to re-execute and clean a notebook before sharing
- How to narrate EDA so every chart leads to a decision
- A walkthrough script that fits a ten-minute slot
SECTION 01A notebook on screen share is a story, not a log
Here 'notebook' means the Jupyter or Colab notebook where your project lives. In daily work, notebooks grow like a lab log: try something, print it, try something else. That is fine while exploring. It is not fine when an interviewer is watching your screen and you have ten minutes.
When I watch a candidate share a log-style notebook, I see long scrolling, printed dataframes with fifty columns and cells that were clearly run out of order. The work may be good, but I cannot follow it. A walkthrough-ready notebook reads top to bottom: what the goal was, what the data looked like, what decisions were made and why, and what the result was against a baseline.
| Notebook section | Log-style version | Walkthrough-ready version | What to say on screen |
|---|---|---|---|
| Top | Imports and a file path | Markdown summary: goal, data, final result | Here is the whole project in four lines |
| Data | df.head() with fifty columns | Shape, dtypes, null counts and asserts | These checks guarantee the input is what I expect |
| Middle | Dozens of experiments | One section per decision with a reason | This chart is why I dropped this feature |
| End | Last model printed | Baseline vs final table and error slices | Here is what improved and where it still fails |
# [markdown] Churn prediction: summary
# Goal: probability a subscriber cancels within 30 days
# Data: 12 months of usage and billing, one row per customer
# Result: recall on churners beats baseline on a time split
# Read sections 3 and 5 first if short on time
# [markdown] 1. Setup
# [markdown] 2. Load data and check it
# [markdown] 3. Key decision: time-based split
# [markdown] 4. Features (with reasons)
# [markdown] 5. Baseline vs final model
# [markdown] 6. Error analysis by segment
# [markdown] 7. Limits and next steps
# [markdown] Appendix: experiments that did not work"Let me start at the top, where I summarised the whole
project in four lines.
The goal was to predict which subscribers cancel in the next
30 days. The main decision was using a time-based split.
The final model beat a logistic regression baseline on recall.
I'll show you the data checks quickly, then the split
decision, then results. The appendix has failed experiments
if you want to see those. Where would you like to start?"
Notice the appendix. Failed experiments are valuable evidence, but they should not interrupt the main story. Moving them to the end keeps the walkthrough clean while keeping your honesty visible.
SECTION 02Hidden state: why your notebook breaks live
The most painful live moment is when the interviewer says 'can you run that cell?' and the screen fills with a NameError. It happens because notebooks keep state between cells. You defined a variable in a cell you later deleted, or ran cells in a different order, and the notebook only worked because of memory left over from an earlier session.
The fix is simple and should become a habit: restart the kernel and run all cells from top to bottom before any interview. Better still, execute it from the command line, which proves it runs without any leftover state. Add a few assert cells so the notebook checks its own assumptions as it runs.
| Problem | Symptom on screen | Prevention | What it signals if it happens |
|---|---|---|---|
| Deleted cell still in memory | NameError after restart | Restart kernel and run all before sharing | Work was not reproducible |
| Cells run out of order | Execution counts jump around | Re-run top to bottom, check counts are in order | Results may not match the code |
| Hard-coded local path | FileNotFoundError on another machine | Relative paths from the repo root | Only works on one laptop |
| Silent data change | Different numbers than the README | Assert cells on shape and key values | Numbers cannot be trusted |
# Run the notebook from a clean kernel, save executed copy
jupyter nbconvert --to notebook --execute notebooks/churn.ipynb \
--output churn_executed.ipynb
# Fail loudly if any cell takes too long (seconds)
jupyter nbconvert --to notebook --execute notebooks/churn.ipynb \
--ExecutePreprocessor.timeout=600 --output churn_executed.ipynb
# Strip outputs before committing, to keep diffs readable
jupyter nbconvert --clear-output --inplace notebooks/churn.ipynb
# Optional: export a read-only HTML copy to share
jupyter nbconvert --to html notebooks/churn_executed.ipynbimport pandas as pd
df = pd.read_csv("data/customers.csv", parse_dates=["signup_date"])
# The notebook checks its own assumptions as it runs
assert df["customer_id"].is_unique, "duplicate customers"
assert df["churned"].isin([0, 1]).all(), "label must be 0/1"
assert df["monthly_fee"].ge(0).all(), "negative fees found"
assert df["signup_date"].max() <= pd.Timestamp("2026-01-01"), \
"rows after the snapshot date"
print(df.shape)
print(df.isna().mean().sort_values(ascending=False).head(5))
When an interviewer sees asserts at the top of your notebook, they immediately trust the numbers further down. It is a small addition that changes the tone of the whole walkthrough.
SECTION 03Narrating EDA so every chart earns its place
Exploratory data analysis is where notebook walkthroughs most often lose the interviewer. Candidates show a correlation heatmap, a few histograms and a pair plot, then say 'I was exploring the data'. The interviewer's natural question is: 'And what did you do because of it?'
Practising aloud fixes this quickly. For each chart, you should be able to finish the sentence 'This showed me ___, so I ___.' If you cannot, the chart belongs in the appendix or should be removed. A short markdown cell under each chart, written in that form, makes your narration almost automatic.
| Chart | What it showed | Decision it led to | Sentence to say |
|---|---|---|---|
| Histogram of monthly fee | Strong right skew with a long tail | Log transform for the linear baseline | Skew was hurting the linear model, so I logged it |
| Churn rate by signup month | Recent cohorts churn more | Time-based split, cohort feature | Behaviour changed over time, so a random split would mislead |
| Null share per column | One field mostly empty | Dropped it, kept a missing flag | Too sparse to use, but missingness itself was informative |
| Correlation heatmap | Two usage features almost identical | Kept one of them | They carried the same signal, keeping both added noise |
import pandas as pd
import matplotlib.pyplot as plt
df = pd.read_csv("data/customers.csv", parse_dates=["signup_date"])
rate = (df.assign(cohort=df["signup_date"].dt.to_period("M"))
.groupby("cohort")["churned"].mean())
ax = rate.plot(marker="o", figsize=(8, 3))
ax.set_title("Churn rate by signup month")
ax.set_ylabel("share churned")
plt.tight_layout()
plt.show()
# [markdown cell under the chart]
# **What this showed:** newer cohorts churn more than older ones.
# **So I:** used a time-based split and added a cohort feature,
# because a random split would mix old and new behaviour."This chart is the reason for my biggest decision.
Churn is clearly higher for customers who signed up more
recently. If I had split randomly, the model would train and
test on a mix of old and new behaviour, and the score would
look better than it would on next month's customers.
So I split by time: train on earlier signups, validate on the
latest. The score went down a bit, but it is the honest one.
The note under the chart says exactly that, so anyone reading
the notebook gets the same story."
When every chart has a 'so I' note, the notebook becomes self-explaining. You will find you can walk through it in ten minutes without rehearsing each sentence, because the notebook leads you.
SECTION 04Prepare your notebook for a ten-minute walkthrough
Use these tabs the day before an interview. They cover cleanup, a timed script and the questions most often asked while a notebook is on screen. In Uncodemy mock interviews we run exactly this kind of screen-share walkthrough, because it exposes notebook habits quickly.
[ ] First cell is a markdown summary (goal, data, result)
[ ] One markdown header per section, numbered
[ ] Restart kernel + run all completed without errors
[ ] Execution counts are in order top to bottom
[ ] No absolute paths like C:/Users/... in any cell
[ ] Assert cells check shape, labels and key ranges
[ ] Every chart has a 'what it showed / so I' note
[ ] Failed experiments moved to an appendix
[ ] Large raw outputs cleared or collapsed
[ ] Final results table shows baseline vs model0:00 Summary cell: goal, data, result, map of sections
1:00 Data checks: shape, asserts, one data issue found
2:30 Key decision cell (e.g. split) with its chart
4:30 Features: two or three with reasons
6:00 Baseline vs final table
7:30 Error analysis: weakest segment
8:30 Limits and next steps
9:00 Pause: 'Which part would you like to see in detail?'
Practise with a timer, sharing your screen to a friend.Common questions while your notebook is shared:
- Can you rerun this cell?
- Where did you split the data?
- Why is this chart here?
- Where is the scaler fitted?
- What happens if this column has a new category?
- Which cell produces the number in your README?
- What did you try that is not in the main flow?
For each, know which cell to scroll to.
SECTION 05Notebook habits that make walkthroughs easy
Build these habits while you work, and walkthrough preparation becomes a ten-minute check instead of a night of cleanup.
- Write the summary cell first — Start every notebook with a summary cell and update it as results change. It keeps you focused and is ready for any interview.
- Restart and run often — Make restart-and-run-all a habit at the end of each work session, not only before interviews. Bugs are easier to fix when they are new.
- Move code into functions — Put repeated cleaning code into a small module and import it. The notebook stays readable and the logic becomes testable.
- Name cells by decision — Use headers like 'Decision: drop sparse fields' rather than 'Cleaning 2'. They become your talking points.
- Keep raw output short — Use head(5), selected columns and summaries instead of printing whole dataframes. Long output buries your story.
SECTION 06Interview Q&A — Notebook walkthrough
Q1Can you walk me through your notebook?
Sure. The top cell summarises the goal, data and result. Section two runs data checks with asserts. Section three shows the key decision, a time-based split, with the chart that led to it. Then features, baseline versus final model, and error analysis. Failed experiments are in an appendix. Where would you like to start?
Q2How do you make sure your notebook is reproducible?
I restart the kernel and run all cells before sharing, and I also execute it with nbconvert from the command line, which proves it runs without leftover state. Paths are relative, seeds are fixed, and assert cells check the data shape and labels.
Q3Why is this chart in your notebook?
It shows churn rising for newer signup cohorts. That is why I used a time-based split and added a cohort feature, because a random split would mix old and new behaviour and overstate performance.
Q4Where in this notebook do you fit the scaler, and why does it matter?
Inside a scikit-learn Pipeline that is fitted only on the training split, in section five. If I fitted it on the full data before splitting, validation statistics would leak into training and the score would be slightly optimistic.
Q5Would you put this notebook code into production as it is?
No. I would move data loading, cleaning and feature code into a module with tests, keep the model training in a script with configuration, and use the notebook only for exploration and reporting. The notebook shows the reasoning; production needs testable code.
SECTION 07Test yourself — Notebook walkthrough quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
ML Engineer interview: How do I present a Jupyter notebook in an interview?
Start at a markdown summary cell, follow numbered sections, show data checks briefly, focus on the key decision and the results against a baseline, then pause and ask what the interviewer wants to see in detail.
How do I clean up a Jupyter notebook before sharing?
Add a summary cell and section headers, move failed experiments to an appendix, remove or shorten raw outputs, use relative paths, then restart the kernel and run all cells to make sure it works.
What is hidden state in Jupyter notebooks?
It is leftover memory from cells that were deleted, edited or run out of order. The notebook may appear to work but fails after a restart. Restart-and-run-all exposes it.
Should I share a notebook or a script for an ML project?
Share both if you can. The notebook explains your reasoning with charts and notes, while scripts or modules show clean, testable code. Interviewers value seeing both.
How long should a notebook walkthrough take in an interview?
Plan for about ten minutes for the main story, then let the interviewer choose where to go deeper. Practise with a timer while sharing your screen.
Is there a course that covers ML Engineer interview answers?
Yes. Uncodemy's Machine Learning Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise ML Engineer interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Build notebooks that explain your thinking
Our Machine Learning Training Course teaches clean, reproducible notebooks and code alongside ML methods, with regular screen-share walkthrough practice before real interviews.
Talk to a counsellor for current fees- Reproducible notebook practice
- EDA with clear decisions
- Screen-share mock interviews
- Weekday & weekend batches