The 12-week plan

Dataset: public bike-share trips. Decision: how many bikes to place at each station each morning. Prediction unit: station × hour. Target: departures in the next hour. Metric: MAE in bikes. Baseline: same hour last week. Leakage risks: using weather observed after the hour, using the hour's own trip count in rolling features, random splitting across time.

Use the same structure as a portfolio README and keep it to about two minutes: problem, baseline, approach, results, failures, next steps. Open with the decision the project supports and its metric ("predict next-hour departures per station to place bikes; error measured as MAE in bikes"), not the model. State the baseline ("same hour last week") and why it was the bar to beat. Describe the approach in one or two sentences, including one real design choice and its alternative. Give results as a difference from the baseline with uncertainty, on a test set the interviewer can trust: time-split, leakage-checked. Then spend real time on failure analysis: where it was weakest, which slice, and why. Close with what you'd do next. Use only numbers you measured and can reproduce. Interviewers will drill into one detail, so pick a project where you did the hand calculation and the debugging yourself.

Strong answers show a checklist, not a hunch. The questions to ask before trusting any result: was the test set truly unseen and representative, or randomly split across time? Could a feature leak the target, such as information only known after prediction time? Does the metric match the cost of errors? Is performance consistent across meaningful slices, or carried by one easy segment? Are the probabilities calibrated if someone will act on them? What happens under drift or a dependency outage? Can the result be reproduced from a clean checkout with one command? A good story: "My model jumped 15 points over baseline, which was suspicious. Ablating features one at a time showed a single rolling feature that included the current hour's count. After fixing it, the honest gain was much smaller but real." Use your own measured numbers. The interviewer is testing skepticism toward your own good news.

Describe a repeatable method with an output. Mine is three passes per topic. First, intuition: the core idea and its main picture before any formulas. Second, mechanics: work a small example by hand, such as an attention output or a backprop step, then run a reference implementation and check that the numbers match. Third, engineering: build a small deliverable against a simple baseline and write up the trade-offs and failures. I use active recall, answering questions without notes and revisiting misses a few days later, and I judge understanding with a teaching test: can I explain it simply, calculate a small case, implement it, and say how it fails? For a new job domain, I'd also read the team's existing evaluation sets and incident reports early, because they show what actually goes wrong. Give one concrete example of doing this, with the artifact you produced.

Cut scope, not rigor or rhythm. Keep the pieces that make the result trustworthy: a baseline, a held-out evaluation, failure analysis, and a short write-up. Cut the pieces that only make it bigger: extra models, a polished UI, stretch features, and a hyperparameter search beyond the obvious knobs. Concretely, I'd define the minimum viable version, the smallest thing that runs end to end and answers the core question against a baseline, ship that first, and list the rest as next steps with reasons. In the course's project ladder, the minimum for the tabular project is a baseline versus a boosted model, a cost-based threshold, a calibration plot, and a one-page failure report. A common failure is spending weeks on a demo before any evaluation exists, then having nothing defensible to show. Interviewers want to hear that you protect the evaluation, and that you communicate the cut to stakeholders early, not at the deadline.