What does a portfolio project need to prove that a resume line cannot?

Kunle Adisa spent four years as a copy editor before moving into product work. His sample project is a triage tool built for the Colby Ledger, a small regional newsroom drowning in wire-service copy: it ranks incoming stories by how likely they are to matter to local readers. Astrid Lindqvist is a hiring manager at a different media company, and she reads roughly thirty resumes for every AI PM role she opens.

How to answer this, stage by stage

This question isn't asking you to list portfolio best practices. It's asking whether you understand why a hiring process built on unverifiable claims is broken, and what you'd personally do about it.

Let's learn

Say a hiring manager is holding two resumes side by side, both claiming the same kind of impact, in the same kind of words.

Before Kunle rebuilt his materials, his resume read: "Led editorial workflow improvements that increased newsroom efficiency." It was true, and it was also completely unverifiable to anyone reading it cold.

After the rebuild, the same underlying work became: a live triage tool Astrid could run three real wire stories through, a page naming the trade-off Kunle chose (flag more stories for review, rather than fewer, to avoid missing a real local angle), and a short log showing the two stories it ranked wrong in testing.

At its worst: a hiring manager makes a call based on a resume line that turns out, three months into the job, to have described a much smaller and much less impressive piece of work than it implied, and by then the cost of that gap has already landed on the whole team.

What I would leave alone: the resume line itself doesn't need to disappear. It's still what earns the first ten seconds of attention. It just can't be asked to do the whole job of proof by itself anymore.

The lesson: the gap between a resume and a portfolio was never about polish. It was about whether the person reading it has any way to catch you if you were wrong.

Now here is the same thing as a story

The short version above is what you'd say defending your own portfolio choices in an interview. Read this one for how Kunle actually found the fix.

For four years, Kunle could read a wire story's first paragraph and tell within seconds whether it had a local angle worth chasing, a skill nobody outside a newsroom ever quite believes until they've watched it happen.

His early job search ran on resume lines that were, if anything, understated: real work, real impact, described the only way he knew how, in the language every resume uses.

One side of this picture holds all the context. The other side holds a decision to make and no way to check it.

Nothing dramatic happened. He just kept getting to a phone screen, hearing polite interest, and then quietly hearing nothing back, application after application, for weeks.

The claim usually doesn't get tested until 90 days into the job. By then, for everyone involved, it's already too late to be cheap.

A mentor finally asked him a plain question after reading his resume: "if I couldn't talk to you, what could I actually go check?" There was nothing to point to.

Most resume lines cluster in the same bad corner: bold claims, nothing checkable behind them.

He spent three weekends building the triage tool from scratch, using public wire-service archives instead of anything from his old newsroom, so nothing about it depended on anyone's word but his own testable work.

Four parts, and the third one, a shown failure, is the one candidates almost always leave out.

The finished page let Astrid click through three real wire stories, read Kunle's one-paragraph explanation of why he chose to over-flag rather than under-flag, and see the two cases where the tool got the call wrong.

Most hiring funnels have a missing box right where a real check should sit. An inspectable artifact is what fills it.

Four things turn a claim from something you have to trust into something you're allowed to check.

The old resume asked Astrid to take Kunle's word for the size of his impact. The new portfolio hands her three real stories, one honest trade-off, and two visible mistakes, and asks her to decide for herself.

I wrote "improved editorial efficiency" because it was true, and because that's the only language I'd ever seen used to describe this kind of work. Hearing my mentor ask what he could actually go check is what showed me the problem was never the honesty of the claim. It was that nothing behind it could be checked at all.

GUARD, for the claim nobody can checkNot a policy problem. A design problem, sitting inside every unverifiable resume line.

The recap, one line per letter: groups is the hiring manager and the candidate, unequal is that candidates without pedigree signals suffer most, ability to contest is the hiring manager's total inability to check a claim cold, reduce is swapping the claim for an inspectable artifact, and detect is asking a candidate to defend one decision live.

And if you want to be sure it really works, try it somewhere elseSame five letters, a permit-review backlog instead of a newsroom. A different candidate, and this time the unequal harm lands on the applicants, not just the hiring process.

Meenal Sinha is building a portfolio project around a tool that triages municipal building-permit applications by completeness, for a mid-sized city planning office. Applied to GUARD: groups are the reviewing hiring panel and the residents whose permits get triaged. Unequal is that the same "no way to verify" problem that hits Meenal's resume line also hits an applicant's paperwork, since an incomplete-looking application from someone unfamiliar with the process gets flagged the same as a genuinely incomplete one. Ability to contest: the applicant flagged as incomplete often has no easy way to ask why, mirroring the hiring manager's own inability to question a bare resume claim. Reduce, for Meenal's portfolio: the artifact itself models the fix, showing the specific reason each application was flagged, not just a pass or fail. Detect: Meenal's write-up describes testing the tool against forty real historical applications and finding six where an unclear reason code would have caused a resident to resubmit needlessly.

The same shape of problem shows up again: bold, unverifiable flags cluster in the same bad corner, whether the subject is a resume or a permit application.

Swap the trigger and it still runs.
Speed: an interviewer wants your answer in one breath. Say "checkable versus trusted," and stop there.
Cost: you have no budget to build a polished demo. A rough one that still works and still shows a failure case beats a beautifully described claim with nothing behind it.
The hiring market gets better, for real: even if more candidates start building real artifacts, the underlying test doesn't change, a hiring manager should still be able to check any claim in minutes, not just trust that everyone's artifact is equally honest.

Where people run it wrong.
They build a portfolio that only shows success, with no failure case a reviewer can inspect.
They describe a trade-off in the abstract instead of naming the actual one they chose.
They assume a nicer-sounding resume line closes the gap that only an inspectable artifact can close.

How to use it live. When asked what a portfolio proves that a resume can't, answer with the one word this whole framework turns on: checkable. Then name one specific thing in your own portfolio a stranger could go check right now, without asking you anything.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0