Reviewers will look, so decide what they find
When you apply for engineering roles, a fair number of reviewers will open your GitHub profile and any portfolio link you provide. Some will skim for thirty seconds. A few will read code closely, especially for smaller companies and senior roles. Either way, you do not get to explain it in the moment, so the profile speaks for you. The aim is simple: make sure what they find shows judgement and care, not a graveyard of half-finished tutorials.
This is not about faking a glittering profile. It is about curating what already exists so your real strengths are easy to see and the weak signals are out of the way.
Curate the profile, do not hoard
A profile with forty repositories, most of them forked tutorials and abandoned experiments, sends a worse signal than a profile with four solid projects. Reviewers do not assume the best repo represents you. They often assume the median one does. So raise the median.
Practical steps:
- Pin your three to six strongest repositories so they sit at the top of your profile.
- Archive or make private the dead experiments, course-along clones, and throwaway scripts.
- Remove or privatise forks you never meaningfully changed, since they clutter the view.
- Make sure your pinned work actually runs and reflects how you write code now.
Pinned repositories are the single highest-leverage control you have, because most reviewers look there first and rarely scroll past. Treat them as your shop window.
Make every showcased project readable in a minute
A reviewer should understand what a project does, why it exists, and how to run it within a minute of opening it. The README carries that weight. A good one includes:
- A one-line description of what the project is and who it is for.
- A short section on the problem it solves or why you built it.
- Clear setup and run instructions that actually work from a clean clone.
- A note on the stack and any interesting technical decisions.
- A screenshot or short demo link if it has a user interface.
The "why" matters more than people expect. A project that says "I built this to learn how rate limiting works, then load-tested three strategies" tells a reviewer about your curiosity and rigour. A bare repo with no README tells them nothing, so they move on.
Let your code show judgement
If a reviewer opens the source, they are reading for judgement more than cleverness. A few things make a strong impression:
- Sensible structure, with files and folders organised the way a teammate would expect.
- Meaningful names and small, focused functions over dense one-liners.
- Tests for the core logic, even if coverage is not complete. Some tests beat none.
- Error handling where it genuinely matters, not defensive noise everywhere.
- A consistent style, ideally enforced with a linter and formatter config in the repo.
You do not need a perfect codebase. You need code that looks like it was written by someone who would be easy to work with. One well-built project beats five sprawling ones with copy-pasted code and no tests.
Tidy your commit history and hygiene
Reviewers sometimes glance at commit history, and it reveals habits. A history of "fix", "stuff", and "asdf" messages reads as careless. You do not need to rewrite years of history, but for showcased projects, aim for commit messages that describe the change in plain language.
Check the basics too:
- No secrets, API keys, or credentials committed anywhere. Scan before you make a repo public.
- A sensible .gitignore so you are not committing build output or local config.
- A license file if you want the work treated as genuinely open.
- A profile README on your GitHub landing page with a short, human introduction.
Committed secrets are both a security problem and a judgement signal, so this is worth a careful pass before any profile goes in front of an employer.
Build your green squares honestly, or ignore them
The contribution graph gets more attention than it deserves. A consistent history of real work looks good, but reviewers who know the platform also know the graph is easy to game and that plenty of serious work happens in private or company repositories. Do not stuff your graph with trivial daily commits to fake activity, because it is transparent and a little embarrassing if noticed.
If your best work lives in private or work repositories, that is normal. Mention it plainly in interviews and describe what you built, the constraints, and your specific contribution. A strong verbal account of private work carries more weight than a busy public graph of throwaway commits.
Treat the portfolio site as a curated front page
If you keep a personal portfolio site, treat it as the curated version of your GitHub, written for humans who may not read code. For each featured project, include the problem, your role, the stack, the outcome, and a link to the live demo or repo. Keep it fast, keep it simple, and make sure every link works, because a broken demo link undercuts everything around it.
You do not need an elaborate site. A clean single page with three strong projects and a clear way to contact you does the job. Reviewers are looking for signal and ease, not visual fireworks.
Make it match the role you want
Finally, align what you showcase with the roles you are chasing. If you want backend work, pin projects that show data modelling, APIs, and reliability rather than a flashy frontend toy. If you are targeting AI-native roles, surface work that involves model APIs, evaluation, or data pipelines, with a README that explains how you measured quality. A reviewer should be able to glance at your pinned repositories and immediately see someone who fits the role, not someone they have to squint at and guess about.
Continue your prep
Pair a clean profile with role-specific interview practice: