A portfolio interview should explain the problem, your contribution, the decisions you made and what you can verify about the result. Select a few relevant examples and guide the interviewer through them. A large collection of attractive screenshots is less useful if your role and reasoning remain unclear.
Use only work you are permitted to share. Label practice projects, collaborative work and AI assistance accurately. The suggestions below apply across design, writing, analysis and technical portfolios, but the vacancy’s requested format takes priority.
1. Choose work that answers the vacancy
Match each sample to a responsibility in the job description. A writing role may need evidence of adapting to a brief; an analyst role may need a checked calculation and explanation. Select for relevance rather than simply choosing your most elaborate project.
Prepare a short reason for including each piece. If a sample demonstrates an adjacent skill, explain the connection without claiming it proves experience you do not have. Keep a backup example available, but do not insist on showing everything.
2. Introduce the audience and problem
Start with who the work was for and what it was meant to achieve. For a fictional project, say so immediately. Explain the constraints that shaped the work, such as the supplied dataset, intended reader or available time.
Avoid inventing a client to make a practice exercise sound more credible. A clearly described self-directed project can still show judgement. The interviewer needs enough context to understand your choices, not a lengthy story about every event that preceded the work.
3. Identify your contribution precisely
Distinguish what you created from what teammates, templates, libraries or other tools supplied. If you revised an existing asset, explain the starting point and the changes you made. Give others appropriate credit.
Hypothetical wording: “The dataset was provided for the course. I wrote the cleaning checks and summary; my teammate prepared the presentation.” That is stronger evidence than describing the entire team outcome as your individual achievement. Be ready for follow-up questions about the part you owned.
4. Show one important decision
Choose a decision that reveals how you think. Explain the options, the constraint and why you selected one approach. A before-and-after comparison can help if both versions are permitted to share and the change is meaningful.
For example, a fictional writing sample might replace an ambiguous instruction with an observable action. Explain why that matters to the reader. Do not rely only on preference words such as cleaner or better; connect the decision to the task the work needed to support.
5. Explain how you checked the work
Describe the review, test or reconciliation you actually performed. For analysis, that might be checking totals against source rows. For a guide, it might be asking someone to follow the steps. For design, it might be checking export dimensions and readability.
Do not imply formal user research or production testing if you only asked a friend for feedback. Name the limits of the check. An honest, small verification step is more informative than an impressive method you cannot explain.
6. Report the result without invented impact
Show the final output and any outcome you can substantiate. A finished practice project can demonstrate a skill without claiming increased revenue, conversions or customer satisfaction. If you have verified numerical results, explain the measure and your contribution.
Where impact was not measured, say what the work made possible or what you learned. Avoid converting a positive comment into a general performance statistic. Separate the result of the work from your hope about what it might achieve in a real organisation.
7. Invite a focused discussion
End the sample with a short reflection and pause for questions. You might explain what you would improve with more information or a different constraint. Keep the discussion open rather than rushing into the next item.
If asked to show confidential material, explain the boundary and offer a permitted alternative. If a file fails to load, describe the relevant decision using an approved backup. The goal is a clear conversation about your work, not a flawless technology performance.
A reusable walkthrough
Use this outline: audience and problem; constraints; my contribution; key decision; check performed; result and limitation. Practise it with one sample before adding more. Time yourself against the employer’s requested slot, leaving space for questions.
Hypothetical opening: “This is a self-directed documentation sample for a fictional booking tool. I wrote and tested the setup instructions. I will show the missing-prerequisite problem, the revision and how I checked the new sequence.”
Final checks
Confirm sharing permission, remove personal data, test the link or file and ensure the sample can be understood without your private notes. Keep the file name and version clear.
Can a practice project be enough to discuss?
It can provide useful evidence of a particular skill. Do not claim it is equivalent to every requirement of a commercial role.
Should I show unfinished work?
If relevant and permitted, explain its status and what remains unresolved.
For role-specific preparation, see graphic designer interview questions or technical writer interview questions.
