You have forty applications for a junior role and most of them include a GitHub link. Reading forty profiles properly is a day you do not have. Reading them badly — stars, follower count, the green contribution graph — is how you end up interviewing people who cannot code.
Here is a routine that takes about ten minutes per candidate and catches most of what matters. It is roughly what we do at Iber before anything is automated.
Minute 0–1: skip the profile page
The profile page is marketing: pinned repos the candidate chose, a README they wrote about themselves, a contribution graph that can be filled by a script. Note the pinned repositories and move on. Everything you need is inside them.
Minute 1–3: the fork and copy check
Open the most impressive-looking repository first.
- Does it say "forked from" under the title? If yes, click the candidate's commits. A fork with zero commits by them is not their project, however prominently it is pinned. This single check removes a surprising number of "featured" projects.
- Is the entire repo one commit? "Initial commit" or "Add files via upload" containing a finished app means it was built elsewhere — or downloaded. It may be genuine; there is simply no evidence either way.
- Does it look copied? Take a distinctive line from the README or a filename that is not standard and search GitHub for it. Byte-identical copies of tutorial and classmate projects are common, and a search takes thirty seconds.
Anything that fails here is not disqualifying by itself, but it means the repo cannot count as evidence. Move to the next one; if all of them fail, you have your answer.
Minute 3–6: read the commit log, not the code
For the best repository that passed, open the commit history. You are looking for the shape of work, not the quality of every line:
- Cadence. Dozens of commits over weeks read as someone building. Three commits in one evening read as someone assembling.
- Messages. "fix", "update", "final" tell you nothing. "Handle receipts photographed at an angle — group by y-coordinate" tells you the person was thinking.
- Authorship. Are the commits by this GitHub account? Team projects are fine, but you want to know which part was theirs. Note a question for later.
- Iteration. Look for a bug fixed after it was introduced, a refactor, a revert. That is what real work looks like. A repo with no mistakes in it usually did not have a human in it either.
Minute 6–8: does it run, and does the README match the code?
Open the live link if there is one. If there is not, that is a small mark against — deploying is free and it is the difference between a claim and a demo.
Then skim the README against the code. A README promising features you cannot find in the source is the most common form of inflation, and the easiest to catch. Also check for secrets committed in plain text — API keys in the repo are a real signal about habits, and worth a gentle question rather than an automatic rejection.
Minute 8–10: write down two questions
Do not decide yet. Write two specific questions from what you read, for example:
- "Your commit on the 14th switched from polling to a webhook — what broke with polling?"
- "The matching logic in
score.py— walk me through what happens when two candidates tie."
A builder answers these in thirty seconds and enjoys it. An uploader cannot answer them at all. These two questions are the highest-value part of the whole routine, because they convert a ten-minute read into a five-minute screen that is almost impossible to fake.
What to ignore
- Stars and followers. Bought, traded, or accumulated by one lucky tweet.
- The contribution graph. Trivially automated, and it counts commits to forks.
- Repository count. Fifteen lab assignments are not fifteen projects.
- Certificates linked from the README. They prove attendance.
- The university. The point of reading the code was to stop using that as a proxy.
Where this runs out
Ten minutes per candidate is fine for forty applications. It does not scale to four hundred, it depends on the reviewer's own judgement, and it stops at "the code looks real" — it does not tell you whether the candidate can explain it under questioning or modify it live.
That is the part we built Iber to do. Repositories are checked for ownership at the source and forks are labelled as forks. Every builder records a two-minute demo of the project and sits a structured AI interview about their own code, with follow-ups that react to their answers; some roles add a live change on their own repository. You get a ranked shortlist of people who built real things and can talk about them — and the two questions above, already asked and answered, before you spend a minute of your own.
Your first hire is free. Bring the role; we will bring the builders.