Adding a GitHub link at the top of a developer resume has become a reflex. But a link is only useful if what it opens confirms what the resume claims. An empty profile, a series of forks never modified or a project without a README can cost you more than having no link at all. This article describes who clicks, at what point, what a tech lead looks at in a few minutes, and how to prepare your profile before showing it, including when most of your code is private.
Who opens the link, and when
The GitHub link is not opened by everyone, nor at the same point in the process.
The recruiter or talent acquisition specialist rarely opens it in detail. If they click, it is to check that it exists, that the profile looks active and that it matches the stack in the job ad. A glance at the profile home page is enough for them: name, photo or avatar, a few pinned repositories with their main language.
The tech lead or manager opens it more often, usually just before the first technical interview, to prepare their questions. They spend a few minutes on two or three repositories, rarely more. They do not read all the code: they look for clues about how you work.
The team, finally, may open a specific repository if you mention it during the interview or offer it as a basis for discussion instead of a technical exercise.
This leads to a simple rule: your profile must be readable in thirty seconds by a non-specialist, and convincing in five minutes for a lead.
Pinned repositories and the profile README
Pin what represents you
GitHub lets you pin up to six repositories 🔗 at the top of your profile. They are almost always the only ones people look at. Choose two to four, using these criteria:
- a project that matches the stack of the role you are targeting;
- a finished project that works, with a demo or instructions to run it;
- a recent project, which shows that you are still coding;
- possibly a contribution to an open source project that you actually changed.
Avoid pinning course exercises, tutorials followed to the letter and forks with no commits of your own. A lead recognises them very quickly.
Take care of each repository’s README
The README 🔗 is the first thing a lead reads in a repository. In a few lines it should answer five questions: what the project does, why you built it, with which stack, how to run it locally and where to see it working. Add a screenshot or an architecture diagram if the project lends itself to it, and a section on technical choices and known limitations.
That last section is often the most convincing. "Payments are simulated; a real integration would require idempotent webhook handling" shows that you know where your project stops, which leads value highly.
The profile README
GitHub also lets you display a profile README 🔗 by creating a repository named after your username. It is useful if it stays plain: two or three lines on your profile, your main stack, the projects to look at first and a way to contact you. Animated banners, visit counters and long lists of technology logos add nothing and give an amateurish impression.
What the commit history reveals
A lead who opens a repository almost always looks at the commit history, because it says a lot about how you work.
What they look for:
- clear messages that describe the change ("Add pagination to the bookings API") rather than repeated "fix", "update" or "wip";
- reasonably sized commits, each matching one intention, rather than a single giant commit containing the whole project;
- progression over time, showing that the project was built and improved, not dumped in one go;
- use of branches and pull requests, even on your own, if you want to show your code review practice.
What they also notice, and what you must fix before adding the link:
- committed secrets: API keys, passwords, environment files. This is a deal-breaker. GitHub offers secret scanning 🔗, but the safest approach is never to commit any and to revoke any exposed key immediately;
- dependency folders or generated files in the repository, a sign that no ignore file was configured;
- large amounts of commented-out code and unused files.
The contribution graph, the green grid on your profile, matters less than people think. A lead knows that an employed developer mostly codes in private repositories. Do not try to fill it artificially.
When your code is private
Most experienced developers have an almost empty GitHub: their work belongs to their employer and lives in private repositories, sometimes on GitLab or Bitbucket. This is not a handicap, provided you handle it properly.
Several options:
- do not include a link if the profile shows nothing. The resume must then carry the proof on its own, through precise experience with figures;
- show private contributions in your profile graph, a settings option 🔗 that displays your activity without revealing the code;
- publish a small representative project, built in your own time, that reflects the practices of your job (tests, continuous integration, architecture) without borrowing anything from your employer’s code;
- offer in the interview to discuss a project in detail, with a diagram, instead of showing the code.
Never send code belonging to a current or former employer, even anonymised. A recruiter would see it as a lack of judgement about confidentiality.
Where to put the link on your resume
The GitHub link goes in the header, next to LinkedIn and your contact details. A few practical rules:
- write a short, readable URL, such as github.com/your-name, rather than a link shortened by a third-party service;
- make it clickable in the PDF, as many recruiters read resumes on screen;
- add direct links to repositories in the projects section if you mention one in particular;
- check the link just before sending, especially if you have renamed your account.
The resume and the profile must echo each other. If you mention a personal project in the projects section, it should be pinned; if you list a technology in your skills, at least one visible repository should use it. The front-end developer resume template shows how an open source contribution fits in one line, with a verifiable result. For presenting your technologies, see our article on the skills section of a developer resume, and if you are coming out of a short programme, the one on the resume after a bootcamp.
A link is only valuable if it is clickable and the rest of the document is readable. The TechCV editor keeps links active in the PDF and produces a layout that recruitment software can read, so that your GitHub link actually reaches the lead. You can update your resume with your freshly cleaned-up profile.
Frequently asked questions
Can an empty GitHub hurt my application?
An empty profile is not a penalty in itself, especially for an employed developer whose code is private. What hurts is a link that promises something and shows nothing. In that case, it is better not to include a link and to let the resume carry the proof.
Do I need a GitHub for a junior developer role?
It is not mandatory, but it is strongly recommended when you have little professional experience. Two carefully maintained repositories, with a clear README and tests, partly make up for the experience you do not yet have.
Are GitLab or a personal portfolio acceptable too?
Yes. The recruiter is looking for proof, not a specific platform. A public GitLab profile or a portfolio that links to the code plays the same role, with the same requirements for readability and a README.
How long does a lead spend on a GitHub profile?
Rarely more than a few minutes. That is why pinned repositories, READMEs and the first visible commits matter far more than the total volume of code.