What Interviewers See When They Open Your GitHub (And What to Do About It)
A few months ago we were watching a candidate use LastRound AI to prep for a senior backend role. The interviewer asked them to “walk me through a project you’re proud of.” The candidate froze, then said “I have some stuff on GitHub.” The interviewer pulled it up. What they found was 47 repos, none pinned, three with commits from 2019, and a profile README that said “currently learning React.” The candidate had 8 years of experience. The interview didn’t recover.
This happens more than you’d think. GitHub profile tips mostly focus on aesthetics, contribution graphs, profile banners. The stuff that actually matters in a hiring context is different. It’s about what the interviewer sees in the first 30 seconds and whether that makes them want to ask you about your work or skip to the next candidate.
GitHub is not a portfolio site. It’s a working directory that happens to be public. That distinction changes how you should think about it when you’re job hunting.
Why your GitHub profile tips matter more than you think right now
The GitHub Octoverse 2025 report found 180 million developers on the platform, up 36 million from the prior year. Nearly one new developer joined every second in 2025. That’s a lot of supply. Recruiters sourcing technical talent increasingly use GitHub as a first filter, before the resume, before the screen.
Here’s what most candidates don’t know: according to data from the GitHub Octoverse 2024 report, about 82% of all contributions happen in private repositories. Meaning your public GitHub only shows roughly 18% of what you actually do at work. That’s the context. If you want that 18% to tell a complete story, you have to be intentional about what’s there.
The two sources I’m citing here are real reports you can read yourself. The Octoverse 2025 post on the GitHub Blog covers the developer growth numbers. The private-repo contribution share comes from the Octoverse 2024 report. I’m not going to cite “87% of recruiters prefer GitHub over resumes” because I cannot find a source for that number and it’s been copy-pasted across the internet without any original data behind it.
What an interviewer actually does with your GitHub link
I’ve sat in on enough mock sessions to have a sense of the pattern. When an interviewer has your GitHub link, they usually do one of three things:
1. they don’t open it at all (common at large companies with ATS pipelines)
2. they open it, glance at the pinned repos and your README, spend maybe 40 seconds, then form an impression
3. they open a specific repo you mentioned in your resume or application and read it more carefully
Option 2 is the most common, especially at mid-size companies and startups. Option 3 is the one that can actually help or hurt you. If they’re digging into a specific project, they want to see the README, the commit history, and whether the code looks like code that someone who knows what they’re doing wrote. Not “clean” in some aesthetic sense. Just coherent. Comments where needed, no 500-line functions with no context, error handling that’s at least been considered.
The confession I have about green squares: I think the contribution graph is mostly irrelevant for hiring purposes. A senior engineer with a full-time job and two kids isn’t going to have 300 green squares a year. Anyone optimizing for daily commits to fill the graph is probably optimizing for the wrong thing. The interviewer checking your contributions day by day doesn’t exist at most companies. What does exist is a human who clicks your best repo and reads two files.
What actually gets looked at (in rough priority order)
- 1. Pinned repos. These are the first thing visible below your profile bio. If you haven’t pinned anything, the default is your most-starred repos, which may not be what you want.
- 2. Profile README. If you have one. If you don’t, you just see your repositories grid with no context. Not terrible, but a missed opening.
- 3. The README inside the repo they click. This is where most of the evaluation happens if they go deeper.
- 4. Recent commits in that repo. Looking for a coherent development story, not frequency.
- 5. Your bio and links. Does this person have a presence beyond GitHub? LinkedIn, personal site, any published work?
The five things worth actually fixing
I’m going to skip the generic “write a good README” advice and be specific about what matters.
1. pin exactly the repos you’d want to talk about in an interview
GitHub lets you pin up to 6 repositories. Treat this like a whitelist, not a default. If you’re applying for backend roles, pin things that show backend work. If you’re applying for ML engineering roles, pin things with actual data processing, not just a “I’m learning PyTorch” notebook from 2021. Archive or make private anything that would make you hesitant if an interviewer asked “tell me about this repo.”
2. fix the readme in the repos you’ve pinned
The minimum viable README for a portfolio project has four things: what it does in one sentence, how to run it, what the interesting technical decision was, and what you’d do differently now. That last one is underrated. Saying “I’d replace the polling with websockets” signals more technical maturity than a polished project that never acknowledges trade-offs.
3. make sure your commit messages aren’t embarrassing
“fix” as a commit message. “asdf”. “wip wip wip”. These are fine in a private repo at 2am. They’re not fine in a public repo you’re using as a portfolio. You don’t need to follow Conventional Commits exactly. You just need messages that show you were thinking. “fix race condition in session token refresh” is infinitely better than “fixed bug.”
4. write a profile README, but don’t overthink it
A profile README is the file at yourusername/yourusername/README.md that GitHub displays at the top of your profile. It doesn’t need to have animated typing effects or a table of 20 badge icons. Three things that work: who you are and what kind of work you focus on, what you’re working on right now (one line), and links to your best repos or your personal site. That’s it. The elaborate profile READMEs with GitHub stats widgets and streak counters are mostly for GitHub’s social layer, not for hiring.
5. have at least one project with a live demo link
Vercel, Railway, Render, Fly.io, wherever you deploy. A live URL in the README is a signal that you’ve shipped something past your localhost. Interviewers notice this. Not because they’ll spend 20 minutes clicking around your app, but because it says you finished something. Plenty of GitHub repos are abandoned mid-build. A deployed project isn’t.
How this comes up in actual interviews at LastRound AI
This is a qualitative observation, not a metric. In practice rounds on LastRound AI, when a candidate shares their screen during a mock technical interview and the interviewer pulls up their GitHub, the sessions that go well are almost always the ones where the candidate can immediately navigate to a specific project and explain a real decision they made. The ones that don’t go well tend to be candidates who have a lot of public repos but can’t quickly orient to any of them, or who have a polished README but can’t speak to the actual implementation. The GitHub profile isn’t the test. It’s the starting point for a conversation, and you need to be ready to have that conversation.
See how this plays out in a real mock session with LastRound AI’s interview copilot.
What to do the week before you start applying
Not a checklist of 20 things. Here’s what actually moves the needle in 3-4 hours of work:
Go through every public repo you have. Anything that’s half-built, anything you’re not comfortable talking about, anything with commit messages that would make you wince, make it private or archive it. This is the most useful single thing you can do. Having 8 solid public repos is better than having 47 public repos of mixed quality.
Then pick the 3 or 4 you’d most want to talk about if someone asked “show me something you’ve built.” Pin those. Write or rewrite their READMEs. Add a deployed link if one is missing. Make sure the last 10 commits in each one have messages that describe what actually changed.
Write or update a profile README. Don’t spend more than 90 minutes on this. The content matters, not the design.
And then practice talking about what you’ve built. The GitHub profile gets someone to the next step. The interview is where you actually get hired. If you can’t explain your own projects clearly, a polished README won’t save you. That’s the part most people skip.
Your resume ties into this too. If your GitHub shows React projects but your resume says you’re a backend engineer, that inconsistency comes up. Worth reading the software engineer resume guide alongside this to make sure both tell the same story. And if you’re preparing for the technical screen that follows, the coding interview prep guide covers what actually happens after the recruiter clicks your GitHub link and decides to move you forward.
One more thing, only loosely related: if you’re coming from a non-traditional background and trying to break into engineering, the GitHub profile matters more than it does for people with 10 years of corporate experience. Hiring managers who’d normally reach for the credential-heavy resume are often more open to someone with a strong public body of work. That’s covered in a lot more depth in the career pivot to tech guide.
