Creating an Effective Portfolio
A portfolio holds artifacts that a reviewer can examine, not restated resume bullets.
Why Copying the Resume Fails
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
No. The restated bullets assert the same claims the resume already makes, and the links add no new evidence unless they lead to work the reviewer can examine.
A bullet is a short summary written by you about something you did. An artifact is the work itself, which a reviewer can open, run, and judge. Restating bullets with links adds presentation, not evidence.
Bullets Versus Artifacts
A portfolio holds artifacts that a reviewer can examine, not restated resume bullets.
The distinction 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 that a reviewer can open, run, and judge for themselves. The artifact is the element that sets you apart, because it lets the reviewer check the claim instead of trusting it. Bullets assert; artifacts demonstrate. That is why bullets are excluded from a portfolio, even though they remain valuable on a resume.
Three Tests for a Portfolio Item
Each candidate item can be classified using three criteria. The first is runnable work: the item must actually execute. The source is blunt on this point: a repo whose code does not run is worse than no repo. The second is verification: a reviewer must be able to check the item independently, without relying on your word. The source's guiding question is whether a reviewer could verify it independently. The third is original building: you must have built the item yourself, from concepts you have learned. The source contrasts building with attending, since attending a talk does not show that you can do what the talk described.
Tracing a Candidate Through the Tests
The source gives a sequence of questions to ask before including an item. Whether a reviewer could verify it independently comes first, followed by whether you built it. The runbook test then confirms the item actually works. Here is one candidate traced through the sequence.
A Chatbot Built From a Tutorial
A candidate has a chatbot project that closely follows a popular tutorial. It runs when the candidate launches it on their own machine. The candidate asks whether to include it.
- 1Step 1: Can a reviewer verify it independently?
The project is available to inspect, so a reviewer could look at it. This passes the verification question, though the source's point is that the reviewer needs independent verification, which depends on whether it can be reproduced from a fresh copy.
- 2Step 2: Did you build it?
The candidate mostly followed a tutorial with little change. The source asks whether the item reflects building from concepts you have learned. Copying a walkthrough without a distinguishing decision weakens this criterion.
- 3Step 3: Does it run from a fresh copy?
The project runs on the candidate's machine but has not been tested elsewhere. The runbook test asks whether someone else can follow written steps to a working result. No runbook exists yet, so the item is not ready.
- 4Step 4: Decide
Because the item is a familiar demo without a distinguishing decision, and it has no runbook, it is excluded for now. The candidate could keep it as a learning exercise, but it should not occupy a portfolio slot in its current form.
Exclude for now. The item fails the originality and runbook tests, even though it appears to run.
Why Untested Prototypes Hurt
An untested prototype is the second category the source tells you to exclude. A broken repo does two harmful things. It fails to show the skill it was meant to show, and it gives the reviewer a visible sign that the work was never checked. A reviewer who clones the project, hits an error on the first step, and moves on has learned something negative about the candidate. The source's conclusion is that this is worse than an empty space.
The source offers a practical test: the runbook. A runbook is a set of steps someone else can follow to run the project and confirm that it works. If you cannot write a runbook that reliably takes a stranger from a fresh copy to a working result, the artifact is not yet a portfolio item. Writing the runbook is part of verifying the work, not an afterthought added to the README.
Mistakes That Dilute a Portfolio
Common mistake Restating resume bullets with links and calling it a portfolio
What it looks likeA bullet reading Built a data pipeline, followed by a link to the same résumé wording on a profile page.
Why it failsBullets assert claims. They do not give the reviewer anything to examine.
Do this insteadReplace the bullet with the artifact it describes, something the reviewer can open and run.
Common mistake Including a repo whose code does not run
What it looks likeA project whose first setup command fails with an error.
Why it failsThe source says a repo whose code does not run is worse than no repo, because it shows the work was never checked.
Do this insteadFix the project and write a runbook that a stranger can follow from a fresh copy.
Common mistake Including a generic chatbot demo
What it looks likeA demo indistinguishable from the many built from the same popular tutorial.
Why it failsThe source notes that the hiring manager has seen ten thousand, so a familiar demo is unlikely to be remembered.
Do this insteadKeep the item only if it reflects a distinguishing decision you made, and explain that decision in the write-up.
Common mistake Presenting a write-up of a conference talk you attended
What it looks likeA long summary of a talk, with no working example of the technique.
Why it failsThe source says attending is not credentialing. It shows exposure, not the ability to do the thing.
Do this insteadBuild a working example of the technique from what you learned and include that instead.
Common mistake Assuming a large item is always stronger than a small verified one
A modest project that applies a concept you understand, runs correctly, and can be verified is a stronger item than a summary of a lecture on a more advanced topic. The source does not require original research. Its emphasis is on building from what you have learned.
Sorting Candidate Items
Sort the five candidate items below into keep and exclude. For each one, give the single criterion that decides it: verification, original building, or runnable work. Items: (a) a resume bullet restated with a link; (b) a repo whose setup fails on the first step; (c) a generic chatbot demo followed from a popular tutorial, now with a runbook; (d) a write-up of a conference talk you attended; (e) a small project applying a concept you learned, which runs from a fresh copy and includes a runbook.
Hints
- Start with the question of whether a reviewer could verify the item independently.
- The runbook test is what decides whether a working project is ready to show.
- Item (c) has a runbook, but ask whether you built it in a way that distinguishes it from thousands of others.
Keeping the Portfolio Focused
Before including any item, ask two questions: could a reviewer verify it independently, and did you build it? Then check that it runs from a fresh copy using a runbook. An item that passes all three belongs in the portfolio. Anything that fails one of them is either excluded or set aside until it is fixed.
Key Takeaways
- A portfolio holds artifacts a reviewer can examine, not restated resume bullets, because bullets assert claims while artifacts demonstrate them.
- Strong items meet three criteria: they run, a reviewer can verify them independently, and you built them from concepts you have learned.
- An untested prototype is worse than no repo, and a runbook that takes a stranger from a fresh copy to a working result is the test of readiness.
- Generic chatbot demos and write-ups of talks you attended do not differentiate you, because familiar work is easily forgotten and attendance is not credentialing.
- A modest, runnable, verifiable project built from what you have learned is stronger than a summary of an advanced lecture.