GitHub
Your GitHub Probably Has These 5 Problems
The five things reviewers notice on a student GitHub profile within thirty seconds, and how long each one takes to fix.
Your GitHub gets judged whether or not you intend it to be part of your portfolio. For most junior applications it is the first thing a technical reviewer opens, and they are answering three questions in about two minutes: does this person write code regularly, can they finish something, and can they explain what they built.
Here are the five things that most reliably get in the way of those answers.
1. Nothing is pinned, so GitHub is choosing for you
This is the most consequential problem on the list and it takes ten minutes to fix.
If you have not pinned repositories, your profile shows your most recently updated ones. That is almost never your best work — it is whatever you touched last, which for most students is a half-finished experiment or a coursework repository from a module they did not enjoy.
Pin up to six. Pin the ones you want judged. Four excellent repositories beat six uneven ones, so do not feel obliged to fill the slots.
Fix time: 10 minutes. It is the best return on effort available to you today.
2. Repository names that mean nothing
assignment3, test2, project-final, untitled-1, cs2043.
A reviewer scanning your profile is reading names first. A name that describes the thing — library-lending-system, recipe-cost-calculator, society-events — does work that no amount of code quality can do, because it happens before anyone opens anything.
Renaming is safe: GitHub redirects the old URL, so nothing you have linked elsewhere breaks. While you are there, add the one-line description field and a couple of topic tags. The description shows in search results and on your profile grid, and an empty one looks unfinished.
Fix time: 20 minutes for a whole profile.
3. Pinned repositories with no README
An undocumented project cannot be assessed, so it counts for nothing. A pinned repository with an empty README is worse than an unpinned one, because you have explicitly drawn attention to something a reviewer cannot evaluate.
The default README your framework generated counts as empty for this purpose. If your project's README explains how to run npm run dev and nothing else, a reviewer learns that you used Next.js and stops.
The structure that works answers questions in the order a reviewer has them: what is this, can I see it working, what is it built with, how does it work, can I run it, what did you learn. Two sections do most of the work — the problem, written as a person having a bad time, and one technical decision with the alternative you rejected.
Do one properly on your best project rather than eight badly. Use it as the model and work down.
Fix time: 30–45 minutes per repository. The README template has the full structure.
4. Secrets in your commit history
This one is not cosmetic. It is the difference between a reviewer thinking "junior" and thinking "risk".
Search your repositories for .env, api_key, apiKey, password, secret and token. 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 immediately. Assume it is compromised. This matters more than the cleanup.
- Remove the file from the working tree and add it to
.gitignore. - Add an
.env.examplewith the variable names and placeholder values, so someone can see what configuration is required. - If you want the history clean, rewrite it with
git filter-repo— but rotate the key first regardless.
While you are here: check that node_modules, __pycache__, .venv, dist and your editor's folder are not committed either. They are not a security problem, but a repository with 40,000 files of dependencies in it is a signal about how carefully you work.
Fix time: 30 minutes to audit, longer if you find something.
5. A profile that says nothing about you
Most student profiles have the default identicon avatar, no bio, no location, an empty website field, and no profile README.
The profile README is the highest-value part. Create 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:
- What you build, in the first line
- What you are currently learning, in two or three lines
- How to reach you
Skip the animated banner, the visitor counter and the trophy widget. They add nothing and they push the actual information below the fold.
Then fill in the three profile fields that take two minutes: bio, location, and the website field pointing at your portfolio — or your CV, if you do not have a site yet. Use a real photograph as your avatar; the default identicon reads as an abandoned account.
Fix time: 30 minutes.
What is not a problem
Your contribution graph. The green squares are the most over-thought thing on GitHub. Nobody rejects a candidate for a quiet March, and streak-padding commits are obvious to anyone who looks at the diffs. Consistent, readable commits on two or three real projects matter far more than an unbroken streak.
Having few repositories. Four good ones is a perfectly respectable profile. Thirty mediocre ones is not better.
Stars. Nobody expects a student project to have stars. Their absence is not evidence of anything.
Not having contributed to open source. It is a nice-to-have, not a requirement for junior roles. If you want to, documentation fixes and issues labelled "good first issue" are the sensible entry point.
The order to do this in
All five together are about two hours, and they are worth roughly a week of new feature work:
- Pin your best repositories (10 min)
- Write the profile README and fill in the profile fields (30 min)
- Rename repositories and add descriptions (20 min)
- Audit for secrets (30 min)
- Write one proper README on your best project (45 min)
Then archive the noise. Settings → General → Archive keeps the code and marks it read-only, which is honest and tidy at the same time.
The full four-pass cleanup, including the workflow signals that read as professional habits, is in the GitHub profile guide. The free toolkit has it as a printable checklist.
Want the complete 14-day system?
Developer Portfolio Builder takes you from “I need a portfolio” to application-ready in 14 days: seven modules, 30 project briefs, every template, and a scorecard to check your work.
See what’s included