Portfolio Artifacts and Verification

A portfolio holds artifacts that a reviewer can examine, not restated resume bullets.

Programming

The Copied Resume Trap

Many people preparing a portfolio start from the resume they already have. They copy its bullet points, add a few links, and call the result a portfolio. This feels efficient, and it is the most common way a portfolio goes wrong. A portfolio is built from a different kind of material than a resume, so knowing what to leave out matters as much as knowing what to include.

What do you think happens?

Suppose a candidate builds a portfolio that contains only the bullet points from their resume, each one restated with a link beside it. Would a hiring manager reviewing this portfolio learn anything that the resume did not already say?

Reveal answer

Answer:

No. The portfolio repeats the resume's claims, and the links only point to the same summaries, so the reviewer learns nothing new.

The source's point is that a portfolio holds artifacts a reviewer can examine, not restated bullets. Adding links to the same claims does not change what the reviewer can check.

Bullets Assert, Artifacts Demonstrate

The distinction the source draws is between a bullet and an artifact. A bullet is a short summary, written by you, about something you did. An artifact is the thing itself: the work a reviewer can open, run, and judge for themselves. The source treats the artifact as the element that sets you apart, because it lets the reviewer check the claim instead of trusting it.

A simple way to hold the difference is this: bullets assert and artifacts demonstrate. A bullet that says you built a task tracker asks the reviewer to take your word for it. A working task tracker that the reviewer can start on their own machine lets them see the result directly. Bullets remain valuable on a resume, which is why they belong there. They are excluded from a portfolio because a portfolio's job is to offer evidence.

How does a resume bullet differ from a portfolio artifact in what a reviewer can actually examine? The bullet is a summary the reviewer can only read, while the artifact is the work the reviewer can open and run.

Three Criteria for Strong Items

Before including an item, the source asks two questions: could a reviewer verify it independently, and did you build it? Those questions, together with the requirement that the work runs, form three criteria for classifying a portfolio item as strong or weak. A strong item meets all three. A weak item fails at least one of them. The three criteria are closely connected, as the diagram below shows.

How do the three criteria relate to each other and to a single portfolio item's classification? Each criterion must hold for the item to count as strong.

Tracing an Untested Prototype

Here is a candidate traced step by step through the checks. The candidate is a small note-taking app. Its code was written, but the README has never been tested on a fresh copy of the project.

Worked example

A note-taking app with an untested setup

Decide whether the note-taking app belongs in the portfolio, using the runnable, verification, and original building criteria.

1
Check original building
You wrote the app yourself, so this criterion passes.
2
Follow the runbook from a fresh copy
The install step fails on the first command because a dependency file was never added. The runbook cannot take a stranger to a working result, so the runnable criterion fails.
3
Check verification
A reviewer who clones the project would hit the same error on the first step and move on. The reviewer cannot verify the work, so this criterion fails as well.
4
Make the decision
The app is excluded for now. Its visible failure says something negative about the candidate, which the source describes as worse than an empty space. It can return once the dependency is fixed and the runbook passes on a fresh copy.

Result

Excluded until the runbook works from a fresh copy. Passing the original building check alone does not make the item strong.

Why Generic Demos and Talk Write-Ups Fail

The source names three categories that tend to slip into portfolios by mistake, and the first one has already been covered: restated resume bullets. The untested prototype is the second. The generic demo and the long write-up of conference talks are the other two.

Common mistake
Treating a generic demo as proof of skill
What it looks like
Including a standard chatbot demo that follows a popular tutorial with no changes.
Why it fails
The source notes that the hiring manager has seen ten thousand of these. A demo that looks like thousands of others, with no distinguishing decision behind it, is unlikely to be remembered.
Do this instead
Include work that reflects a decision of your own, even a small one, so that the reviewer has a reason to remember it.
Common mistake
Listing conference talks you attended as portfolio material
What it looks like
Writing a long summary of talks you watched, presented as your work.
Why it fails
The source says attending is not credentialing. The write-up shows exposure to a topic, not the ability to do what the talk described.
Do this instead
Build a working example of the idea yourself, then show that example.
Common mistake
Assuming an untested repo still helps
What it looks like
Keeping a project whose setup steps have never been run on a clean machine.
Why it fails
The source states that a repo whose code does not run is worse than no repo, because a broken first step tells the reviewer the work was never checked.
Do this instead
Write a runbook and follow it on a fresh copy before including the item.

Sorting Candidate Items

The decision for any candidate follows a fixed path. Each check asks one question, and a failed check sends the item to the exclude branch. An item reaches the keep branch only after it passes every check. The flowchart below shows the path that combines the source's criteria with the reasons for exclusion.

For a candidate item, which checks does it pass or fail, and which branch does that send it down to keep or exclude? Each failed check routes the item to an exclude outcome with a stated reason.

The last check, a distinguishing decision, is drawn from the source's reasoning about generic demos rather than from a checklist item the source states directly. The source explains that a demo with no distinguishing decision behind it is unlikely to be remembered, so the check follows from that explanation.

Practice: Sort the Candidates

MEDIUM

Using the flowchart, decide keep or exclude for each candidate and write one reason per candidate. The candidates are: (A) a list of resume bullets, each restated with a link; (B) a long summary of conference talks you attended; (C) a standard chatbot demo copied from a tutorial with no changes; (D) a small calculator you built, with a runbook you tested on a fresh clone; (E) a prototype whose main feature has never been run, with no runbook.

Hints

Start each candidate at the first check. Ask whether a reviewer can open and run it, not whether it looks polished.
For candidate C, ask whether anything in the demo reflects a decision of your own.
For candidate E, consider what the reviewer would see if they tried the first step.

Your attempt (not saved)

Key Takeaways

A portfolio holds artifacts a reviewer can examine, not restated resume bullets. Bullets assert a claim; artifacts let the reviewer check it.
Strong portfolio items meet three criteria: runnable work, verification by a reviewer, and original building from concepts you have learned.
An untested prototype is worse than no repo, because a broken first step signals that the work was never checked. A runbook that works from a fresh copy is the test of readiness.
Generic demos and write-ups of talks you attended do not differentiate you, because familiar demos are easily forgotten and attendance is not credentialing.
Before including an item, ask whether a reviewer could verify it independently and whether you built it.