Your GitHub is a portfolio · Mohammed Ibrahim

The first thing a senior engineer does when they meet your name is look at your GitHub. Not your LinkedIn. Not your blog. Your GitHub. They don't read your code in detail; they take 30 seconds, glance at your pinned repos, look at recent activity, and form an opinion.

Most engineers' GitHub profiles are accidents — leftover personal projects from years ago, half-finished tutorials, a fork of dotfiles. The ones whose GitHub helps them have done a few specific things on purpose.

What a GitHub-glancing reviewer notices#

In 30 seconds, here's what they form an opinion on:

Profile photo and bio. Is this a real engineer or a half-empty profile?
Pinned repos. What do these say about you?
Recent contributions graph. Are you active? Doesn't have to be daily; "this person ships things" is the signal.
The README of pinned repos. Skim, see if it explains what the project does.
Stars and forks (on the pinned repos). Bonus, not required.

That's the bar. Five things. Hit each.

Step 1: profile-level basics#

Go to github.com/yourusername. Three things to fix today:

A photo. Same photo as LinkedIn. Recognizability beats artistic merit.
A bio. Short. "Senior backend engineer. Postgres, Python, observability." Or whatever you actually are. Not "code monkey" or empty.
A profile README (the magic username/username repo). Don't make it a wall of text — make it a 6-line "what I'm working on, what I write about, where to find me" snippet.

Profile READMEs are GitHub's resume slot. Use it.

Step 2: pinned repos (max 6)#

This is the most important real estate. You have six pinned slots; they should be the six things that best represent what kind of engineer you are.

Decision tree:

Have any open-source contributions you're proud of? Pin those.
Have personal projects that work? Pin them.
Have nothing impressive? Build something. The "I have no GitHub" problem is solved by writing one good thing.

Anti-patterns:

❌ A pinned tutorial fork (tells me you completed a tutorial; not a portfolio piece).
❌ A pinned dotfiles (everyone has these; not a differentiator).
❌ A pinned half-finished project with no README and a "TODO" everywhere.
❌ Pinning all six slots with throwaway scripts.

Patterns that work:

✅ A pinned "small but polished" tool — does one thing well, README explains why it exists, has a release.
✅ A pinned contribution to a known OSS project — link to the merged PR in the README.
✅ A pinned writeup of a project — your blog source, or a notes-on-X repo summarizing your thinking.

Step 3: a project worth pinning#

If you're starting from "I have nothing to pin," here's how to fix it in a weekend:

Pick a small problem you actually have. A CLI for something annoying, a script that solves your specific need, a dashboard that aggregates data you care about.
Build it. Make it work. No half-features.
Write a README that opens with: "What this does. Why it exists. How to install. How to use." Three paragraphs, with examples.
Add a license (MIT or Apache 2 by default).
Tag a release (v0.1.0). Even a one-person project benefits from versioning.

That's a portfolio piece. Pinned, it's a signal that you ship.

Step 4: the README that does the work#

Most repo READMEs are bad in predictable ways:

They start with build status badges and tooling logos. (Skip that section. Your value isn't your CI provider.)
They jump straight to "Installation" without explaining what the project does.
They don't show usage. No example invocation, no example output.

A README that works:

# fastpgvector

Drop-in pgvector replacement that adds keyword + vector hybrid search and
auto-tunes index params for your workload.

## Why?

I had a 50M-row pgvector setup that was ~120ms p95. After porting to
fastpgvector with auto-tuning, it dropped to 18ms p95.

## Install

    pip install fastpgvector

## Use

    from fastpgvector import HybridIndex
    idx = HybridIndex.create("articles", text_col="body", embedding_col="embedding")
    results = idx.search("what does X do?", limit=10)

## Why this exists vs alternatives

- pgvector: great, but no built-in hybrid mode
- Qdrant: requires a separate service
- This: Postgres-native, hybrid out of the box

## Status

Beta. Used in production at one company (mine).

That's a README. Three paragraphs explain. One paragraph each on install, use, alternatives. A status note that's honest.

Step 5: contribution patterns#

The contribution graph isn't required to be lit up daily. But long stretches of zero activity look... uninspired. Aim for "I shipped something publicly each month" as the bar.

Easy ways to keep activity respectable:

Push small commits to your blog repo when you publish a post.
Make typo-fix PRs to OSS projects you use.
Use GitHub for personal scripts, configs, dotfiles (some private, some public).
Document interesting bugs in issues on your own repos.

Avoid the "GitHub farming" trap (commits whose only purpose is greening the calendar). Reviewers can spot it. Real shipping > grass farming.

Step 6: the things to clean up#

A 30-minute pass once a year:

Delete or archive old, broken, embarrassing repos. Old shouldn't have to mean public.
Make the abandoned tutorial follow-alongs private. Or delete them.
Pin meaningful things; unpin the half-finished things.
Update bio and profile README if your story has changed.

GitHub's "archive" is also useful — keeps the history but signals "not actively maintained."

Stars are not the metric#

Star counts are vanity. A thoughtful 10-star tool that's used in three production contexts is worth more than a 5K-star "Best of Github" list of resources.

Hiring managers know this. Don't optimize for stars. Optimize for "this person ships things that work."

Beyond the basics: discoverability#

Once your profile is intentional, GitHub becomes a discovery surface:

Sponsor unlikely OSS authors. $5/month sponsorships of small library authors put you in their network and signal community-mindedness.
Attend issues, not just PRs. Helping someone debug a problem in a project's issues earns more trust than drive-by PRs.
Open thoughtful PRs to known projects. A good PR (clear description, tests, fits style) builds reputation in the project's community.

These are 5-year arcs. Doing them consistently makes you visible in the way that earns invitations.

The minimum viable profile#

If you want to do exactly the minimum:

Add photo + bio (5 minutes).
Pin 3-6 repos that you're not embarrassed by (15 minutes; takes longer if you need to write READMEs).
Make sure each pinned repo has a working README (variable; budget 30 minutes per).
Push something this week. (Anything. A README change. A typo fix in a project you use.)

Total: an afternoon. Outcome: a GitHub profile that doesn't subtract from your story.

That's the floor. Above the floor, sustained shipping over years compounds.