{"title":"Pinned Repos Strategy","description":null,"content":"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.\n\nYour 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.\n\nThe goal is simple: make it easy for a hiring manager to find your best, most relevant work without digging through your whole account.\n\n---\n\n# Relevance and Quality Matter Most\n\nYour 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.\n\nEach pinned repository should answer at least one useful question:\n\n- Can this person finish a real project?\n- Can they write readable code?\n- Can they explain their work clearly?\n- Do they have experience with the stack or domain this role needs?\n- Is there enough substance here to discuss in an interview?\n\nTwo ideas matter most: relevance and quality.\n\nRelevance 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.\n\nQuality 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.\n\nIf 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.\n\n---\n\n# Choosing and Ordering Your Pins\n\n### Make a short list\n\nWrite 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.\n\nDo 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.\n\n### Check each repository for relevance\n\nAsk whether the repository supports the jobs you want. A project does not need to match perfectly, but it should help make your case.\n\nFor 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.\n\n### Check each repository for presentation\n\nAsk whether a stranger can understand the repository in a minute. At minimum, a pinned repository should have:\n\n- a clear project name\n- a README that explains what it does\n- the stack used\n- setup or demo instructions if relevant\n- screenshots, demo links, or examples when they help\n- enough commit history or project structure to show it is real work\n\nA 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.\n\n### Choose quality over filling all six slots\n\nYou 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.\n\nA profile with a few solid projects looks better than a full grid padded with weak ones.\n\n### Put the strongest repository first\n\nGitHub 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.\n\nThe 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.\n\n### Show range only after you show substance\n\nVariety helps, but only when the projects are strong enough. Six shallow projects in different stacks do not show range; they show scattered effort.\n\nFor 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.\n\n### Be honest about forks and tutorials\n\nForks and tutorial-based projects are not automatically bad. They become a problem when they are presented as if all the work is yours.\n\nIf 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.\n\nHere is a simple filter for each repository.\n\n\n```mermaid\nflowchart TD\n A[Candidate repository]:::start --> B{Relevant to
target roles?}:::q\n B -->|No| F[Do not pin]:::no\n B -->|Yes| C{Clear enough for
a stranger?}:::q\n C -->|No README,
unclear, unfinished| G[Fix first
or skip]:::mid\n C -->|Yes| D{Mostly your
own work?}:::q\n D -->|Yes| H[Good pin]:::yes\n D -->|Fork or tutorial| I[Pin only if you
explain your part]:::mid\n\n classDef start fill:#00ceff,stroke:#000,color:#000\n classDef q fill:#ffd43b,stroke:#000,color:#000\n classDef no fill:#ff8787,stroke:#000,color:#000\n classDef yes fill:#69db7c,stroke:#000,color:#000\n classDef mid fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThis helps you avoid the two things that hurt most: unclear projects and projects that appear to claim someone else's work.\n\n---\n\n# Variety and Depth by Level\n\nThe right set of pins depends on where you are in your career.\n\n\n| Level | What to prioritize | Why |\n|-------|--------------------|-----|\n| New grad or early-career | 2-3 solid projects with clear READMEs | Projects may be your main evidence that you can build beyond coursework. |\n| Career switcher or self-taught | Projects that show job-ready skills | Reviewers need evidence that your skills transfer into software work. |\n| Mid-level engineer | A strong main project plus a little range | Your work history shows depth; GitHub can add public examples of how you build and explain software. |\n| Senior engineer | Public contributions, tools, writing examples, or focused side projects | Your resume carries most of the evidence. Pins should add useful public context, not repeat beginner-level work. |\n\n\nFor 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.\n\n---\n\n# A Weak Set and a Better Set\n\nHere is a pinned section that would raise doubts for a reviewer.\n\n**Weak:**\n\n\n```javascript\nPinned:\nassignment-3 no README\ntodo-app-tutorial forked, original README unchanged\nhackathon-2021 last commit 3 years ago, no setup notes\ntest-repo empty\nmy-website placeholder only\ndata-structures code dumps with no explanations\n```\n\n\nThe 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.\n\n**Better:**\n\n\n```javascript\nPinned, in order:\n1. query-profiler CLI that finds slow SQL queries, with tests and examples\n2. url-shortener API with rate limiting, analytics, and clear setup notes\n3. expense-tracker full-stack app with auth, Postgres, and a live demo\n4. dev-notes small documented scripts and setup notes for daily work\n```\n\n\n**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.\n\nNow the fork case.\n\n**Fork pinned without context:**\n\n\n```javascript\nawesome-framework\nForked from original-author/awesome-framework.\nREADME is unchanged from the original project.\n```\n\n\n**Fork pinned with context:**\n\n\n```javascript\nawesome-framework\nREADME opens with:\n\"This fork adds Redis-backed caching to the query layer. My changes are in\nthe caching/ directory and were proposed upstream in PR #482.\"\n```\n\n\n**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.\n\n---\n\n# Pinning Mistakes to Avoid\n\nEvery 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.\n\n- **Pinning by recency.** The newest repository is not always the strongest. Choose based on relevance and quality.\n- **Pinning by stars alone.** Stars can help, but they do not matter much if the repository is unrelated, unclear, or mostly someone else's work.\n- **Filling all six slots with weak repositories.** You are allowed to pin fewer than six. Do that when the alternatives are empty or confusing.\n- **Hiding the best project.** Put the strongest, most relevant repository first. Do not make a reviewer hunt for it.\n- **Pinning unexplained forks.** A fork can be valuable, but only if the README explains your contribution.\n- **Showing the same project six times.** Six similar basic apps or class assignments make the profile feel narrow. Show depth first, then useful variety.\n- **Leaving pinned repositories stale.** If a pinned project is abandoned, broken, or no longer represents your work, unpin it or update it.","pageType":"job-search"}

Get Premium