Project Deep Dives¶

Presenting a project in an interview is one of the most differentiated parts of the process — it is the one place where you have full control of the content. Yet most candidates waste this opportunity by narrating what they did rather than demonstrating how they think. A strong project walkthrough shows the interviewer exactly how you approach problems, make tradeoffs, and learn from results.

What Interviewers Are Looking For in a Project Walkthrough¶

Interviewers are not evaluating whether your project was impressive in absolute terms. They are evaluating four things:

Problem understanding: did you know why the problem mattered before you started solving it? Can you articulate the business or research context without prompting?
Decision-making quality: did you make deliberate choices, or did you default to the most familiar tool? Can you explain why you chose this model, this metric, this approach — and what you considered but rejected?
Self-awareness about results: can you honestly evaluate what worked and what didn't? Candidates who say "it went great!" for every project are less credible than candidates who say "we got X, but in retrospect Y was the limiting factor and here is what I'd change."
Communication: can you calibrate the level of technical depth to your audience? In an interview, you should be able to go from a 30-second summary to a 10-minute deep dive and back, smoothly.

The Project Narrative Structure¶

Every project walkthrough should follow this five-part structure:

1. Problem (30–60 seconds) Context, business importance, why this was worth solving. The goal is to make the interviewer care before you explain what you did.

"Our e-commerce platform was losing around 15% of completed checkouts to delivery-related cancellations — customers were abandoning orders when the estimated delivery date was too far out. The existing estimate was a simple average that didn't account for regional variation or product-specific handling times. The business wanted to know whether a better estimate would reduce cancellations."

2. Data (1–2 minutes) What data was available, what its limitations were, how you processed and validated it. Most candidates skip this step. Most real ML projects fail here.

"We had two years of order history — about 4 million orders — with actual delivery timestamps. The challenge was that delivery times had changed significantly after a warehouse expansion 8 months in, so the earlier data was misleading. We used only the last 14 months. We also discovered that ~12% of orders had no delivery timestamp (cancelled, returned, or lost), which we had to handle carefully — we couldn't just drop them because cancellations were correlated with late deliveries, which would bias the model."

3. Approach (2–4 minutes) What you built and why. Focus on decisions, not steps. What alternatives did you consider and why did you choose this path?

"We started with a gradient boosting model (LightGBM) with features for: product category, destination zip code cluster, warehouse of origin, carrier, and day of week. The key design choice was treating delivery time as a regression target rather than a binary 'on time / late' — because we needed to show a specific estimated date, not just a probability. We considered quantile regression to produce a confidence interval, which would have been more useful to the product team, but the engineering complexity of displaying an interval was out of scope for this iteration."

4. Results (1–2 minutes) Quantify the outcome — in business terms, not just model metrics. Always connect the model metric to the business outcome.

"On the held-out test set, our RMSE improved from 2.1 days to 0.9 days compared to the existing average-based estimate. In an A/B test with 8% of traffic over three weeks, the checkout page showing the model's estimates saw a 4% reduction in abandonment at the delivery date display step. That translated to approximately $2M annualised revenue recovery at our order volume."

5. Learnings (1 minute) What would you do differently? What surprised you? This is the part that separates candidates with real experience from those who only ran experiments in notebooks.

"If I did it again, I'd invest earlier in understanding the cancellation data — the 12% of orders with no delivery timestamp turned out to be the most important segment for the business, and we ended up building a separate cancellation risk model later. I should have seen that coming in the data exploration phase."

How to Talk About a Project Where Results Were Not Great¶

Not every project ships with impressive metrics. Real ML projects are full of models that didn't make it to production, A/B tests that came back flat, and analyses that contradicted the hypothesis.

Why this is not a weakness, framed correctly: Interviewers value honesty and self-awareness. A candidate who says "my model achieved 0.93 AUC on everything" for every project is either very lucky or not being truthful. A candidate who says "we built the model, the offline metrics looked great, but the A/B test came back flat — and here is what we think we got wrong" demonstrates maturity.

Framework for talking about a project with poor results:

Own the result clearly: don't bury it or hedge. "The model didn't outperform the baseline in the online test" is cleaner than "the results were somewhat mixed."
Diagnose it honestly: what was the root cause? Data quality? Wrong metric? Deployment issue? Distribution shift between training and production? Showing that you understand why it didn't work demonstrates more than showing it did.
What you learned: this is the most important part. A failed project that taught you something valuable is more valuable than a successful project you didn't learn from.
What you would do differently: concrete, specific, not vague. Not "I would work more carefully" — that is meaningless. Specific: "I would build the monitoring first, so we'd know immediately when the feature distribution shifted between our training set and production traffic."

Common Traps in Project Presentations¶

Trap 1: Talking about code instead of decisions "We used pandas to load the data, then we ran some EDA, then we trained an XGBoost model..."

This tells the interviewer nothing. They know how to use pandas. What they want to know is: why XGBoost, what features mattered, what did the EDA reveal that changed your approach?

Trap 2: Skipping the "so what" Reporting model metrics without connecting to business impact. "We achieved 0.87 AUC" is meaningless without context. 0.87 AUC compared to what? What did that correspond to in dollars, users affected, decisions changed?

Trap 3: Overselling the complexity Using technical jargon to imply sophistication ("we used a multi-head attention mechanism for cross-feature interactions") when the result would be better explained in plain language. Complexity in a model is a cost, not a virtue. If a simpler model worked, say so.

Trap 4: Ignoring what didn't work Presenting only the successful path makes you sound either inexperienced or dishonest. "We tried random forests first but they were significantly slower to train at our data volume without meaningfully better performance, so we moved to LightGBM" is a better answer than pretending you chose LightGBM from the start.

Trap 5: Not knowing your numbers "It improved performance by a significant amount." How much? If you don't know the numbers from your own project, you weren't paying attention. Before any interview, review your project metrics and know them precisely.

Preparing Three Levels of Depth¶

For every project you might discuss, prepare three versions of the answer:

30-second version (the elevator pitch): problem, approach, result — one sentence each. Used when the interviewer is scanning your background at the start.

"I built a delivery time estimator for an e-commerce platform using gradient boosting on order history data. The model reduced prediction error from 2.1 days to 0.9 days, and in an A/B test produced a 4% reduction in checkout abandonment."

2-minute version (the standard walkthrough): adds the key data challenge, one important design decision, and the business impact framing. Used when the interviewer says "tell me about a project you're proud of."

10-minute version (the deep dive): full five-part structure. Used when the interviewer says "let's dig into this" and starts asking follow-up questions. You should be able to sustain a 10-minute technical conversation about any project on your resume.

Prepare these in advance. Write them out. Practice them out loud. The difference between a memorised answer and a genuine answer is that the genuine version can handle follow-up questions from any direction.

How to Discuss a Team Project vs a Solo Project¶

For team projects: Be explicit about your specific contribution without taking credit for the team's work or being so modest that your contribution is unclear.

Bad: "We built a recommender system for the platform." (What did you do?)
Bad: "I built a recommender system for the platform." (If it was a team project, this is misleading.)
Good: "I was responsible for the feature engineering pipeline and the offline evaluation framework. The model architecture was designed by a colleague; I was the one who defined what 'relevant recommendation' meant as a training label and built the tools to measure it."

Be prepared to answer: "What would have happened differently if you had not been on this project?" This forces a specific claim about your contribution.

For solo projects: The advantage is full ownership. The challenge is that solo projects often lack the scale and complexity of team projects. Compensate by being thorough on the decisions you made and the things you had to figure out on your own.

Questions Interviewers Ask After a Project Walkthrough — and How to Prepare¶

"Why did you choose [model/approach X] over [alternative Y]?" You should have an answer for every major technical decision. "Because that's what I knew how to do" is honest but weak. "Because I considered Y and X was better for this reason" is strong.

"How did you evaluate whether the model was any good?" Know your evaluation strategy — offline metric, how it was computed, what the baseline was. Know whether you had an online test. Know the limitations of your evaluation approach.

"What would you do differently if you started over?" This is your self-awareness question. Answer it concisely and honestly. One or two specific things you'd change, and why.

"How is this model performing in production?" If the model is live, know the monitoring setup, the most recent performance numbers, and any degradation issues. If the model is not live (student project, prototype), know why not.

"How would you scale this to 10× the data?" This tests whether you understand the operational context, not just the modelling. Know the bottlenecks in your approach — whether it's data loading, training time, inference latency, or something else.

"How confident are you in the results?" Be honest about uncertainty. What could invalidate the result? Data leakage? Insufficient sample size? Short experiment window? Showing that you know the limitations of your own work is a sign of maturity.

Pre-Interview Project Review Checklist¶

Before any interview, review every project on your resume with these questions:

[ ] What was the business problem and why did it matter?
[ ] What data did I use, and what were its biggest limitations?
[ ] What were the two or three most important decisions I made, and what were the alternatives I considered?
[ ] What were the exact results, in both ML metric terms and business impact terms?
[ ] What went wrong or didn't work as expected?
[ ] What would I do differently with what I know now?
[ ] What specific contribution did I make if this was a team project?
[ ] Is this model in production? If yes, how is it monitored? If no, why not?

← Previous: Telling Your Story | → Next: Conflict & Collaboration