Interview prep
Interview Prep field notes
How to explain a data project in an interview without reciting it
Use a decision-first walkthrough that makes your contribution, judgement and learning easy for an interviewer to assess.
This is a working guide: use the prompts and checkpoints as you make the decision or build the project, not only after it is done.
Open with the decision, not the technology
Start by naming the user, the problem and why the outcome mattered. Then state your role. This gives the interviewer a map before you introduce data, tools or implementation details.
A strong opening sounds like a case brief: a team needed to improve a decision, you owned a specific part of the analysis or system, and your work produced a measurable or testable output.
Keep this opening to roughly thirty seconds. A useful pattern is: who faced the problem, what decision was difficult, what you owned and what outcome your work supported. Save the implementation detail for the questions that follow.
Use a five-part walkthrough
Keep the first version concise. The interviewer will ask for depth where it matters to the role. A clear structure prevents you from getting lost inside implementation details.
- Problem: the decision, user and constraint.
- Evidence: the data you had and the important quality issue.
- Choices: two or three decisions you personally made.
- Result: the output and how you evaluated it.
- Reflection: one limitation and what you would change next.
Make your contribution unmistakable
Team projects become vague when every sentence begins with 'we.' Give credit to the group, then define the boundary you owned: the analysis you designed, the pipeline you built, the metric you selected or the recommendation you delivered.
Use first-person language for your decisions and actions, and team language for shared context and outcomes. If you inherited part of the work, explain the starting point and what you changed. Clear ownership does not require claiming that you did everything.
- I owned this part and collaborated with these people on the rest.
- The starting approach was this; I changed it because of this evidence.
- My output enabled this decision, handoff or next experiment.
Prepare for the questions behind the questions
When asked why you chose a tool or metric, the interviewer is testing judgement. Explain the alternatives you considered and the constraint that made your choice reasonable.
When asked about a mistake, describe what signal exposed it, how you corrected it and what check you added afterwards. Honest debugging demonstrates ownership better than pretending the project was linear.
- Scope: What did you own, and what did others provide?
- Validation: How did you know the result was correct or useful?
- Trade-off: What alternative did you reject, and why?
- Next step: What would you test with more time or better data?
Keep this in mind
Do not memorise paragraphs. Memorise the structure, the key numbers and the reasoning behind your most important choices.
Practise at two levels of depth
Record a two-minute overview, then practise a ten-minute version with technical follow-ups. Remove unexplained jargon and make sure every number has context.
End with what the project taught you and how it changed your next piece of work. That final reflection signals that you can learn beyond a single assignment.
06 · Practice lab
30 minutesRecord a two-minute project walkthrough
Use one completed project and practise the version an interviewer is most likely to hear first.
- 1
Write five cue lines: problem, evidence, key choice, result and reflection. Do not write a full script.
- 2
Record the walkthrough once without stopping and note where you become vague or overly technical.
- 3
Record it again with one concrete number, one trade-off and one limitation.
- 4
Listen back and check whether your personal contribution is clear within the first minute.
Your finished output
A reusable two-minute answer plus a list of three follow-up questions you should be ready to explain in depth.