Hiring managers skim portfolios in seconds, and most portfolios fail the skim identically: the same weather app, the same e-commerce clone, the same todo list with a fresh coat of Tailwind. The projects aren't bad code — they're indistinguishable, which is fatal when the reader's question is "what does this person do differently?" Here's how to build portfolio pieces that survive contact with an actual screener.
Understand what the skim looks for#
A reviewer spends 30–60 seconds per project answering four questions:
- Can this person finish things? Deployed and working beats ambitious-and-broken, every time.
- Do they understand real constraints? Error states, loading behavior, data that isn't pristine.
- Is there evidence of judgment? Decisions visible and explained — why this approach, what got cut.
- Would working with them be pleasant? README quality, commit hygiene, communication tone.
Notice none of these require impressive scale. A small project that answers all four beats a half-finished distributed system that answers none.
Five project archetypes that stand out#
1. Solve your own annoying problem. You track something in spreadsheets; automate it. Built for a real user (you), it naturally has authentic requirements, iteration history, and a story to tell in interviews. Original problems signal original thinking.
2. Rebuild something mundane exceptionally well. Take a boring tool everyone uses poorly — an invoice generator, a habit tracker, a markdown editor — and execute it flawlessly: fast, accessible (the basics), polished edge cases. Depth on a small canvas demonstrates taste, which interviewers can't teach.
3. Contribute to open source you actually use. Even documentation fixes and small bug patches prove you can navigate unfamiliar codebases, follow contribution norms, and collaborate asynchronously — precisely the job skills resumes can't show. Start where you have user context.
4. Data-flavored projects with honest writeups. Pull a public dataset, answer a specific question, publish findings including dead ends ("my first hypothesis was wrong because…"). Analytical honesty is rare and memorable. Traders can even make this personal: backtest results analyzed properly are genuinely interesting engineering content.
5. The tool other developers would install. A CLI utility, a browser extension solving one irritation, a well-documented library wrapping an annoying API. Developer-tools projects get shared, starred, and used by exactly the people interviewing you.
Presentation: the difference between read and skipped#
- Deploy it. A live URL with a demo account pre-filled removes every ounce of friction. "Clone and run locally" loses half your audience instantly.
- Write the README for the skimmer: one-sentence pitch up top, screenshot or GIF of it working, then decisions-and-tradeoffs notes. Explain what was hard and why you chose what you chose — reasoning is the résumé.
- Commit history tells the truth anyway, so let it be good: meaningful messages, incremental progress. One giant "final commit" says the opposite of what you intend.
- Three excellent projects beat eight adequate ones. Curation is the demonstrated skill.
- Link real usage if any exists — even twelve users makes a project feel alive rather than academic.
The meta-move: document publicly as you build#
A build log — short posts or threads per milestone — compounds everything above. It generates searchable proof of process, gives interviewers stories to ask about, and quietly becomes writing samples for the communication skills every team claims to want. The portfolio stops being a gallery of artifacts and becomes evidence of a working engineer's mind — which is, finally, the only thing anyone is actually trying to hire.
Related: reading unfamiliar codebases is the skill open-source contributions exercise, and planning systems keep side projects from joining the graveyard.
