What a Recruiter Actually Looks At on Your GitHub (It Is Not the Number of Repos)

Quick Answer

They look for one repository that is clearly yours, has a README explaining what it does, and a commit history showing it was built over time. Thirty tutorial forks with no descriptions is worse than three real projects, because it makes the real ones harder to find.

What happens in the first forty seconds

Assume the person opening your profile is busy, is not going to hunt, and has several other candidates open in other tabs. In roughly this order they will: glance at your pinned repositories, open the one with the most promising name, look for a README, scroll it briefly, and — if still interested — check the commit history.

Every one of those steps is a place to lose them. A profile with no pinned repositories means they see your most recently pushed work instead, which is often a half-finished experiment. A repository with no README means they are looking at a file tree and guessing. A commit history with one commit called "final" tells them the code arrived from somewhere else.

None of this is about writing more code. It is about making the code you already wrote legible to someone who has never seen it.

The README is the whole thing

If you fix one item, fix this. A README that answers four questions puts you ahead of most student profiles:

• What does it do? One sentence, plain language, first line. Not "a MERN stack application" — say what it is for.
• How do I run it? The actual commands, in order. If a reader cannot start it in three steps, most will not try.
• What does it look like? One screenshot or a short GIF. This single item does more than any paragraph.
• What was hard? A short section on the interesting problem and how you solved it.

That last one is optional for the project and essential for you. It is the part a technical interviewer reads and then asks you about, which means you have quietly chosen the topic of your own interview. It is the same material you need for explaining your project verbally.

Keep it short. A README that runs for three screens before saying what the project does is as bad as no README.

Commit history: the part students forget is public

A reader can see every commit, its message, its date and its size. This is the most honest signal on the profile, and students rarely think about it.

What reads badly: a single enormous commit called "project" or "final", six commits all made on the same evening, or messages that are all "update" and "changes". None of these prove anything dishonest, but they remove the evidence that you built it incrementally.

What reads well is ordinary and undramatic:

$ git log --oneline
9f2c1ab Handle empty search results
4d81e07 Add pagination to results page
1b60f3e Fix crash when API returns null
8c22d90 Add search endpoint
3a7f114 Initial project setup

Each message says what changed. You can see the project growing, and you can see bugs being found and fixed — which is what real development looks like. Aim for messages in the imperative: "Add pagination", not "added pagination" or "pagination stuff".

Start committing this way now rather than trying to reconstruct it later. Rewriting history to fake a timeline is both obvious and pointless.

Check that you have not committed a secret

This is the one item on the list that can cause real damage rather than just a weak impression. API keys, database passwords and service account files get committed constantly, usually inside a config file that was never meant to be shared.

Use a .gitignore from the start:

node_modules/
.env
*.log

You can confirm a rule is doing its job:

$ git check-ignore -v .env
.gitignore:2:.env	.env

That output names the file and line of the rule that excluded it. If the command prints nothing, the file is not ignored.

Two things people get wrong here. First, adding a file to .gitignore does nothing if the file is already tracked — you also need git rm --cached .env to stop tracking it. Second, and more important: removing a secret in a later commit does not remove it from history. Anyone can read the earlier commit. If you have ever pushed a real key, treat it as compromised and rotate it, rather than assuming a deletion fixed it.

Cleaning up the profile itself

Small things, quick to fix, and they compound:

• Pin three to six repositories. This is the highest-leverage setting on the site. It replaces "whatever I pushed last" with "what I want you to see".
• Write a one-line description on every pinned repo. The grey text under the name is often the only thing read.
• Delete or archive dead tutorial clones. Twelve repositories named after a course you followed dilute the three that are yours. Archiving keeps them without cluttering the profile.
• Add topics. Two or three tags per repository, so the stack is visible without opening the code.
• Set a real name and a one-line bio. An empty profile with an avatar placeholder reads as abandoned.

A profile README — a repository named after your username — is a nice extra, but it matters much less than the four items above. Do those first.

If you have nothing worth pinning yet

Then the problem is not the profile, and no amount of formatting will fix it. You need two or three projects that are genuinely yours and that do something a stranger can understand in one sentence.

Depth beats count. Three projects you can explain in detail is a strong profile for a fresher; fifteen shallow ones is not, because the reader assumes the average rather than the best. Pick problems where something is actually difficult — handling bad input, preventing two users from clashing, making something fast that was slow — because those are the parts worth writing about in the README and talking about in the interview.

If you want starting points that already have a real hard part built in, our projects catalogue is organised that way, and the final year project guide covers how to choose one you can finish.

Frequently Asked Questions