When I open a candidate's GitHub, I give it about two minutes. Most of that goes to one repository. If that repository has no README, I close the tab.
Blame volume. A US startup hiring manager with 200 applications does the same thing, often faster. Your GitHub either answers a question for them quickly or it doesn't get read at all.
Key Takeaways
- Reviewers open your pinned repositories and one README. Build for that.
- One deployed project with a clear README beats twenty tutorial clones.
- Commit history and tests say more about you than stars.
- For many senior engineers, GitHub barely matters. Work history carries the decision.
What reviewers actually open
Roughly in this order:
1. Your profile page. GitHub lets you pin up to six repositories and gists, combined. Those six are your portfolio. Everything else is background noise.
2. The first pinned repo's README. Does it say what the project does, how to run it, and why it exists?
3. The code layout. Clear folders, tests, a config file, a lockfile.
4. The commit history. A project that arrived in one "initial commit" looks copied. Fifty small commits over three weeks look like real work.
What mostly gets skipped: the contribution graph, follower counts, and forks you never touched.
You can also add a profile README by creating a public repository with the same name as your username. Use it for three lines: what you build, your main stack, and a link to your best project. Skip the animated badges.
What to pin
| Pin this | Why it works | Instead of |
|---|---|---|
| A deployed app someone actually uses | Shows you can ship end to end | A to-do app from a course |
| A small tool or library you use yourself | Shows taste and upkeep | An untouched fork of a popular list |
| A merged pull request to a known open-source project (link it from your README) | Shows you can work inside someone else's codebase | Typo fixes presented as contributions |
| A project in the stack of the job you want | Matches what the reviewer is hiring for | Five languages at beginner level |
That last row is the one people skip. If you're applying for Go backend roles, a Go service with tests and a Dockerfile is worth more than a polished React side project.
The README that gets read
Five short sections:
- What it does, in one sentence, with a screenshot or a live link.
- Why you built it. One real reason.
- How to run it, in three commands or fewer.
- Decisions. Two or three choices and their tradeoffs. ("Postgres over Mongo because the data is relational. Would add a read replica past a few thousand daily users.")
- What's next. Shows you know where it falls short.
Write it in English, even if your code comments are in Spanish or Portuguese. The README doubles as a writing sample, and remote US teams will read a lot of your writing.
A Concrete Version
A composite example. Camila is a fullstack TypeScript developer in Guadalajara. Her GitHub has 34 public repos: bootcamp exercises, three half-finished apps, a forked UI kit. Nothing pinned.
She spends two weekends cleaning up. Twenty-seven repos get archived or made private. She pins four things: a Next.js app that tracks her running club's races (deployed on a free tier, about 40 real users), a small Node CLI that converts bank CSV exports into a budgeting format, her fork containing a merged fix to an open-source date library's timezone handling, and her profile README.
The running app's README gets a screenshot, a one-line "why", three setup commands, and a section on where server components helped and where they bit her. She adds a GitHub Actions workflow that runs 22 tests on every push.
Before the cleanup, nobody who interviewed her mentioned GitHub. After it, two of her next four interviewers opened with a question about the timezone bug. That's the real job of a portfolio: giving the interviewer something specific to ask, so the conversation starts on ground you know. She now puts that link at the top of her CV when applying to roles like fullstack TypeScript engineer.
The Honest Counterpoint
Plenty of excellent engineers have empty GitHub profiles because their work lives in private company repos. For someone with seven years at real companies, the CV and the interview make the decision and a thin GitHub costs little. Don't spend a month on side projects if your work history already speaks.
Portfolios also prove less than they used to. With AI coding tools, anyone can generate a clean-looking repo in an afternoon, and reviewers know it. That's why commit history, tests and the decisions section carry weight: they're harder to fake, and the interview will probe them. If you can't explain a line in a pinned project, unpin it. Many companies, us included, also run their own coding assessment, so read up on passing a take-home challenge. The portfolio gets you the interview. The test still happens.
Frequently Asked Questions
Should I keep my contribution graph green every day?
No. Nobody hiring cares about streaks, and daily trivial commits can look like you're gaming it. Steady real work over months is plenty.
Can I pin work I did for my employer?
Only if it's public and you have permission. Otherwise describe it on your CV and pin a public project that shows similar skills.
Is GitLab or Bitbucket fine instead of GitHub?
Yes. Reviewers care about the code and the README. GitHub is simply the link most US reviewers expect to click.
The Bottom Line
Pin fewer, better projects. Write READMEs that explain decisions. Deploy one thing people can open. Then put the link at the top of your CV and apply to a role that matches your stack.
---
Roberto Espinoza is CEO of Ruzora, which places senior LATAM engineers with US startups. Browse open roles.
