A useful GitHub portfolio is curated, documented and legally safe. Pin a few relevant repositories, explain the architecture and your contribution, and never publish confidential employer or client code.
Curate before you publish.
Pin a small number of repositories that support the roles you want. Archive or unpin abandoned experiments if they create noise. Recruiters and engineers are more likely to inspect two clear projects than twenty unlabeled ones.
A README is part of the technical evidence.
For each repository, make the first screen answer four questions quickly: what problem it solves, what you personally built, how to run or inspect it, and which engineering decisions are worth discussing in an interview. Screenshots or a short architecture diagram can help when the result is visual or distributed.
- What problem the project solves
- Architecture or key design decisions
- How to run it
- Testing approach
- Known trade-offs or future work
- Your contribution if it was collaborative
Do not publish client or employer code.
Portfolio value never justifies breaching confidentiality or IP obligations. Use personal projects, open-source contributions or sanitized demonstrations.
Show engineering quality at the repository level.
A small project with tests, clear commits, sensible structure and documented decisions can be stronger evidence than a large copy-pasted application.
Employers often learn more from structure than from project size. Clear modules, meaningful names, dependency hygiene, error handling, tests and a repeatable build show how you work even when the repository is intentionally small.
Link GitHub only when it helps your target role.
A strong private production background does not become weak simply because there is no public code. Use projects, architecture explanations and interview evidence instead.
Pin repositories that support one professional story.
If you are targeting backend roles, a well-structured API, data pipeline or distributed-systems experiment is more useful than unrelated design demos. If you are a frontend engineer, show interaction quality, component structure, accessibility or performance thinking.
The goal is coherence between CV, target role and public evidence.
Commit history is part of the signal.
Perfect commit history is not required, but meaningful commits make a project easier to understand. Avoid uploading one giant final commit if the repository is meant to demonstrate how you work.
For collaborative projects, make your own contribution clear in the README or project description.
Tests and automation show engineering habits.
A small test suite, linting, CI workflow or deployment configuration can demonstrate that you think beyond “it runs on my machine”. Choose quality signals relevant to the role rather than adding tools only for decoration.
Security matters in public repositories.
Never commit API keys, passwords, private certificates or copied production configuration. Use environment examples and secret placeholders. Check repository history too: deleting a secret from the latest file does not remove it from old commits.
A portfolio can be private and still useful.
If your best work is confidential, prepare architecture diagrams, a sanitized technical case study or a small demonstration project. During interviews, explain production decisions without sharing proprietary code or data.
If your best work is confidential, describe the architecture, scale, responsibilities and trade-offs in your CV or Skills Passport without publishing the code. A public toy project is not automatically stronger evidence than a well-explained real-world responsibility.
Frequently asked questions
Do employers require GitHub for every developer role?
No. It can help, but professional production work is often private. A good CV and technical interview can provide equivalent or stronger evidence.
How many GitHub projects should I pin?
Usually 2–4 relevant projects are enough. Quality, clarity and relevance matter more than a large count.
Should I include unfinished projects?
Only when they still show useful engineering thinking and the README clearly explains the current state. A broken or unexplained repository can weaken the signal.