GitHub lets you pin up to six items to your profile. Those items can be repositories or gists, but for most job searches, repositories matter more because they can show complete projects.

Your pinned repositories are the projects a reviewer is most likely to notice first. They should not be random. Do not simply pin the newest repository, the one with the most stars, or every project you have ever touched. Use the pinned area as a small portfolio: a short, intentional set of work that helps someone understand what you can build.

The goal is simple: make it easy for a hiring manager to find your best, most relevant work without digging through your whole account.

Your pinned repositories do not need to show everything you have ever built. They need to show the work that best supports the roles you want.

Each pinned repository should answer at least one useful question:

Two ideas matter most: relevance and quality.

Relevance means the project supports the roles you want. If you want backend roles, lead with backend services, APIs, infrastructure tools, data projects, or other work close to the target role. If you want frontend roles, show polished interfaces, component design, state management, accessibility, or deployed apps. If you want data or machine learning roles, show data handling, modeling, evaluation, and clear explanation.

Quality means the project is presented well enough for a stranger to understand. It does not have to be perfect. It should have a useful README, clear setup instructions when needed, and enough care that it does not look abandoned.

If you do not have six strong repositories, that is normal. Pin fewer. Three good projects are better than three good projects plus three weak ones.

Make a short list

Write down every public repository you might pin. Include projects that are already strong, projects that could become strong after a README cleanup, and projects you could finish in the next month or two.

Do not include private work you are not allowed to share. If your best professional work is private, use your resume to explain that work and use GitHub for public side projects, open source contributions, or learning projects that are safe to show.

Check each repository for relevance

Ask whether the repository supports the jobs you want. A project does not need to match perfectly, but it should help make your case.

For example, if you want backend roles, a small API with authentication, tests, and a database is more useful than a basic static website. If you want frontend roles, a polished UI with real state and responsive behavior is more useful than a half-finished script.

Check each repository for presentation

Ask whether a stranger can understand the repository in a minute. At minimum, a pinned repository should have:

A strong project with a weak README may still be worth pinning after you fix the README. A weak project with a polished README is still weak.

Choose quality over filling all six slots

You do not need to use all six pins. If you have four good repositories, pin four. Empty repositories, tutorial copies, assignment dumps, and stale experiments lower the overall impression.

A profile with a few solid projects looks better than a full grid padded with weak ones.

Put the strongest repository first

GitHub allows you to reorder pinned items. Put your best and most relevant project first. On most profile layouts, the first pin gets the most attention, especially from a busy reviewer.

The best first pin is not always the most popular repository. It is the project that best supports the role you want and is easiest to understand quickly.

Show range only after you show substance

Variety helps, but only when the projects are strong enough. Six shallow projects in different stacks do not show range; they show scattered effort.

For beginners, one or two well-finished projects matter more than a long list. For experienced engineers, pins can show public contributions, tools, technical writing, examples, or side projects that complement the resume.

Be honest about forks and tutorials

Forks and tutorial-based projects are not automatically bad. They become a problem when they are presented as if all the work is yours.

If you pin a fork, explain what you changed. If a project started from a tutorial, say what you added beyond the tutorial. A reviewer will notice if the README, commit history, or project structure belongs mostly to someone else.

Here is a simple filter for each repository.

This helps you avoid the two things that hurt most: unclear projects and projects that appear to claim someone else's work.

The right set of pins depends on where you are in your career.

For a beginner, a simple project can still be a good pin if it is finished, explained, and built with care. For a senior engineer, the same project may look too basic unless it serves a clear purpose.

Here is a pinned section that would raise doubts for a reviewer.

Weak:

The problem is not that every repository is worthless. The problem is that the pinned section makes the person look careless. A reviewer has to work too hard to find anything useful.

Better:

Why the better version works: Four clear projects beat six weak pins. Each repository shows something different: a tool, a backend service, a full-stack app, and evidence of how the person works. The strongest, most relevant project comes first.

Now the fork case.

Fork pinned without context:

Fork pinned with context:

Why this works: The second version is honest and specific. It tells the reviewer what belongs to the candidate. That can matter a lot for roles involving open source or developer tools.

Every item below picks the wrong repository for one of the six pinned slots, which is the only real estate a reviewer sees before deciding whether to keep scrolling.