Product Design & UX · Chapter 5 of 5
The design loop and the portfolio
The portfolio review decides it, and it is judged on reasoning rather than on visuals.
| Round | What it tests | Prepare |
|---|---|---|
| Recruiter | Level and fit | A one-line description of the kind of problem you like |
| Portfolio review | Reasoning, not craft | Two or three cases, each with the constraint and the trade-off |
| Design exercise | How you work under ambiguity | Practise talking while designing |
| Cross-functional | Whether engineering and product will enjoy working with you | A disagreement with an engineer, resolved well |
| Behavioural | Feedback, iteration, failure | A design that shipped and did not work |
What a strong portfolio case contains
- The problem and who had it, before any screens.
- The constraint — technical, legal, timeline. Design without constraints is decoration, and interviewers are listening for it.
- What you rejected and why. The alternatives you did not ship are where the reasoning is visible.
- What happened after it shipped, including if it did not work. Metrics are named in 41% of postings for a reason.
- What you would do differently, specifically.
The most common portfolio failure
A beautiful case study that never states the problem, never names a constraint, and never says what happened afterwards. It demonstrates craft and leaves the interviewer unable to assess judgement — which is the thing they are hiring for.
Three cases with reasoning beat ten with visuals, every time.
What each round is testing
| Round | The question behind it | What fails it |
|---|---|---|
| Portfolio review | Can you explain why, not just show what? | Showing final screens. Interviewers want the constraint, the alternatives, and what you cut |
| App critique | Can you evaluate work that is not yours, generously and specifically? | Aesthetic opinions. 'I'd make it cleaner' is not a critique |
| Whiteboard / design exercise | How do you think when you have no time to polish? | Jumping to a screen. The first five minutes should be questions |
| Cross-functional | Can engineering and product work with you? | Treating feasibility as someone else's problem |
| Behavioural | What happens when your design is overruled? | Having no example. It happens to everyone, and having none suggests you were not in the room |
The portfolio mistake almost everyone makes
Candidates present outcomes. Interviewers are listening for decisions.
A beautiful final screen tells the interviewer that you or someone near you can produce a beautiful final screen. It says nothing about whether you can be trusted with an ambiguous problem, which is what they are hiring for.
The structure that works, per project: what the problem was and how you knew; what constrained you — technical, legal, timeline, existing patterns; what you tried that did not work; what you shipped; and what you learned afterwards that would change it.
The third item is the one that separates candidates, and almost nobody includes it. A portfolio in which every decision was correct first time reads as a portfolio that has been tidied, and interviewers discount it accordingly.
And be precise about your own contribution. Team projects are fine and expected; ambiguity about who did what is not, and it is the single most common reason a reference-checked portfolio falls apart later.
One more: bring something that shipped and was measured, if you have it. ‘This reduced support tickets about X by a third’ does more for you than any amount of visual craft, because it is evidence the design worked rather than that it looked right.
Check yourself