Make your GitHub profile do some of your job search for you: a 30-minute checklist

Sahul Rajhansa — Mon, 26 Oct 2026 03:21:43 +0000

From PPLIED (Sahul Rajhansa, founder). Drafted with AI assistance; details at the end.

If your resume links to your GitHub profile, someone will eventually click it, usually after reading only a line or two about you. What they see in the first screen decides whether they dig deeper or close the tab.

Most developer profiles weren't built for that visitor. They're full of forks, tutorial repos, a 2019 hackathon project with no README, and a contribution graph that's empty because the real work happens in private company repos.

The good news: you don't need a new side project to fix this. You need a cleanup pass. Here's one you can do in about 30 minutes, with links to GitHub's own docs for every feature mentioned.

The goal: a one-minute story

Before touching anything, write down (for yourself) the answer to one question:

What kind of role am I applying for, and which 3–6 pieces of my work best prove I can do it?

Everything below serves that answer. If you're applying for backend roles, a polished React portfolio site shouldn't be the first thing on your profile. If you're moving into data engineering, your pipeline project should be front and center, even if your most-starred repo is something else.

Step 1 (5 min): Add a profile README

GitHub shows a README at the top of your profile if you create a public repository with exactly the same name as your username containing a non-empty README.md at its root (GitHub Docs: Managing your profile README).

Keep it short. A visitor should be able to read it in about 20 seconds. A structure that works:

# Hi, I'm Alex 👋

Backend engineer (Java, Spring Boot, PostgreSQL) focused on APIs that stay fast under load.
Currently looking for: backend / platform roles, US remote or NYC.

**Start here:**
- [order-service](link): event-driven order API with Kafka, idempotent consumers, and load tests
- [pg-migration-toolkit](link): zero-downtime schema migration scripts + write-up
- [rate-limiter](link): token-bucket rate limiter, benchmarked against two alternatives

**Elsewhere:** [Blog](link) · [LinkedIn](link) · email in profile

(Alex and these repos are a made-up example. Swap in your own.)

What to skip: long badge walls, auto-generated stats cards that dominate the screen, and a list of 25 technologies you've touched once. A stack line that matches the jobs you want, plus 3 links, beats all of it.

If you don't want your README there, you can remove it: delete or empty the file, or make the repo private (same doc).

Step 2 (5 min): Pin the repos that match your target role

You can pin up to six repositories and gists combined to your profile, and drag them into any order (GitHub Docs: Pinning items to your profile). Without pins, visitors see "Popular repositories," which may not be what you'd choose.

Pick your pins with the role in mind:

Your strongest, most relevant project first. Order matters, since the top-left pin gets read first.
Variety in what each pin proves, not in languages. For example: one project shows system design, one shows testing discipline, one shows you can ship something people use.
Your own work over forks. A fork you contributed to meaningfully is fine. Say what you did in the description.
Fewer is OK. Three solid pins beat six where half are half-finished.

Also write a one-line description for each pinned repo (repo settings → "About"). "Todo app" tells a reader nothing. "Offline-first todo app with conflict-free sync (CRDTs), React + IndexedDB" tells them a lot.

Step 3 (10 min): Give each pinned repo a README a stranger can follow

This is where most of the value is. For each pinned repo, the README should answer, in this order:

What is it? One or two sentences, plus a screenshot or GIF if it has a UI.
Why is it interesting? The hard part: the trade-off you made, the bug you chased, the performance number you measured yourself (and how).
How do I run it? Copy-pasteable commands. If it needs secrets, show a .env.example.
What's the stack? One line.
What would you do next? Two or three bullets. This shows judgment, and it's a natural thing for an interviewer to ask about.

A minimal template:

# order-service

Event-driven order API that stays consistent when consumers crash mid-message.

![demo](docs/demo.gif)

## Why it's interesting
- Idempotent consumers using an outbox table, so duplicate Kafka deliveries don't double-charge
- Load-tested with k6; results and method in `docs/load-test.md`

## Run it
    docker compose up
    ./gradlew test

## Stack
Java 21 · Spring Boot · Kafka · PostgreSQL · Testcontainers

## Next
- Add dead-letter queue replay tooling
- Move to schema registry for event contracts

Two honesty rules: only include numbers you measured yourself, and say how you measured them. If someone asks in an interview, you'll be glad you did.

Step 4 (3 min): Make your real activity visible (if it's private)

If most of your commits go to private or internal repos at work, your contribution graph can look empty. GitHub lets you show anonymized activity from private repos: open your profile, click Contribution settings above the contribution calendar, and toggle Private contributions (GitHub Docs: Manage visibility settings for private contributions).

The details of private repos stay hidden. Check your employer's policies if you're unsure. And don't stress about the graph itself: a steady, real history is nice to have, but a green grid isn't a skill. Your pinned projects matter more.

Step 5 (5 min): Do a quick cleanup and safety pass

Archive or make private the repos you'd be uncomfortable explaining in an interview: abandoned experiments, old coursework you didn't write yourself, and anything with copied code you can't credit.
Search your public repos for secrets. Look for .env files, API keys and passwords in config. If you find a real credential, GitHub's guidance is that the first step is to revoke or rotate it. Deleting the file or rewriting history comes after (GitHub Docs: Removing sensitive data from a repository).
Add a license to projects you want others to reuse. Without one, default copyright law applies and others can't reuse your code (GitHub Docs: Licensing a repository). This matters less for a job search, but it signals that you know how open source works.
Fill in your profile basics: a real name or consistent handle, a photo or avatar, your location or "Remote (US)" if you're comfortable sharing it, and a link to your portfolio or LinkedIn.

Step 6 (2 min): Connect it to your applications

A great profile does nothing if nobody finds it.

Put the profile URL in your resume header, next to your email and LinkedIn.
In each resume project bullet, link the specific repo, not just your profile.
When an application form has a GitHub field, fill it in. It's a free chance to show your work instead of describing it.
Tailor your pins before a big application push. It takes two minutes to reorder them for "backend" vs "data" roles.

The 30-minute checklist

[ ] Wrote down the target role + 3–6 pieces of proof
[ ] Profile README: one-line pitch, what you're looking for, 3 "start here" links
[ ] Up to 6 pins, most relevant first, each with a one-line description
[ ] Every pinned repo has: what / why interesting / how to run / stack / next
[ ] Private contributions toggled on (if relevant and allowed)
[ ] Secrets checked, credentials rotated if any were exposed
[ ] Old or embarrassing repos archived or made private
[ ] Profile URL on your resume, specific repo links in project bullets

That's it. The profile doesn't need to be impressive to everyone. It needs to make it easy for one specific reader, a person hiring for the role you want, to say "let's talk."

What's the one thing on your profile you'd fix first? Tell us in the comments.

About PPLIED: This post is published by PPLIED, founded by Sahul Rajhansa. PPLIED is a free, hands-free, fully AI-powered job portal. You build one profile, usually by uploading your resume, and can add your GitHub, LeetCode or Kaggle usernames. Matching then looks at your skills, related skills, experience and developer signals, not one exact keyword. Recruiters reach out with contact requests, and you decide how to respond. If that sounds useful, you can create a free PPLIED profile. We don't promise jobs or interviews, and everything in the checklist above works with or without PPLIED.

AI disclosure: This article was drafted by an AI assistant for PPLIED and approved for publication by PPLIED's founder. GitHub features were checked against GitHub Docs (linked above) on Oct 25, 2026.

DEV Community: PPLIED