How to evaluate a developer's GitHub as a non-technical founder
How to evaluate a developer's GitHub as a non-technical founder
To evaluate a developer's GitHub as a non-technical founder, ignore the green-square contribution graph and look at four things: their pinned repos (do the READMEs read like a human wrote them), their commit messages (do they explain why not just what), their pull requests to other people's projects (real collaboration or just commits to their own forks), and whether anything they built is actually deployed and reachable on the public internet. Those four signals separate working engineers from profile decorators in about ten minutes.
You don't need to read code to do this. You need to read context, and GitHub gives you more context than most founders realise.
Why the GitHub graph alone tells you almost nothing
The classic founder mistake is opening a candidate's GitHub, seeing a wall of green squares, and assuming the person ships. Green squares are easy to fake. A cron job that commits one updated README to a personal repo every day produces a perfect contribution streak with zero engineering value behind it.
We've seen "100-day streak" candidates whose entire activity log was auto-generated commits from a script. We've also seen senior engineers with mostly-grey graphs because their actual work lives in private company repos, which GitHub doesn't show by default.
The graph tells you someone has a GitHub habit. It doesn't tell you they can build your product. The four signals below do.
The four GitHub signals that actually matter
1. Pinned repos: are these real projects or portfolio theatre
Every GitHub profile lets the developer pin up to six repos. These are the ones they want you to see. Open each one and ask three questions:
- Does the README explain what the project does in the first paragraph, in plain language, like a human wrote it for another human?
- Are there installation instructions, screenshots, or a link to a live demo?
- Was the repo touched in the last 90 days, or has it been abandoned since 2022?
A strong pinned repo has a README that reads like a product page: what it is, who it's for, how to run it, what's left to do. A weak pinned repo has a one-line description, no demo link, and the most recent commit is "initial commit" from 18 months ago.
If three of their six pinned repos look like that, you're looking at a portfolio built for show.
2. Commit message hygiene: do they explain why
Open any active repo and click "commits." Scroll the list.
Strong commits look like this: "Fix race condition in Stripe webhook handler when subscription is cancelled mid-trial." That's specific, it names the system, and it tells you the why. The engineer was thinking about edge cases.
Weak commits look like this: "fix", "update", "wip", "changes", "asdf". That's someone treating git as save-to-cloud, not as a thinking tool.
The reason this matters for you, the founder, is that commit messages are the cheapest possible signal of how the person communicates under low stakes. If they can't be bothered to write a useful sentence when committing their own code, they will not write useful Slack updates, useful PR descriptions, or useful handoff notes when they wrap a project.
This is the same logic we wrote about in how to handle scope creep as a founder: the people who write things down protect you. The people who don't, cost you.
3. Pull requests to projects they don't own
Click the "Pull requests" tab on their profile, then filter for is:pr author:<username>. Now look at where the PRs went.
If 95% of their PRs are to repos they themselves own (so they're approving their own pull requests on their own forks), that's not collaboration. It's a workflow preference. It tells you nothing about how they work with a team.
If, on the other hand, you see merged PRs into projects they don't own (an open-source library, a former employer's tool, a friend's repo, a community project), read the PR conversation. Did they engage with reviewer feedback gracefully or defensively? Did they ship the fix in one round, or did it take six rounds of nitpicking? Did the maintainer thank them, or merge silently?
A single merged PR into a popular OSS project is worth more than 200 commits to a personal fork. It proves the person can read someone else's code, follow contribution guidelines, accept review, and ship.
4. Deployed live demos: does anything they built actually run
Scroll their profile for project links. Click them.
If the link 404s, the demo "needs a backend running locally," or the README points to a Vercel URL that returns "this project has been paused," the candidate has shipped code to GitHub but has not shipped product to a user. Those are two completely different skills.
If the link loads, you can interact with it, and you can find their name or handle attached to it, that's the highest-quality signal on their entire profile. Shipping to a real domain involves DNS, hosting, environment variables, a build pipeline, often a database, and the patience to debug all of it when things break at 2am. Every founder hiring an engineer needs that exact skill set.
For founder context on what shippable actually looks like, our notes in how to build a startup waitlist that converts walk through the minimum production stack a real launched project tends to have.
The "AI-generated repo" tell
Here is the 2026 wrinkle: anyone can claude code init or cursor compose a polished-looking repo in 90 minutes. Pretty README, sensible folder structure, even a passable test suite. The output looks like senior engineering.
It isn't, on its own, a red flag. Every engineer on Cadence uses Cursor, Claude Code, or Copilot daily, that is the baseline. The flag is when the repo is all the polish and none of the iteration. Specifically:
- A single massive initial commit with 8,000 lines of code, then nothing.
- README in perfect three-paragraph marketing voice, but no record of what the project evolved into.
- Tests that all pass and all test the happy path with no edge cases.
- File names and folder structures that match a popular AI-generated template (the
lib/,components/,app/skeleton that every Cursor-bootstrapped Next.js repo has).
The tell is the absence of struggle. Real engineering looks like 47 commits over three weeks, half of which are "fix typescript error in middleware" or "actually fix the typescript error this time." That mess is the evidence the person debugged real problems.
AI-generated portfolio repos look pristine because they never met a real user, a real bug, or a real constraint. Ask the candidate, on a call, to walk you through why a specific architectural choice in their repo was made. If they can't explain it past the first follow-up question, the repo wrote them, not the other way around.
Green / yellow / red flags at a glance
| Signal | Green flag | Yellow flag | Red flag |
|---|---|---|---|
| Pinned repos | 4+ active, real READMEs with screenshots, recent commits | Mix of polish and abandoned | All abandoned, "initial commit" only, generic READMEs |
| Commit messages | Specific, name the system, explain why | Mostly fine, occasional "wip" | "fix", "update", "asdf" dominate |
| Pull requests | Merged PRs into repos they don't own, civil PR threads | All PRs to own repos, but real discussion in issues | No PRs anywhere, or defensive PR threads |
| Live demos | Links work, you can click around, name attached | Links exist but require local setup | All links 404 or "demo paused" |
| Contribution graph | Mixed pattern, gaps, then bursts during projects | Suspiciously perfect daily green | All-green wall but no substance in repos |
| Issue participation | Asks good questions, files reproducible bugs | Quiet but present | Never engages with issues |
| Repo iteration | 30+ commits over weeks, messy middle | Few but substantive commits | Single huge initial commit, then silence |
If the candidate hits 4+ green flags and no red flags, they're worth a real conversation. If they hit any 2 red flags, save your time.
The founder evaluation flow (10 minutes per candidate)
You're not trying to become a code reviewer. You're triaging. Here's the order:
- Open their GitHub profile. Note the username, real name, location, bio.
- Glance at the contribution graph for shape, not volume. Bursts and gaps are normal and healthy.
- Click the top pinned repo. Read the README out loud to yourself. Does it sound like a human? Does it tell you what the project does?
- Open one live demo link from the pinned section. Does it load? Can you click anything? Bonus: does it have their name on it?
- Click "commits" on the most recently-updated repo. Read 5 commit messages. Specific or lazy?
- Click "Pull requests" tab. Filter for
is:pr author:<username> is:merged. Are any of these merges into repos the candidate doesn't own? - Search their username on Hacker News and Twitter / X. Do real engineers reference them or their projects?
That's the whole evaluation. Ten minutes, no code reading required.
If you want a one-page version of this flow to keep open during interviews, we have a similar founder playbook in how to find a technical advisor for your startup that pairs well with this evaluation.
When the GitHub profile is mostly empty
Lots of strong engineers have thin GitHub profiles. They've spent 8 years writing payment systems for a bank, all of which lives in a private corporate Bitbucket. That's not a red flag.
In that case, GitHub isn't the right evaluation surface. Ask instead for:
- A short Loom walking through a project they shipped at their last job (no proprietary details, just architecture).
- The name of a former colleague you can email for a one-paragraph reference.
- One technical write-up they've published anywhere (blog, internal Notion they can share, conference talk).
If they can produce one of those three in under 24 hours, the empty GitHub is fine. If they can't produce any, that's the actual signal.
Where Cadence fits, and where it doesn't
If you want to skip GitHub triage entirely for short-scope work, that is what booking exists for. Every engineer on Cadence has already cleared a structured interview that covers commit hygiene, public-repo review, and AI-native tooling fluency (Cursor, Claude Code, Copilot used daily) before they unlock the platform. Founders see four matched candidates, pick one, and start a 48-hour free trial; weekly billing, daily ratings, cancel any week with no notice. Cadence has 12,800 engineers in the active pool, and median time to first commit on a new booking is 27 hours.
That said, if you're hiring a co-founder, GitHub triage is still the right tool. A co-founder is a 10-year decision; you want to read their public work yourself, talk to people they've shipped with, and form your own judgement. For that decision, our breakdown of fractional CTO vs full-time CTO gives you the framework. And for the situation where you're not sure if you need a full-time technical hire at all, how to find a technical advisor for your startup is the right next read.
The honest answer is: for a single 2-week feature spec, GitHub triage is overkill, book the work. For a long-term hire, GitHub is one of several signals. For a co-founder, GitHub is necessary but not sufficient.
What to do next
Pick a candidate you're currently considering. Open their GitHub. Run the seven-step evaluation flow above with a timer set to 10 minutes. Write down a green / yellow / red verdict for each of the four core signals before you talk to them again. Most founders we talk to find that 60% of candidates fail this triage cleanly, which is a huge time-saver compared to scheduling another round.
If you want to skip the triage for a short, scoped piece of work, start a Cadence booking and use the 48-hour free trial as your evaluation step instead. Two days of real working code with you tells you more than two weeks of GitHub-reading.
If you're a non-technical founder hiring your first engineer and the candidate's GitHub feels like a coin flip, Cadence shortlists four pre-vetted engineers in two minutes, with a 48-hour free trial. Cancel any week, replace anyone, no notice period.
FAQ
Can a developer with no public GitHub still be a good hire?
Yes, often. Engineers from banks, defence, healthcare, and most enterprise jobs have years of work locked in private repos. Ask instead for a Loom walkthrough of a past project, a reference from a former colleague, and one piece of public writing (blog post, conference talk, internal doc they can share). One out of three is fine; zero out of three is the signal.
How long should a GitHub evaluation take a non-technical founder?
Ten minutes per candidate is enough. You're triaging, not code-reviewing. The seven-step flow in this post (profile, graph shape, top pinned repo README, one live demo, five commit messages, PRs to other people's repos, social proof search) covers the highest-signal evidence in that time.
What's the difference between a real OSS contributor and someone with a lot of forks?
A fork is just a copy. Anyone can fork the React repo with one click and have it sit on their profile forever. A real OSS contributor has merged pull requests into projects they don't own. To check, click their "Pull requests" tab, filter is:pr author:<username> is:merged, and look at the destination repo. If every merge is into their own forks, that's not contribution, that's housekeeping.
How do I tell if a repo was mostly AI-generated?
Look for the absence of struggle. A real human-built repo has 30+ commits over weeks with messy middle commits ("fix typescript error", "actually fix it", "revert previous"). An AI-bootstrapped portfolio repo has one massive initial commit, perfect prose in the README, and tests that only cover the happy path. Then ask the candidate on a call to explain a specific architectural choice past the second follow-up question. If they can't, the repo wrote them.
Should I just trust GitHub stars and follower counts?
No. Star counts are gameable (paid promotion, Twitter / X virality, niche communities upvoting each other) and follower counts measure social reach, not engineering skill. A 50-star repo with a thoughtful README, working demo, and clean commit history is a better signal than a 5,000-star repo that hasn't been touched in two years.