Nobody in that room is going to read your portfolio while you talk. They can't. Reading and listening use the same bit of the brain, and if your walkthrough is just a spoken caption track for pages they're already looking at, you've given them two versions of the same information and neither one lands. That's the flat feeling. Not nerves, not rambling — redundancy.
The fix is to treat the interview as a separate artefact from the document. The PDF is the evidence. The talk is the argument. Same projects, different job.
Ask how long you've got. If nobody tells you, assume ten minutes of talking and build for that, because a portfolio walkthrough that runs long is the fastest way to lose a room and the panel will almost never stop you — they'll just stop listening and start flicking ahead.
Three projects. Not five, not your whole book.
The flagship. Four or five minutes. This is the project that does the heavy lifting, and it should be the one closest to what the studio actually builds. If they do multi-unit residential, your housing scheme leads, even if your museum is prettier.
The counterweight. Three minutes. Different scale, different problem, different skill. It exists to prove you aren't a one-trick portfolio.
The evidence project. Two minutes, sometimes ninety seconds. The one with the section details, the site work, the thing you actually built or made. It doesn't need a concept narrative. It needs you to say "and this is where I was doing technical work" and then stop talking.
Within each project, the shape we teach for the page sequence works just as well spoken: brief and context, the idea, how the idea got tested, how it resolved technically, what came out of it. Five beats. The trap is spending four of your five minutes on beats one and two, because concept is the bit you're most rehearsed on from crits. Practice interviews are not crits. Concept is a minute. The testing and the resolving is where they're deciding whether to hire you.
The pacing test that actually works: go through your own PDF and mark every page as either a talk page or a flip page. A talk page gets sixty to ninety seconds of you. A flip page gets a sentence, maybe none, and you move. In practice most graduate portfolios have about six real talk pages in them. The rest are support. If you can't decide which is which, your layout has a hierarchy problem, which is a different fixable thing entirely.
The Projects You Deliberately Leave Out
There are three kinds of project that should be in your PDF but not in your ten minutes, and one kind that shouldn't be in either.
Leave out the one you can't defend. Every graduate has a beautiful project built on a decision they made because a tutor liked it. It photographs well, it renders well, and the moment someone asks why the cores are where they are, you're improvising. If you'd rather not be asked, don't lead with it.
Leave out the one where your contribution was decorative. If the honest answer to "what did you do on this" is "the renders and the diagrams", that's a perfectly respectable answer — but it's a supporting answer, not a lead one. Put it in the book, mention it in a sentence, let them ask.
Leave out duplicates. Two housing schemes means one of them is redundant airtime. Pick the better one.
And the one that shouldn't be in either: work you can no longer explain. If you can't remember the reasoning, it's not yours any more.
This is really a selection problem, and it's the same problem as building the portfolio in the first place — we teach project choice as ordering by strength first, then by relevance to the studio profile, with the off-brief project deliberately taking a back seat. If you did that job properly when you built the document, your three interview projects are already sitting at the front of it. If you didn't, the interview will expose it, because you'll be leafing forwards and backwards looking for the good bits while talking.
"Which Bits Are Yours?"
This is the question that catches out more graduates than anything else, and it's specific to our field. Nobody asks a copywriter which sentences they personally wrote. Architecture is collaborative, portfolios are visual, and a good render hides six pairs of hands.
The failure modes are symmetrical. Overclaim and you get caught the moment someone drills one layer down. Undersell — "oh, it was a group project, I just did some of the..." — and you've told a room full of people who hire for ability that you contributed nothing worth naming.
What we teach people to prepare is three things per collaborative project, said in one breath:
Scope. Verb. Artefact.
"Team of four. I led the section strategy and modelled the whole envelope. The bay detail on the next page is mine end to end; the master plan drawings were Anna's."
That's it. Team size gives them the calibration. The verb tells them what you did rather than what you were near. The artefact points at something on the page they can look at and test. And naming the bit that isn't yours is what makes the rest of it credible — volunteer one boundary and you'll almost never be pushed on the others.
The same applies to software authorship, which people get oddly cagey about. If a teammate built the Rhino model and you did the Illustrator drawings on top, say that. If you rendered someone else's model, say that. Nobody thinks less of you for it. They think less of you for the two-second pause before you answer.
One thing worth preparing that almost nobody does: the seam. Know exactly where your work met someone else's and what you had to negotiate at that join. "I was doing the envelope, so I had to work to the grid Tom had set, which meant the corner never quite resolved — here's how we fudged it." That answer is better than a clean claim of sole authorship, because it's what working in a practice actually sounds like.
The Technical Question Hiding Inside the Design Question
When a panel asks "why timber?", they are rarely asking about material poetics. They're asking whether you know what timber costs you — spans, fire strategy, moisture, tolerance, the fact that your 400mm-deep zone might not be a 400mm-deep zone once you've run services through it.
So answer in two layers. First the design reason, in one sentence. Then, unprompted, the consequence: "which pushed the spans down to about four metres, so the plan had to work in bays." You've now answered the question they actually asked and you look like someone who thinks in consequences.
When they interrupt to drill into something you genuinely didn't resolve — the structural transfer, the fire escape distances, the U-values — there is one good answer and several bad ones. The bad ones are guessing a number, waffling, and apologising at length.
The good one has three parts: what you know, where your knowledge stops, what you'd do about it. "Honestly, the transfer structure was indicative — we had a rough sizing from a structures tutorial but I didn't verify it. If I were resolving it now I'd start by testing whether the column grid above could be pulled back to align, because that's cheaper than a transfer."
Never invent a figure under pressure. If you say a U-value out loud in an interview, somebody in that room knows whether it's plausible, and the whole walkthrough gets re-audited in their head from that moment on.
Same structure works for "would you change anything?", which is a question about self-criticism, not about the building. Have one real answer ready per project, and make it a spatial or technical criticism rather than a graphic one. "I'd redo the render lighting" tells them nothing. "I'd give up the double-height space, because it cost me the circulation and I don't think it earned it" tells them you can prioritise.
And unbuilt or abandoned work: describe what stopped it in one factual clause, then keep moving. "The site got sold" is not a failure. Lingering on it turns it into one.
Let Them Drive, But Know the Route
Here is the honest tension. You've planned ten minutes and they will interrupt at minute two. Let them. A panel that interrupts is a panel that's engaged; the silent, polite one is the one going badly.
The skill is re-entry. Answer the question, then hand the wheel back with a bridge: "— and that actually feeds into how the section works, which is the next page." You've answered and resumed without saying "anyway, as I was saying".
Read the cues. If someone flips two pages ahead while you're talking, they've found something more interesting than what's in your mouth. Go where they went. If someone asks about the technical drawings early, abandon the concept narrative entirely — they've told you what they're hiring for.
Screen-Share Versus a Book on the Table
These are two different performances and most people prepare for one and get the other.
On screen, you're driving and they can't flip. That means every page transition is yours to make, and silence during a scroll is much longer online than it feels in the room. Share a PDF in full-screen page view, never the InDesign file, never a browser with your tabs showing. Have the file open before the call starts. Use the arrow keys, not the scroll wheel — smooth scrolling on a shared screen looks like seasickness. And say the page number out loud occasionally, because they may be looking at a PDF you emailed rather than your share, and the two drift apart within about a minute.
On the table, you've lost control of the sequence and gained everything else. They will turn pages, go backwards, and land on page thirty while you're on page eight. Build for that: your book should be legible in any order, which means captions on every drawing and a project title visible on every spread. Bring two copies so nobody is craning. Put the book down facing them, not you — you should be able to talk through it upside down, which is worth actually practising once, because it forces you to know the pages rather than read them. And never hand over your only copy at the start; you've just made yourself the person narrating a book they can't see.
Different Rooms, Different Scrutiny
A practice interview is testing employability. They want to know what you can do on Monday, so authorship questions are really skill questions in disguise.
A postgraduate or Part 2 interview is testing intellectual position. Group authorship matters less; they want to see that the projects in your book belong to one head with a consistent way of thinking, and they will ask you to connect them.
Part 3 is a different animal. It's an examination of your professional experience, and the authorship scrutiny is the whole point — what you did, under what supervision, and what you'd advise now. The portfolio walkthrough habits of "we designed" and "the team decided" that pass comfortably at graduate level are exactly what gets probed there. Worth getting out of them early.
The Thing Worth Rehearsing
Not the script. The first sentence of each project and the last one.
If you can open cold with "this is a forty-unit housing scheme on a tight urban site, and the whole thing is an argument about how to get daylight into a north-facing terrace" — you've set up everything that follows and bought yourself four minutes of attention. If you can close with "and what I'd take from it into work here is the section detailing" — you've made the point they were going to have to make for you.
The middle will take care of itself. It's your work. You know it better than anyone in the room.
