Somewhere between "we received your application" and "we would like to schedule a call", a human opens your GitHub. They spend about thirty seconds there. This post is about winning those thirty seconds, in two weeks, without pretending you have five years of experience you do not have.
I am writing this for freshers and early-career developers in India specifically, because the advice you usually get ("contribute to open source!") skips the part where nobody tells you what a reviewer is actually looking at.
What a reviewer sees in 30 seconds
In order:
- Your profile picture and bio. Blank avatar plus no bio reads as "abandoned account".
- Pinned repositories. If you have not pinned anything, they see your six most recently touched repos, which are usually forks and homework.
- The README of the first pinned repo. If it is the default "Getting Started with Create React App", they close the tab.
- The commit history of that repo. One commit called "final" is the end of the review.
- The contribution graph, last. A wall of green helps a little. Gaps hurt less than you think, as long as the work that is there is real.
Everything in the plan below exists to fix one of those five things.
Week 1: clean up what is already there
Day 1: profile
- Add a real photo and a one-line bio that says what you build and where you are. "Full-stack developer, Bengaluru. Building tools for small shops." is enough.
- Create a repository with the same name as your username. Its README becomes your profile page. Keep it short: what you are working on now, three links, how to reach you. No badges wall.
Day 2: pin three repos, hide the rest
Pick the three projects that best show your range, even if they are small. Pin them. Then archive or delete forks you never touched, tutorial follow-alongs, and anything named test, practice, or assignment-3. Archiving is reversible. A short, clean list beats a long, noisy one.
Day 3 and 4: rewrite three READMEs
Use this structure for each pinned repo:
# Project name
One sentence: what problem it solves and for whom.
## Live demo
Link. (If there is no link yet, that is Day 8.)
## What it does
Three bullets. Features, not technologies.
## How it works
One paragraph on the architecture and one decision you made and why.
## Run it locally
Exact commands. Test them on a fresh clone.
## What I would do differently
Two honest bullets.
A screenshot or a short GIF at the top doubles the time someone spends on the page. Record it with your OS screen recorder, convert with ffmpeg, done.
Day 5: fix the commit history going forward
You cannot rewrite the past cleanly, and you should not try. From today, write commit messages that describe a change and a reason: add retry to payment webhook (was dropping on timeout). Small commits, real messages. Reviewers scroll the log and this is what they read.
Day 6 and 7: rest, or handle the small things
Add a licence file. Add a .gitignore so node_modules is not in the repo. Remove the .env you committed in 2024. Rotate the key that was in it.
Week 2: create new proof
A clean profile of old work is a good profile. A clean profile with something built this week is a hireable one.
Day 8: deploy something
Take the best pinned project and put it on a free tier: Vercel or Netlify for frontend, Railway or Render for a backend, Supabase for a database. Put the link at the top of the README and in the repo's "About" field. Deployed or not deployed is a signal about finishing, and it costs nothing now.
Day 9 to 13: build one small real thing, in public
Pick a problem you actually have. A mess-bill splitter for your hostel. A tracker for when your college portal goes down. A WhatsApp order formatter for a family shop. Small scope, real user (you), five days.
Rules for these five days:
- Commit every day. Not for the graph, for the log. A five-day history with twelve meaningful commits is the most convincing thing on your profile.
- Open two or three issues for yourself and close them with commits. It shows you can break work down.
- Deploy on Day 12 even if it is ugly. Fix the ugliness on Day 13.
Day 14: record a demo and update the profile README
Record sixty seconds of you using the new project. One line on the problem, forty seconds of it working, one line on a technical detail you are proud of. Put the video in the README (a GIF or a link) and pin the repo in position one. Update your profile README to say "currently building: ..." with the link.
What this looks like from the other side
After two weeks, a reviewer opens your profile and sees: a face, a sentence, three pinned repos with real READMEs, one of them deployed and built this week with a commit log that reads like a diary of decisions, and a one-minute video. That is more than most candidates with three years of experience show. It took you two weeks and cost nothing.
Where I am coming from
I run a small hiring platform in Bengaluru called Iber, where builders post sixty-second demos of real projects and companies hire from the work instead of from a resume. Everything above is the checklist we see working for the people who get replies. You do not need Iber to do any of it. If you do want your work in front of companies once it is ready, Wave 1 is open at https://joiniber.com and it is free for builders. The longer version of this guide lives on our blog: https://joiniber.com/blog/github-profile-that-gets-you-hired
