“Your GitHub is your new resume.” People started saying some version of this around the time contribution graphs turned green squares into a personality trait, and they haven’t stopped.
I don’t think it’s true, exactly, and I don’t think it’s false either. Nobody has clean data on this — not me, not the career-advice sites quoting a callback-rate lift with three significant figures and no methodology attached, not the recruiter who’ll tell you in one breath that they always check GitHub and in the next admit they mostly don’t have time to. I spent twenty minutes chasing the study behind those percentages you’ve probably seen anyway, on the theory that a real number would make this whole piece shorter and more useful than my opinion is. What I got back instead were five different sites confidently citing a “73 percent of hiring managers” figure, each with a different alleged source, none of which led anywhere near an actual survey. One cited another one of the five. A number that specific, repeated that widely, and traceable to nothing, is worse than no number at all, because it borrows the authority of research it never did. So set the percentages aside entirely. What’s left is smaller and more useful: what the people who build hiring processes for a living, and put their names on it, actually say about what they built.
Open source, side projects, writing, and the personal site that’s supposed to tie them together don’t carry equal weight, and most advice treats them as interchangeable pieces of the same homework assignment.
Most open source contributions don't move the needle
Start with the myth, because it’s the loudest one, and because conceding its strongest version first is the only honest way to argue against it.
Open Source Guides (GitHub)How to Contribute to Open SourceThe official guide. Frames contributions as public work samples — and quietly admits most of them aren’t code.GitHub’s own contributor guide makes the career case plainly: all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do. That’s true, and it’s also doing a lot of quiet work in the word “examples,” because the guide’s own numbers cut against the version of this story where you land a big feature in a popular repo and a hiring manager notices. It cites research putting 28 percent of casual open source contributions at documentation — typo fixes, reformatting, a translation. That’s not a footnote. That’s the modal contribution.
GitHub’s own docs on contributing tell first-timers to look for issues tagged “good first issue” or “help wanted” — the label maintainers use specifically to flag the small, contained, low-risk stuff. The entire on-ramp most engineers are pointed toward is built for minor fixes, not moonshots. Which makes sense if you’ve ever maintained anything: an unsolicited pull request that rewrites your auth layer is a burden, not a gift, and most maintainers will tell you so, sometimes politely.
A pull request that fixes a typo in a README counts.
Nobody puts that on a resume.
GitHub’s guide is explicit that responding “promptly and professionally” and working within the existing thread rather than opening a new one is part of what a good contribution looks like — advice written entirely from the maintainer’s side of the desk, with your visibility nowhere in the calculation. A maintainer reviewing your first PR is doing you a favor on a volunteer clock, and the contributions that respect that are, structurally, the small, unglamorous, well-scoped ones. None of this means don’t contribute. It means the contribution that actually helps a maintainer is rarely the one that was ever going to impress an interviewer, and treating the two as the same activity is where the advice breaks down.
The honest case for open source has nothing to do with a hiring manager. It’s that you get to read code written by people better than you, under review from strangers who owe you nothing and will say so directly. That’s a real education. It’s just not a portfolio piece, most of the time.
A shipped side project reads as effort, not skill
Julia Evans wrote about the year she spent recruiting rather than being recruited, and one line from it has stuck with me since I first read it: she’d written a cookbook for the Python library pandas on a long train ride, and now there are people who I don’t know using it and asking Stack Overflow questions about it, which is super surprising.
Julia Evans, MediumSwitching sidesWhat she learned watching resumes land in a stack from the other side. The pandas-cookbook line is the whole argument in one sentence.A stranger using something you built and not knowing your name is a stronger signal than any commit count, and it’s a much higher bar than most side projects clear. Most side projects clear a lower bar: they prove you can start something and, this time, finish it. That’s a real signal too, just a quieter one, and it says more about your follow-through than your ability.
It also cuts both ways. A GitHub profile with nine abandoned repos, each with one commit and a README that says “TODO,” tells a specific story, and it isn’t the one you meant to tell.
Writing is the one variable actually within your control
Of everything on this list, writing is the one where the advice from people who’ve actually done a lot of it converges, and where doing it well doesn’t require anyone’s permission, a maintainer’s blessing, or a side project that happens to go somewhere.
Julia Evans, jvns.caBlogging principles I useWrite for the version of yourself from a year ago. Admit what you don’t know — readers trust it more, not less.Julia Evans, jvns.caHow do you write blog posts?Concrete mechanics: half her posts run under 500 words, most take one to three hours, and she publishes without heavy editing.Two questions from that second post do more work than any advice I could add: would this have helped me a year ago? and would this have helped me last week? Answer yes to either and you have a post. You don’t need a novel angle, a strong opinion, or three months of research. You need a bug you actually fixed, written down clearly enough that the next person who hits it finds it.
This is where the case for a personal blog beats the case for a side project outright: a post takes an evening, not a season, and it’s finished the moment you publish it, which means you can produce ten of them in the time a side project takes to reach the point where you’re embarrassed to link it.
The personal site is real estate, not a resume rewrite
The default mistake is restating your resume on it. That information already exists, in a format recruiters already know how to scan, and a personal site that just repeats it in prose is a worse resume with extra steps.
What it should hold is the writing, an index of the two or three projects worth a second look, and a way to reach you that isn’t a contact form. That’s it. Design effort past that point is procrastination dressed as productivity — I’ve lost entire evenings to font choices instead of writing the post the font was supposed to hold, and I’d guess you have too.
Staff-level career advice mostly skips this entirely
Will Larson, StaffEngWhat do Staff engineers actually do?Sets technical direction, mentors, provides organizational judgment. No mention of a blog, a GitHub profile, or a personal site — not an oversight, a signal.I went looking for where StaffEng — the closest thing this industry has to a documented account of how people reach senior individual-contributor roles — talks about public writing or an outward-facing portfolio as part of that path, expecting to find at least a paragraph on it given how often “build in public” gets repeated as career advice one level down. It isn’t there. The site is about influence inside an organization: setting direction, being trusted with ambiguous problems, being the person a VP asks a hard question and believes the answer to. None of that is visible from outside the company, and no personal site fixes that.
The other data point worth sitting with: the single most-starred free resource engineers actually reach for when they’re trying to get hired is an interview handbook, not a portfolio guide. Tech Interview Handbook sits at 141,000-plus stars, MIT-licensed, built by one engineer, Yangshun Tay, and expanded by contributors since. Demand tracks toward what decides outcomes. If portfolios decided outcomes the way interviews do, you’d expect a comparably starred repo for that. I couldn’t find one.
What to actually spend a free weekend on
If you have four hours and want the highest odds of it mattering to someone besides you: write about the last bug that actually cost you an afternoon. Not a tutorial, not a “top 10” list — the specific, annoying thing, with the wrong turns left in.
If you want to contribute to open source, look for the “good first issue” label and treat the documentation fix as equal in standing to the code change, because the maintainer receiving it will.
And once any of this starts generating actual inbound — a recruiter who read the post, a maintainer who remembers your name — the failure mode shifts from “nobody’s looking” to “I lost track of who replied to what.” That’s a bookkeeping problem, and it’s the one Vigil is actually built to solve.
The GitHub grid was never the resume. It just looked like one from far enough away.