Portfolio playbook
Interview Prep field notes
Build a data portfolio that recruiters can understand in 90 seconds
Turn project work into clear evidence by showing the problem, your decisions, the output and what changed because of it.
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.
Design for the first 90 seconds
A reviewer should be able to answer four questions quickly: What problem did you solve? Why did it matter? What did you personally do? What did the result make possible? If those answers are buried, the project will feel weaker than the work behind it.
Open with a short case summary, not a long technical introduction. State the user or business, the decision they faced and the outcome your work supports.
Use the top of the page as a compact evidence summary: one sentence for the problem, one for your contribution and one for the result. Add a clear path to the live output, repository or deeper case study so each reviewer can choose the level of detail they need.
Use a repeatable case-study structure
Consistency makes a portfolio easier to scan and makes you easier to interview. Use the same narrative structure across projects so the reviewer can focus on your reasoning.
- Context: the situation and why it matters.
- Question: the specific decision or outcome you investigated.
- Approach: the important choices, not every command you ran.
- Result: the insight, model or product you produced.
- Reflection: limitations, trade-offs and the next experiment.
Keep this in mind
Tools belong inside the story. A list of Python, SQL and Power BI does not explain how you think.
Show the decisions only you could explain
Public datasets are not a problem. Generic execution is. Explain why you selected a metric, removed a field, chose a baseline or changed the visual hierarchy. Those choices demonstrate judgement and give an interviewer something meaningful to ask about.
Include one or two artefacts that carry the argument: a readable chart, a model comparison, a system diagram or a concise dashboard. Every visual should answer a question.
- Name one assumption that shaped the analysis and how you checked it.
- Explain one alternative you considered and why you rejected it.
- Show one limitation that changes how the result should be used.
Make your evidence easy to verify
A reviewer should not have to trust a claim they cannot inspect. Link each important conclusion to the artefact that supports it: a query, chart, model result, dashboard view or short methodology note. Keep the main story readable, then place technical depth one click away.
Be precise about impact. If a project was not used by a real team, describe the decision it could support instead of inventing revenue, time savings or adoption numbers. Honest evidence is more credible than an impressive estimate with no basis.
- Separate observed results from expected business implications.
- Label simulated, public or synthetic data clearly.
- Include enough setup information for a reviewer to reproduce the main result.
Finish the project like a professional handoff
Check links, write a useful README, make the first screen understandable and remove dead experiments. Then ask someone unfamiliar with the project to explain it back to you after a minute of reading.
If they cannot identify the problem or your contribution, revise the story before adding another project. Clarity compounds; volume does not.
06 · Practice lab
45 minutesRewrite one project as a recruiter-ready case
Take an existing notebook, dashboard or class assignment and rebuild only its first screen or README.
- 1
Write a two-sentence opening that names the user, decision and why the problem matters.
- 2
Select three decisions you made and explain why each choice was reasonable.
- 3
Choose one visual that carries the main insight and give it a conclusion-led title.
- 4
Ask someone to scan the page for 90 seconds and tell you the problem, your contribution and the result.
Your finished output
A concise case-study opening that a reviewer can understand before opening your code or dashboard.