How to Make Your GitHub Profile Look Professional

What a reviewer is actually doing

A technical reviewer opening your GitHub is answering three questions, usually in under two minutes: does this person write code regularly, can they finish something, and can they explain what they built?

Note what is not on that list — repository count, streak length, star totals, and whether you use the trendiest framework. Optimise for the three questions that actually get asked.

Pass 1 — Your profile page

About 30 minutes, and it changes the first impression more than anything else here.

• Create a profile README. Make a repository named exactly the same as your username, add a README.md, and it renders at the top of your profile. Keep it to about 150 words.
• Say what you build in the first line. “Software engineering student at [university]. I build web applications in TypeScript and Python.” Skip the animated banner and the visitor counter.
• Fill in bio, location and website. The website field should point at your portfolio, or your CV if you do not have a site yet.
• Use a real photograph. The default identicon reads as an abandoned account.
• Pin up to six repositories. This is the single highest-leverage action available to you, because it decides what gets judged. Four excellent ones beat six uneven ones.
• Add a short “currently learning” list. It gives an interviewer an easy opening question.

Pass 2 — Remove the noise

Everything a reviewer can see that you would rather they did not.

• Archive abandoned repositories. Settings → General → Archive. It keeps the code and marks it read-only, which is honest and tidy at the same time.
• Delete forks you never contributed to. A wall of untouched forks makes real work harder to find.
• Rename meaningless repositories. cs2043-assignment-3 becomes library-lending-system. GitHub redirects the old URL, so nothing you have linked elsewhere breaks.
• Add a description and topics to every public repository. The description shows in search results and on your profile grid; an empty one looks unfinished.
• Check your history for secrets. This one is not cosmetic.
• Confirm your commits are attributed to your account. If they show a different name, your git config user.email does not match a verified email on your account.

On secrets: search your repositories for .env, api_key, password, secret and token — and check the history, not only the current state. Deleting a file does not remove it from previous commits, and a key committed six months ago is still readable by anyone who clones the repository.

If you find one, rotate the key first. Assume it is compromised. Then add the file to .gitignore, add an .env.example with placeholder values, and rewrite the history if you want it clean.

Pass 3 — Each pinned repository

Repeat for each one you pinned. Budget about an hour per project.

• The README opens with what the project does and who it is for — not the install steps
• There is a live link or a screenshot near the top
• The tech stack is listed explicitly
• Setup instructions actually work from a clean clone — test them in a fresh folder, this fails more often than people expect
• There is a .gitignore appropriate to the language: no node_modules, no __pycache__, no .venv, no IDE folders
• There is an .env.example if the project needs configuration
• There is a licence — MIT is a fine default for portfolio work
• The main branch builds and runs

Do one properly rather than eight badly. A single excellent README on a pinned repository changes more than eight mediocre ones, because a reviewer reads the first one and forms their view there. The README template has the full structure.

Pass 4 — Signals of a working developer

Optional, and each is visible evidence of professional habits. Pick one or two rather than all of them.

• Commit messages that describe the change. “Add rate limiting to the auth endpoint” rather than “fix”, “update”, “asdf”. A reviewer skimming your history should be able to follow the build.
• A pull request on at least one project. Even solo. Open one against your own main branch, write a description, merge it. It shows you know the workflow every team uses.
• Tests, however few. Five meaningful tests beat a coverage badge. Say what they cover in the README.
• CI running on push. Roughly fifteen lines of YAML, and it adds a green tick to every commit.
• Issues used on at least one project. It shows you can break work down, which is most of what junior engineering is.

Repository structure

A reviewer opening a repository is looking for the things they expect to be there. Missing them is a small signal that adds up.

Adding CI

Fifteen minutes for a disproportionate return. Create .github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci
      - run: npm run lint
      - run: npm test

Swap the setup step for your language — actions/setup-python, actions/setup-go, actions/setup-java — and the run steps for your commands. Add the status badge to your README afterwards.

About the green squares

The contribution graph is the most over-thought thing on GitHub. Nobody rejects a candidate for a quiet March, and streak-padding commits are obvious to anyone who opens the diffs.

What a reviewer takes from the graph is roughly “does this person write code with some regularity”. A scattered but genuine pattern answers that fine. Consistent, readable commits on two or three real projects matter far more.

What to fix first

The whole cleanup is about two hours and it is worth roughly a week of new feature work. Start with pinning.