- Portfolio optimization is a signal filtering problem, not a quality problem — most developers are fixing the wrong thing
- Per a Q2 2025 analysis of 1.39M applications, interviewed candidates had lower GitHub presence than non-interviewed ones — LinkedIn networking drove more initial interviews
- 3–5 polished projects with documented process outperform 15+ repos, but not for the reason you think
- Live demos eliminate a specific evaluation risk that no other portfolio element addresses
- Big tech hired 25% fewer new graduates in 2024 — early-career devs face a structurally different market than mid-career ones
The Signal Problem Nobody Names
Here’s the thing about portfolio advice. Most of it treats the hiring process like a quality contest. Build better stuff, document it better, deploy it — and you win. The problem is that framing is wrong.
Hiring is a filtering problem. Specifically, it’s a signal-to-noise problem. And if you don’t understand what layer of the filter you’re actually stuck at, you can spend months polishing your GitHub profile while your application never reaches a human being.
So your resume gets filtered before a human sees it. Fine. Everyone knows this. But here’s the part that breaks the “build a better portfolio” logic: a Q2 2025 job search analysis by Huntr, covering 1.39 million applications submitted since Q4 2024, found that candidates who received interviews had significantly higher LinkedIn presence (69.4%) compared to those who didn’t (61%). But they had lower GitHub presence. “Professional networking trumps code portfolios for getting initial interviews,” the report concluded. Population: 1.39M applications, user-reported outcomes. Conservative floor estimate per authors.
Jobscan’s ATS data establishes that the first filter is algorithmic — keyword-based, resume-first. Huntr’s application data establishes that the second filter is network-based — LinkedIn presence predicted interviews better than GitHub activity. Neither source discusses the third filter, which is what portfolios actually affect: the decision made after a recruiter has already decided to proceed. Your portfolio doesn’t get you in the door. It prevents you from being rejected after you’re through it. These are different problems, and solving one doesn’t solve the other. A developer who fixes only their portfolio but not their LinkedIn and resume is optimizing the third filter while the first two remain broken.
The implication: you probably need all three layers working. But the order matters. A jaw-dropping portfolio with a keyword-bare resume and a dormant LinkedIn won’t outperform a decent portfolio with a tailored resume and an active network presence.
What Screening Actually Does to Your Application
Let’s name the three filters explicitly, because “the ATS is bad” is not useful without specifics.
Filter 1 — Algorithmic. Your resume goes into an ATS. Jobscan’s 2025 ATS audit found that Workday now accounts for over 39% of Fortune 500 ATS deployments — up from 37.1% in 2024. Workday, Greenhouse, and Taleo all handle keyword matching differently. Greenhouse doesn’t recognize abbreviations; if the job description says “Masters of Business Administration” and you wrote “MBA,” it doesn’t count. These systems are not smart. They are consistent. You solve this with tailored resumes, not better portfolios. Conflict of interest: Jobscan data from a company selling resume optimization tools. Cross-checked against employer-reported behavior.
Filter 2 — Social. Recruiters find candidates proactively. Huntr’s application data suggests LinkedIn presence predicts getting interviews more reliably than GitHub activity. This is before your portfolio ever gets seen. You solve this with network presence.
Filter 3 — Evaluative. A human reviewer — recruiter, tech lead, or hiring manager — is now looking at your materials. This is where your portfolio finally matters. And here, the quality signal is real.
A developer whose portfolio is disorganized doesn’t just fail the quality check. They fail it in a way that’s invisible to them — because the reviewer closes the tab and moves on without sending feedback. The developer assumes their application is “in process.” They aren’t told their profile was dismissed in under 30 seconds. This is why developers keep sending the same broken applications: the failure mode evades detection.
Per Flatiron School’s recruiter research, recruiters spend roughly 6 seconds on an initial resume scan. A Carnegie Mellon study on GitHub evaluation found employers favored “easily verifiable and reliable measures” — frequency of activity and project ownership — over code quality assessments that took more time than they had.
“Hiring is up, yet 74% of developers still struggle to land jobs. The disconnect isn’t about demand; it’s about how companies hire, evaluate, and retain talent.”
HackerRank 2025 Developer Skills Report — survey of 13,732 developers, engineering managers, recruiters, and students across 102 countries, Q4 2024–early 2025
The market context matters here. HackerRank’s 2025 report found that hiring signal activity increased across the board in 2024, but growth skewed heavily toward senior roles. Data cited by Jonas David at Medium (attributing venture analysis from Temkin 2025) suggests big tech hired 25% fewer new graduates in 2024 than the year prior, even while increasing mid-career hiring. Junior devs face a structurally different market than those with 2–5 years of experience. David’s piece attributes this figure to Temkin 2025, TechCrunch — treat as directional, not independently audited here.
Why the divergence? Partly AI. Entry-level work that used to require a junior hire can increasingly be done with AI-assisted senior engineers. This is a thesis-complicating finding for “just get a job in tech” content. The market is not uniformly competitive — it’s bifurcated.
Portfolio Mechanics: What Actually Changes an Evaluator’s Decision
Right, so you’ve gotten past filters 1 and 2. A human is looking at your stuff. Here’s what they’re doing, mechanically.
They’re not reading your code. They’re scanning for evidence that you’re not a risk. Specifically: can I put this person in front of our team? Do they understand what production software looks like? Can they communicate? The portfolio has to answer all three questions in under two minutes.
| Portfolio Element | What It Signals | Evidence Level | ⚠ Limitation |
|---|---|---|---|
| Live deployed demo | You understand production environments; the code actually runs | Strong | Broken demos actively hurt you. Many hiring managers never clone repos — a 404 is a rejection. |
| Clear README with problem → approach → outcome | Communication ability; you understand your own work well enough to explain it | Strong | Generic READMEs (“Todo app in React”) signal no deeper thinking than the tutorial it came from. |
| 3–5 polished repos vs. 15+ basic ones | Judgment; you know what’s worth showing | Moderate — practitioner consensus, not large-sample study | Rule of thumb, not empirically tested. Senior devs with long career history may legitimately have more. |
| Open-source contributions | Collaboration; you can work in someone else’s codebase | Moderate — cited in Carnegie Mellon GitHub hiring study (2013, mechanism stable) | Some hiring managers on HN explicitly said empty GitHub doesn’t hurt candidates — it depends heavily on company type. |
| AI/ML integration in projects | Relevance; you’re not behind the curve on tooling | Directional — based on job posting trend analysis, not hiring outcome data | Superficial LLM wrappers are immediately recognizable and don’t help. Depth matters more than presence. |
| Consistent commit history with clear messages | “Activity signal” — CMU research identified frequency of activity as a more reliable hire signal than code quality, due to assessment time constraints | Moderate — CMU study methodology: qualitative recruiter interviews, not outcome-matched hiring data | Quantity of commits without quality is worse than sparse commits. “Fixed stuff” commit messages are a red flag. |
The README problem, specifically
Generic descriptions cost more than you think. “Todo app built with React” tells an evaluator: you followed a tutorial, you didn’t solve a problem, and you didn’t think about what anyone else would need to know to evaluate this. Contrast: “Task management tool with drag-and-drop priority ranking, real-time sync via WebSockets, and offline-first caching — built to solve my own workflow problem of losing tasks during unreliable conference WiFi.” Same React. Different signal entirely.
The README is where evaluation actually happens for time-constrained reviewers. A good README structure follows: what problem does this solve, how did you approach it, what did you learn or what would you do differently. That last part is almost never included, and it’s the one that distinguishes someone who’s reflected on their work from someone who just shipped it.
The Counter-Intuitive Data and What It Actually Means
Back to the Huntr finding. Interviewed candidates had lower GitHub presence than non-interviewed candidates. I want to be careful about how to interpret this. It doesn’t mean GitHub hurts you. It means LinkedIn presence — which correlated with being interviewed — likely reflects network effects: passive candidate discovery, recruiter outreach, being found rather than applying cold.
Here’s the mechanism: candidates who are found by recruiters are more likely to be hired than candidates who apply cold. A strong LinkedIn presence increases the chance you’re found. GitHub presence, while valuable in the evaluative stage (filter 3), doesn’t drive that initial recruiter discovery the way LinkedIn does. These two things are solving different parts of the problem.
“The job seekers who thrive aren’t the ones applying to the most jobs. They’re the ones being strategic, leveraging networks, and continuously developing relevant skills.”
Editorial synthesis — sources: Huntr Job Search Trends Q2 2025 (1.39M applications); HackerRank Developer Skills Report 2025 (13,732 respondents); LHH/Adecco Group Global Workforce of the Future Research 2025
The failure case here is the developer who spends four months polishing their GitHub while their LinkedIn profile shows a job title and nothing else. I’ve seen this. The instinct is to fix what you control (the code, the READMEs, the project selection) and avoid what feels uncomfortable (networking, showing up in the professional discourse, having opinions publicly). That instinct is backwards. The uncomfortable thing is what’s blocking you.
One more data point that complicates the “just build more projects” advice: HackerRank’s 2025 report found that AI-generated resumes are flooding application pipelines, making it harder for companies to separate strong candidates from noise. Both the quantity of applications and the perceived quality of applications have increased — which means differentiation is increasingly about signals that AI can’t fake. Demonstrated thinking (process documentation, commit message quality, contribution discussion) matters more now specifically because AI-generated surface signals are everywhere.
As AI code generation improves, the code itself becomes a weaker signal of developer ability. A recruiter looking at a clean React component in 2023 could reasonably infer developer competence. In 2026, that inference is shakier — was it written, or prompted? The signals that remain hard to fake are: documented decision-making (why this architecture, not just what), contribution quality in collaborative repos (responses to code review, issue discussion), and live explanation during interview. This shifts portfolio value from “showing the output” toward “showing the thinking behind the output.”
This is the complication I’d add to the original article’s framing. It treats the portfolio as a fixed problem with a fixed solution. The actual problem is that the evidence of competence keeps shifting as the tooling changes. What worked in 2022 (clean code, consistent commits) is table stakes now. What works in 2026 is documented thinking and live demonstration.
What To Actually Build (And In What Order)
Okay. Concrete stuff. The sequence matters more than the tactics.
Fix the First Two Filters First
- Keyword-audit your resume against 5 actual job descriptions using Jobscan or Huntr (both have free tiers) Both companies sell resume optimization tools — conflict of interest disclosed
- Update your LinkedIn headline beyond job title: “Full-Stack Developer | TypeScript, Python | Building production tools at [company]”
- Check every link in your existing portfolio. Every. Single. One. A 404 on your featured project is an instant rejection from a time-constrained reviewer.
Archive and Rebuild
- Archive repos that are tutorial clones or incomplete. Don’t delete — just unpin and set to private if they don’t represent your best work
- Pick one existing project and rewrite the README from scratch: problem → approach → outcome → what you’d do differently
- Deploy that project if it isn’t already. Vercel, Netlify, and Railway all have free tiers. No excuses.
One Original Project That Solves a Real Problem
- The “real problem” constraint is non-negotiable. What actually frustrated you last month? What’s a workflow at your current or previous job that was stupidly manual?
- Document the decision-making as you build. A short “Architecture Decision Record” (ADR) in the repo shows evaluators you think about tradeoffs, not just output
- If you’re pursuing ML/AI roles: deploy a model, don’t just submit a notebook. A Jupyter notebook is not a portfolio piece. A deployed prediction API with documented methodology is.
- AI literacy projects that work: LLM-powered internal tools, automated data pipelines, prompt chaining with documented failure cases. Not: “I made a ChatGPT wrapper.”
Make It Findable
- Contribute to one open-source project — not for the commit count, but for the collaboration artifact it creates. A code review exchange shows communication ability that solo projects can’t.
- If you build a portfolio website: keep it fast, keep it professional, keep your best three projects front and center. A poorly designed portfolio website is worse than no portfolio website.
- Apply to 10 highly targeted roles, not 100 generic ones. Huntr’s data found tailored resumes generate roughly 6 interview opportunities per 100 applications, versus fewer than 3 for generic submissions. User-reported outcomes, likely conservative floor estimates per authors.
Stop doing this
Adding tutorial clone projects to your portfolio. Hiring managers recognize freeCodeCamp calculators and Traversy Media clones on sight — not because they’re snobbish, but because they see dozens of them. The clone signals that you followed instructions. Original projects signal that you identified a problem and solved it. Those are different skill demonstrations.
Don’t add consent banners and call it “privacy-focused” without understanding what the project actually does differently. Don’t claim “machine learning” if what you have is a scikit-learn notebook with no deployment. The disconnect between claimed complexity and visible evidence is more damaging than not claiming the complexity at all.
Before / After: What This Looks Like on an Actual Repo
Advice is abstract until you see it applied. The three pairs below are composite examples — reconstructed from patterns we see repeatedly across dozens of portfolios reviewed for this series, not screenshots of one real person’s GitHub. We’re not publishing identifying details of real candidates without consent; these composites keep the mechanics honest while protecting anyone’s actual repo from being used as a “before” example without asking first.
1. Project description
Todo app built with React and Firebase.
Task manager with drag-and-drop priority ranking, real-time sync via WebSockets, and offline-first caching — built to stop losing tasks over unreliable conference WiFi.
2. README opening
This is a weather app I made. It uses the OpenWeather API. Clone the repo and run npm install to get started.
Weather dashboard for people who check 3+ cities daily (I have family across time zones). Chose client-side caching over a backend to keep hosting free — tradeoff: no historical data. Live demo below; setup instructions further down for anyone who wants to run it locally.
3. Commit message pattern
fix stuffupdatewipfinal final v2
Switch auth to httpOnly cookies (XSS risk in prior localStorage approach)Add optimistic UI update for task reorderDebounce search input to cut API calls ~70%
For You Specifically
Your market is structurally harder right now. Here’s the specific play.
Look, here’s what this actually is: you’re entering a market where big tech hired 25% fewer graduates in 2024 than the year prior. AI is absorbing some of what used to be junior work. You’re not competing on experience — you’re competing on signal clarity. One polished project with documented decision-making beats ten tutorial clones. Not metaphorically. Actually.
What you do: Build one project that solves a problem you personally have. Document every architectural decision, even trivial ones (“I chose Postgres over SQLite because I expected to need concurrent writes”). Deploy it. Make the README an explanation of your thinking, not a description of the features. Then contribute to one open-source project — target projects with active maintainers who respond to PRs, because the back-and-forth exchange is what creates a visible collaboration artifact.
Here’s what’s going to stop you: Entry-level positions in software dropped more than 50% on one major job platform between 2022 and 2025, per Thompson (The Atlantic, 2025). The barrier isn’t your skills — it’s the volume of senior candidates who’ve been laid off and are competing for the same roles. LinkedIn presence and network referrals are disproportionately valuable here because referred candidates bypass the ATS entirely.
The market is moving toward you. But “experience” alone isn’t the signal anymore.
Look, here’s what this actually is: you’re in the demographic that big tech is actively increasing hiring for. The problem is that your portfolio was built when the standards were different. Projects that showed “I can build a REST API” were differentiated in 2018. They’re table stakes now. The question is whether your portfolio shows architectural judgment — the ability to make tradeoffs, not just implement features.
What you do: Audit your pinned repos for anything that documents a decision with a tradeoff. “I chose microservices because X; the cost was Y” is worth more than a clean monolith with zero explanation. Add at least one project that integrates AI tooling meaningfully — not a wrapper, but something where AI changes the core value proposition. Your specific advantage over junior candidates is your judgment; your portfolio needs to make that judgment visible.
Here’s what’s going to stop you: Mid-career portfolios often look like “a bunch of work projects I can’t share + a few side projects from 2021.” The work projects are real proof but NDA-protected. The solution: rebuild the concept (not the code) from scratch in a personal project, then document the architectural decisions you made in the actual work context. The documentation is the signal; the code is just the evidence.
The Portfolio Audit: 20 Points
The 7-item version of this used to live here — it’s now folded into a fuller audit. Run through all 20 before your next application. Most checks take under a minute; the whole thing takes about 15.
Section 1 — GitHub profile
- Exactly 3–6 repos pinned — varied by tech stack and problem domain, not six variations of the same framework
- Every pinned repo’s description names an outcome (“cut sync latency to 200ms”), not just a technology (“React app”)
- Every pinned repo has a working live demo link, or explicitly states why not (CLI tool, library, local-only)
- Your profile README exists and answers three things: what you build, what stack you prefer and why, how to reach you
- Commit messages on your three best projects read like short technical decisions — not “fix,” “update,” or “stuff”
- Any repo you’d be uncomfortable discussing in an interview is set to private, not just unpinned
- Your contribution graph shows activity in the last 30 days
Section 2 — Project & README quality
- Every link in your portfolio works — test each one manually; a 404 on your featured project is an instant rejection
- Each README follows: problem → approach → outcome → what you’d do differently
- At least one project documents an architecture decision with the tradeoff explained
- No tutorial-clone projects are pinned — no unmodified freeCodeCamp or Traversy Media walkthroughs
- At least one open-source contribution shows a visible collaboration artifact: a PR thread, a review exchange, an issue discussion
- If you claim AI/ML skills, there’s a deployed model or working integration behind the claim — not just a notebook
Section 3 — Site, resume & LinkedIn alignment
- If you have a portfolio website, it loads in under 3 seconds and works cleanly on mobile
- Your LinkedIn headline names specific skills and current focus, not just a job title
- Your resume has been keyword-matched against 3–5 real target job descriptions
- Every bullet point in your resume and README states an outcome with a number, not a responsibility
- Your handle/username is consistent across GitHub, LinkedIn, resume, and portfolio site
- Incomplete projects include what stopped you and what you’d do differently
- A quarterly review is on your calendar — outdated projects get archived or unpinned every three months
portfolio-audit-20-points.pdf to the media library and confirm this URL before publish. A Notion-importable version can be built the same way on request. Watch a Portfolio Get Audited Live
Reading a checklist and watching someone apply it to a real profile are different kinds of learning. We record short, unscripted portfolio reviews — this is where that series will live once the first episode is published.
- Send your GitHub and/or portfolio URL to [email protected] with the subject line “Portfolio review”
- Confirm you’re OK with the review being public (we’ll anonymize on request, but the code itself will be visible)
- Reviews are unscripted — expect direct feedback, not a highlight reel
Questions That Actually Come Up
How many projects should I include?
3–5 polished, deployed projects consistently outperform larger portfolios of basic work. The reason isn’t aesthetic — it’s signal clarity. Depth signals expertise; breadth signals you haven’t finished anything. Each project should stand alone as evidence of a specific judgment call, not just a skill. If you can’t articulate in one sentence what problem this project solves and why you solved it this way, it’s not ready to be pinned.
Do I need a portfolio website, or is GitHub enough?
GitHub is non-negotiable. A personal portfolio website is beneficial but not universal. A poorly designed website — inconsistent typography, broken mobile layout, slow load times — actively signals worse than no website. If you can’t make it fast and professional, focus on GitHub. The portfolio website decision depends on your target roles: design-adjacent positions benefit more than pure backend engineering roles.
What about AI/ML skills — do I really need them for non-ML roles?
Directional evidence suggests yes, but the bar is “literacy,” not expertise. Job postings increasingly include AI tooling familiarity as a listed skill even for general software roles. What matters: can you integrate an LLM API intelligently? Can you explain when not to use AI for a given problem? One project that demonstrates thoughtful AI integration is more valuable than three projects that gesture at it. Based on job posting trend analysis — directional, not hiring outcome data.
Should I include incomplete projects?
Only if you document what you learned and what stopped you. The documentation turns an incomplete project from a liability into a transparency signal. “I stopped this project when I realized the architecture I chose would require a full rewrite to support multi-tenancy. Here’s what I’d do differently” shows more judgment than a finished project with no reflection. Don’t include projects you abandoned because you got bored and have no lesson to surface.
I can’t share my work projects due to NDA. How do I show relevant experience?
Rebuild the concept, not the code. If you built a payment retry system at work, build a payment retry system as a personal project — different codebase, different company, different data, same architectural problem. Then document the decisions you made, which can include “I’ve solved a version of this problem before and here’s what I learned.” The goal is creating a visible artifact of your judgment, not revealing trade secrets.
How much does the GitHub contribution graph matter?
Moderately. CMU research found frequency of activity was one of the more reliable signals hiring managers looked for — specifically because it’s verifiable, unlike self-reported skill levels. But a blank graph with three excellent repos beats a green graph full of “fix typo” commits. Quality of what you’re committing matters; the graph is a proxy, not the thing itself. Some strong practitioners make this exact argument on HN and don’t maintain public activity at all.
The application volume advice in most guides seems impossible. Is 100 applications really necessary?
Probably not, if you’re targeting correctly. Huntr’s Q2 2025 data found tailored resumes generate roughly 6 interviews per 100 applications versus under 3 for generic submissions. The math changes significantly if you’re referred: sourced candidates bypass ATS entirely and face very different acceptance rates. Targeting 20 well-matched roles with tailored applications and network connections is likely more effective than 100 cold applications. I don’t know exactly how much more effective — the data isn’t conclusive on this — but the direction is clear. Directional — Huntr data based on user-reported outcomes, likely conservative floor estimates.
The Actual Takeaway
Look, most portfolio advice is solving the third filter — the evaluative stage — while assuming the first two are already working. They usually aren’t. The developer who fixes only their GitHub while their LinkedIn is dormant and their resume is keyword-bare is optimizing the wrong thing.
The sequence is: fix the resume for ATS, fix LinkedIn for discoverability, then fix the portfolio for the human who’s now looking at your work. Skip any step and the chain breaks.
The harder truth from the Huntr data: being found beats applying. A developer who builds a distinctive portfolio, writes about their work occasionally, and maintains an active LinkedIn presence is generating inbound interest — which converts at dramatically higher rates than cold applications. That’s not a portfolio problem. It’s a visibility problem that a portfolio alone can’t solve.
Your portfolio is the evidence presented at the trial. But someone has to bring you to trial first.
Update yours quarterly. Remove what no longer represents your best judgment. Add what shows how you think now, not who you were in 2022.