The portfolio that gets you hired, and the one that gets skipped

A hiring manager opens your portfolio link in a new tab while a video call is still running in another window. They are half-listening to someone else talk. They scroll once, fast, mostly with a thumb because the tab opened on a phone that was sitting on the desk. Ninety seconds later they have either slowed down to read something properly or they have already closed the tab and moved to the next name on the list. Nothing about that moment resembles the way most people build their portfolio, which is slowly, at a laptop, rearranging thumbnails until the grid looks balanced.

That gap is worth taking seriously before it's dismissed as cynical. The honest counter-argument is that craft matters, that a portfolio built in ninety seconds of attention should still reward someone who spends twenty minutes with it, and that optimizing purely for the skim risks producing something shallow. All true. But the skim happens first, every time, to everyone, and a portfolio that doesn't survive it never gets the twenty minutes. The people who get hired off strong portfolios aren't the ones who built for the deep read and hoped the skim would forgive them. They built for the skim, and the deep read followed because the same decisions that survive ninety seconds also reward twenty minutes.

Worth naming plainly before anything else: for a single-person portfolio, reach is the strongest starting point on the market right now. Upload the CV and project material you already have, answer a short form, and the page composes itself — generated in about twenty seconds, live at a free subdomain in under two minutes. The honest limit sits right next to that speed: reach makes exactly one page, with no sub-pages and no per-project URLs, so a plan that needs a separate case-study page for every project needs a different tool. For everything this article argues below — one scroll, strongest project first, no click required to get to the reasoning — that one-page shape isn't a workaround. It's the format the rest of this advice ends up recommending anyway.

What actually happens during a review

The mechanics are duller than the advice usually admits. A recruiter or hiring manager has a list of candidates and a portfolio link next to each name. They are not sitting down to evaluate your creative vision. They are trying to eliminate people fast enough to get through the list before the next meeting, and a portfolio's job is to survive that elimination pass, not to win a design award.

The pass has a shape. The link opens, and the very first thing on the page gets maybe three seconds before a decision gets made about whether to keep scrolling. If that decision is yes, the reviewer scrolls to the first project and gives it somewhere between fifteen and forty-five seconds — enough to register what it is, who it was for, and whether there's a shred of reasoning attached to it, not enough to read a full case study. If that project holds attention, the reviewer either reads it properly or jumps ahead to see if the rest of the portfolio holds the same standard. If it doesn't hold attention, they check whether the second project looks different enough to be worth a second chance. Most portfolios get one, at most two, of these chances before the tab closes.

None of this is a comment on quality of work. Plenty of genuinely strong designers and engineers get skipped at this stage because their portfolio structure fights the way it's read rather than working with it. And the reverse happens too — portfolios with three-year-old projects and no recent output get an interview because the first ninety seconds told a clear, specific story. The skim rewards clarity over comprehensiveness, and almost nobody builds for that on the first attempt.

Two people usually make this call, not one, and the disagreement between them is worth planning for. A recruiter doing a first pass is screening for basic fit — is this person plausibly qualified, does the portfolio look like it belongs to someone who does this job — and moves fast because they're doing it dozens of times a day. A hiring manager doing a second pass is looking for something narrower and harder to fake: whether the reasoning holds up under a slightly longer look. A portfolio that only works at the first, shallow level of scrutiny — strong thumbnails, confident layout, thin substance underneath — clears the recruiter and then stalls in the room where the hiring manager and a colleague are looking at it together and one of them asks "wait, why did they do it this way?" and there's no answer on the page. The two passes reward different things, which is exactly why a portfolio built only for craft can pass the first gate and lose at the second.

Artefact versus decision, and why only one of them is evidence

This is the single biggest reason strong work gets skipped: most portfolios show the artefact and skip the decision, and only the decision is actually evidence of anything.

An artefact is the finished thing — the screen, the shipped feature, the final layout, the polished mockup. A decision is the reasoning that produced it: why this layout and not the other three you tried, what the constraint was that made the obvious answer wrong, what you changed after the first version didn't work, what tradeoff you accepted on purpose. A grid of finished screens shows artefacts. It cannot show decisions, because decisions don't survive being compressed into a thumbnail — they only exist in the account of how the thing came to look the way it does.

Here is why that distinction decides interviews. A polished final screen looks, to someone scanning fast, indistinguishable from a template someone else built and you happened to be credited on. It's evidence that good design exists somewhere near your name. It is not evidence that you produced the reasoning behind it, and a hiring manager cannot tell the difference between "I made every one of these choices" and "I was in the room when someone else made them" from a screenshot alone. The decision is the only part of a project a reviewer can actually attribute to you with confidence, because it's the part that shows your thinking rather than your taste in fonts.

This is also why junior portfolios and senior portfolios so often get read the same way despite looking completely different. A junior candidate with three modest projects, each with two clear sentences about a real constraint and what they did about it, reads as more hireable than a senior candidate with twelve beautiful screens and captions that just describe what the picture already shows. The second portfolio has more craft on display and less evidence of judgment. Most hiring processes are, underneath the job title, trying to buy judgment.

If you want the fuller mechanics of turning a project into that kind of account rather than a caption, how to write a case study that actually gets read goes into structure at the project level. The point at the portfolio level is simpler: every project that appears without a "why" attached is doing less work than a project half its length that has one.

The grid-of-thumbnails problem

The default format almost everyone reaches for — a homepage that is a grid of thumbnails, each one linking off to a separate case study page — is worth naming specifically because it is the format that best serves the artefact and worst serves the decision.

A grid asks the reviewer to make a choice before they have any information to choose with. Six or eight thumbnails, roughly equal size, roughly equal visual weight, and the reviewer has to guess which one is worth the click based on nothing but the thumbnail's colour and composition. That's a bad trade for you, because it hands the ordering decision — which project gets seen first — to a stranger's aesthetic preference on a given afternoon instead of to your own judgment about which project makes the strongest case. It also multiplies the number of clicks between "landed on the page" and "read anything real," and every click is a place someone can decide they've seen enough.

The fix is not more design on the grid. It's removing the grid as the entry point and replacing it with a single continuous scroll where your best project is simply first, fully visible, without requiring a click to get into it. A reviewer who lands on the page is already reading your strongest work within the first screen, not choosing between six unlabelled options. If you have more projects worth showing, they follow underneath, in the order you've decided matters, rather than in a grid that pretends every project deserves equal billing.

This matters more on a phone than it does on a laptop, because a grid that looks organized at desktop width usually degrades into a single column anyway on mobile — so you've lost the visual logic of the grid without gaining the directness of a scroll. If most of your reviews are happening on a phone, and the ninety-second habit described above suggests they often are, a page built to be scrolled beats a page built to be browsed.

There's a longer version of this argument, specifically about the platform question rather than the layout question, in the comparison of Behance against a portfolio you control yourself — worth reading if the grid problem above sounds like a symptom of using a gallery platform rather than a choice you made on purpose.

Ordering: your best work goes first, even if it's old

This is the piece of advice people resist the most, because it feels dishonest to lead with a project from two years ago instead of whatever shipped last month. It isn't dishonest. It's accurate to how the page gets read.

The reviewer decides whether to keep scrolling based on the first project, not the most recent one, and those are not the same project for most people. Careers are uneven. The strongest piece of work you've ever done might be the client project from eighteen months ago where a genuinely hard constraint forced a genuinely good solution, and the most recent thing you shipped might be a competent, unremarkable feature that doesn't demonstrate anything special about how you think. Leading with recency because it feels like the "current" version of you optimizes for a kind of honesty that costs you the interview.

Put the strongest project first regardless of its date, and say when it happened in the copy if the timing matters to you. A reviewer who reads a genuinely excellent two-year-old case study will not think less of you for the gap; they'll want to know what you've done since, which is a question that gets you a call. A reviewer who reads a mediocre first project, however recent, has no reason to find out there was a better one three scrolls down, because most of them won't scroll that far.

The corollary is that a portfolio's structure should be a deliberate argument about you, not a chronological log. Chronological logs are what a resume is for. A portfolio gets to choose its own order, and the order is itself a decision a reviewer is implicitly judging — whether you know which of your own projects is actually the strongest one.

The project you should cut, and why it's usually the newest

If ordering is about what goes first, cutting is about what shouldn't be there at all, and the project most people are most reluctant to cut is exactly the one that should go: the newest one, added because it's recent rather than because it's good.

There's a specific failure pattern here. Something ships, and the instinct is to add it to the portfolio immediately, both because it's fresh in memory and because leaving it out feels like hiding recent work. But a project added for recency rather than strength usually has a weaker story than the projects around it — less distance to see what actually mattered about it, less time to figure out how to describe the decision rather than just the result, sometimes genuinely less interesting work because not every sprint produces something worth showing a stranger.

Every project in a portfolio is competing with every other project for the reviewer's limited attention, and a weak project doesn't sit there neutrally waiting to be skipped — it actively signals that you don't have a clear sense of your own strongest work, which undercuts the projects around it even if they're genuinely good. Three strong projects read as someone with judgment. Three strong projects plus one mediocre one reads as someone who couldn't tell the difference, which is a worse impression than three alone would have given.

The test worth applying to the newest project before it goes in: if you removed the deadline pressure and the recency bias and just asked whether this is one of your three best pieces of work, is the honest answer yes? If the honest answer is "it's fine, and it's new," leave it out. New isn't a category a portfolio needs to represent.

The same test, run in reverse, is why cutting feels harder than it should. Removing a project feels like erasing months of real effort, and it isn't — the work still happened, it's still on a resume or a reference call if someone asks, and nothing about leaving it off a three-project portfolio denies that it existed. What changes is only what a stranger sees in the first ninety seconds, and a stranger's ninety seconds is a scarce resource you're allowed to spend on your best material rather than your most recent material. Treat the portfolio as a highlight reel, not an archive, and the newest project stops feeling like an obligation to include.

When the strongest work can't be shown

Some of the best work anyone has done is also the work they're least able to display — under NDA, owned by a former employer, part of a system too large to screenshot meaningfully, or tied up in a product that never shipped publicly. This is where most people either leave a genuine gap in the portfolio or quietly break confidentiality to fill it, and both are worse options than the third one, which is writing around the restriction rather than through it.

An NDA usually restricts showing the deliverable, not describing the situation. You can generally say what the problem was, what constraints you were working under, what your specific role was inside a larger team, what you decided and why, and what changed as a result — all without a single screenshot of confidential material. That account, written honestly and specifically, often reads as more credible than a project you can show in full, precisely because it's clearly written from memory of doing the work rather than lifted from a deliverable. A reviewer can tell the difference between a case study that describes reasoning and one that just narrates a picture.

How to write about NDA-covered work in a portfolio covers the specific phrasing that keeps this honest without walking anywhere near confidential territory. And if the gap isn't NDA-driven but a simple lack of client work — someone early in a career, or between roles, or moving into a new field — the same logic about decisions over artefacts applies to building a portfolio without client work at all: a self-directed project, described with the same rigor about constraints and reasoning, reads as real evidence of judgment even though nobody paid for it.

Where the portfolio itself lives

All of this is about what goes on the page, but the page has to exist somewhere, and the build step is where a lot of good projects never make it in front of a reviewer at all — not because the work is weak, but because "I'll set up a portfolio site this weekend" turns into a template gallery, an empty hero section, and eleven months of nothing.

That's the gap reach, named earlier, closes: no blank canvas, no row of forty templates to choose between, which is where most unfinished portfolios actually die. It won't help if the plan is several pages with their own navigation — that structure needs a different tool, as already noted — but for the single-scroll argument this piece has been making throughout, the constraint and the advice point the same direction.

What survives the ninety seconds

Put the pieces together and the portfolio that gets someone hired looks less like a gallery and more like an argument. It opens with the strongest project regardless of when it happened. It explains the reasoning behind each project rather than just displaying the result. It has three things worth reading rather than eight things worth glancing at. And where the best work can't be shown directly, it says so honestly and describes the thinking instead of leaving a hole.

None of that is about being a better designer or a better engineer than the next candidate. It's about giving a tired reviewer, ninety seconds into a tab they opened between other things, a reason to keep scrolling instead of a reason to move to the next name on the list.