We read a lot of GitHub profiles. Not skimmed — read: cloned, checked the commit log, opened the files. After a few hundred, the same four patterns show up again and again, and every one of them costs the candidate an interview they might have earned. None of them is dishonest on purpose. All of them are avoidable in an afternoon.
Pattern 1: the pinned fork
You forked a well-known project — a classmate's, a YouTube tutorial's, a popular open-source repo — and pinned it to your profile under "Featured". The fork has your name on it. It also has zero commits by you.
Reviewers see this in about four seconds. Every fork on GitHub says "forked from" under the title, and the commit history shows exactly who wrote what. When the top of a profile is three forks with no commits, the reviewer's honest conclusion is: this person has not built anything yet and is hoping I will not check.
What to do instead: unpin the forks. If you contributed to a project — even a small fix — link the pull request itself, not the fork. A merged PR with your commits, review comments, and a maintainer's approval is one of the strongest signals a fresher can show. A fork with nothing in it is one of the weakest.
Pattern 2: the drag-and-drop upload
The repo has one commit called "Initial commit" or "Add files via upload", containing a finished project. Twelve files, 4,000 lines, uploaded through the browser on one afternoon.
This is what a project looks like when it was built somewhere else — a friend's laptop, a college lab machine, a downloaded template — and copied in at the end. Maybe you really did build it. But there is nothing in the repo that proves it, and a reviewer cannot tell your work from a download.
What to do instead: build in the repo from day one. git init before the first line of code. Commit every time something works. Twenty small commits over three weeks are worth more than a perfect upload, because they are the record of someone thinking.
Pattern 3: the identical copy
Search engines index GitHub too. When a project's files match another repository byte for byte — same filenames, same typos in the README, same commented-out line 47 — a reviewer who cares will find the original in a minute. We have seen "plagiarism detection" projects that were themselves copied without a single change. That one is hard to come back from.
What to do instead: if you learned from someone's code, say so in the README and link it. Then change something that matters: add a feature, fix the thing that annoyed you, swap the storage layer. Now the diff between the original and yours is the proof of what you can do, and you have an honest story to tell.
Pattern 4: the coursework dump
Fifteen repos named lab3, assignment_final_v2, DBMS-mini-project, each with a .docx and some code that has never run outside a lab. The profile looks busy. It contains nothing a stranger could open and use.
Coursework is not a crime, but it is not evidence either. Every other student in your batch has the same fifteen repos, and reviewers know it.
What to do instead: archive the lab repos (Settings → Archive) so they drop out of the way, and put one real thing at the top — a deployed app, a tool you use yourself, a bot that runs every day. One finished project beats fifteen started ones. If you need an idea, these seven were chosen because each can be finished in two weeks.
What reviewers actually look at, in order
- The pinned section. Six slots. Are these things you built, and do they run?
- The commit log of the best one. Steady commits over time, in your name, with messages that explain decisions. This is the part that is very hard to fake.
- The README. Does it say what the project is, who it is for, and how to run it — in the first ten lines? Here is how to write one.
- A live link. A URL a stranger can open is worth more than a paragraph of description.
- Whether you can talk about it. That is what the interview is for.
Notice what is not on the list: the number of repositories, the contribution graph, the follower count. Reviewers stopped trusting green squares when people started writing bots to fill them in.
How Iber checks this
On Iber, a build has to come from a repository under your own GitHub account — we check ownership at the source. A fork is labelled as a fork, so a reviewer never mistakes one for your work. What we deliberately do not do is count your commits or measure your streak. A weekend project you actually built passes; a popular repo you forked and never touched does not, no matter how many stars it has.
After that, the AI interview asks about the decisions inside the code. If you wrote it, those are easy questions.
The afternoon fix
- Unpin every fork with no commits by you.
- Archive coursework and tutorial repos.
- Pick your one best project. Deploy it if it is not deployed.
- Rewrite its README so a stranger understands it in ten lines.
- Record a two-minute demo and put the link at the top.
That is a few hours of work, and it changes what a reviewer sees from "hasn't built anything" to "built one real thing and can show it". That is the whole gap.