Researchers at Carnegie Mellon, Socket and NC State scanned every public GitHub event from July 2019 to December 2024 — a dataset covering 63.9 million users and 326 million stars — and identified roughly 6 million suspected fake stars given by about 301,000 accounts to 18,617 repositories (arXiv:2412.13459). Their other finding matters more to you than the headline one: the bought stars lifted real attention for under two months, and then the effect turned negative. That is the shape of every cheap proof signal right now. If a number on your profile can be manufactured, it has already stopped meaning anything — and what survives is something a stranger actually used.
Key takeaways
- Stars and badges have been measured and found wanting: 6 million suspected fake stars, and profile badges with negligible correlation to anything but follower count.
- More than 230 new repositories are created every minute. A repo is not scarce, so its existence carries no signal.
- 82% of GitHub contributions happen in private repositories — so what you publish is a deliberate choice, not a record of your work. Choose it like one.
- Three quick throwaway builds, then one deep thing that strangers use. Five tutorial clones and a green contribution graph are not a substitute.
The cheap signals got measured, and they failed
Stars are the obvious casualty. The fake-star study found most campaigns were promoting short-lived malware repositories dressed up as pirated software or crypto bots, and that fake-star activity surged from 2024 onward. Whatever a star meant in 2018, it is now a number with a market attached to it.
Badges went the same way, and there is research on that too. Calefato, Quaranta and Lanubile tracked 6,022 GitHub developers across 51 organisations for twelve months and published the results in Information and Software Technology (arXiv:2303.14702). By December 2022, 82.65% of those developers displayed at least one personal badge. Only one badge — Starstruck, which is awarded for follower count — showed a large correlation with anything, and what it correlated with was follower count. The rest showed negligible or small effects. The survey respondents in the same study described the badges as unreliable cues that failed to capture experience, and an increasing share of developers were simply switching them off.
None of this means your GitHub is worthless. It means the parts of it that can be accumulated without doing the work have been priced at zero by anyone who evaluates candidates for a living.
What you publish is a choice, not a record
Two numbers from GitHub’s own reporting change how you should think about your profile. The first: developers created more than 230 new repositories every minute in 2025, with over 36 million new developers joining in a single year (Octoverse 2025). The second, from the 2024 report: more than 82% of GitHub contributions are made to private repositories, across more than 181 million of them.
Put those together and the professional norm becomes obvious. Most real engineering is invisible on public GitHub. A public profile is therefore not an audit trail of what someone has done — it is a curated shelf of what they chose to show. Students are the only group who treat it as a diary, which is why the advice to “maintain your GitHub profile” produces contribution-graph theatre: daily commits to nothing in particular, five repositories from five tutorials, and a README template that says the same thing as everyone else’s.
A stranger using it is the part that cannot be faked
Here is the asymmetry worth understanding. Source code, a README, an architecture diagram and a tidy commit history can all be produced in an afternoon with a language model. A thing that is running, that someone you have never met has used, and that broke in a way you had to fix, cannot — because the evidence is not the artefact, it is the sequence of decisions you made when reality disagreed with your plan.
That is also why a deployed link earns its place at the top of the README. Keeping something online forces you through configuration, secrets handling, input you did not anticipate, and errors that only appear under someone else’s conditions. Every one of those becomes an answer when a founder asks “what went wrong with this?” — and that question, not the code listing, is where the interview actually happens. We made the employer-side version of this argument in the fix runs 2.5 minutes, and the student-side version in six minutes of video is now your cheapest proof.
One honest caveat about open source, because it is oversold to second-years: a merged pull request into a project people depend on is real proof, and worth pursuing — that is the case in your first merged PR is the way in. But a documentation typo fixed in a repository nobody runs is not the same artefact, and the time cost per unit of signal is high. If you have one semester, ship your own small thing and get users for it.
The sequence: three throwaways, then one deep build
- Weeks 1–6: three throwaway builds, in three different areas. A web tool, something with data, something that talks to a device or an API. One week each, finished and deployed, deliberately shallow. The point is to find out what you want to go deep on, not to impress anyone. Do not list these as portfolio projects.
- Week 7: pick one, and write down who it is for. One sentence naming a specific person with a specific annoyance — your hostel’s mess committee, a professor’s lab, the juniors in your club. A project with a named user is a different project.
- Weeks 8–12: build the smallest version that solves it, and put it online. A real domain, real error handling, real configuration. Not a video, not a screenshot. If it is not reachable by URL, it is not shipped.
- Week 13: get ten people to use it who are not your friends. Post it where those people already are. Ten strangers will surface more than ten thousand stars, because they will use it wrong.
- Weeks 14–16: fix what they broke, in public. Issues, commits, a short changelog. This is the part nobody fakes, and the part you will be asked about.
- Write the README for a stranger with twenty minutes. What it does, the live link, one screenshot, how to run it, and a short section on the decision you are least sure about. That last section is the single strongest paragraph on most student profiles, and almost nobody writes it.
- Pin four repositories and nothing else. The deep one first. Archive or unpin the tutorial clones — they do not add, they dilute.
- Be able to explain every decision in it. Why that database, why that approach, what you would change now. If you cannot, it is not proof of anything, whoever wrote it.
Why this is the version that travels
A US startup hiring a remote intern from an Indian campus cannot check your college’s reputation, cannot call a mutual contact, and is not going to read a transcript. What crosses the distance intact is a link that works when they click it and a person who can explain what is behind it. That is the whole of the trust problem, and it is the reason a single deployed project with ten real users outperforms a profile with fifty repositories.
Tierones matches students from IITs, NITs and IIITs with startups that hire on proof of work — commits, ratings, shipped projects and a code walkthrough instead of a CV. It is free while the network grows. If you want the profile-level version of this, we wrote it up in your GitHub gets minutes, and the wider picture for students starting out is at tierones.io/students.
FAQ
How many projects do I need to get an internship?
One that works and that people other than you have used, plus enough smaller work to show you finish things. Volume stopped being a signal — Octoverse 2025 counted more than 230 new repositories created every minute, so the existence of a repo proves nothing. A founder with twenty minutes wants one thing they can open, use, and ask you questions about.
Do GitHub stars matter for getting hired?
Much less than students think, and it is now documented. Researchers found around 6 million suspected fake stars across 18,617 repositories, and a study of 6,022 developers found GitHub’s profile badges correlated with nothing much beyond follower count. Anyone evaluating you seriously knows this, so they read what the code does rather than the counter above it.
Is a deployed demo better than a GitHub repository?
You want both, but the live link is the one that cannot be assembled in an afternoon. Keeping something running means handling configuration, errors and other people’s unexpected input, and it produces the thing no repository has: a real user who did something you did not plan for. Put the link at the top of the README.
Building the one deep thing this semester? Create your profile with your .ac.in email and your GitHub, and let the work speak for you. Questions go to careers@tierones.io.