The \"Project Done in Public\" Signal: A Hiring Manager's Cheat Code

What you actually need to know

• A developer who builds in public is giving you a live record of how they work, not just a summary of what they have done.
• Commit history shows habits. A resume shows claims. One of those is harder to fake.
• Public projects reveal how a developer handles ambiguity, feedback, and the messy middle of building something real.
• A non technical founder can read a GitHub profile productively without understanding code. The patterns are readable without the syntax.
• The absence of public work is not disqualifying. But it shifts the evaluation burden to a trial project, which takes more time from both sides.

The core argument

The resume is a curated document. Everyone knows that. The developer writes it to maximize the chance of getting the interview, which means the rough edges get smoothed, the failed projects get dropped, and the job titles get upgraded to their most impressive possible reading. None of that is dishonest exactly, but it means the resume tells you the story the developer wants you to hear.

The public commit history is a different kind of document entirely. It was not written to impress you. It was written to track progress, which means it shows the false starts, the refactors, the commits labeled "fix that stupid bug" and "this should have worked the first time." It shows whether the developer works in small increments or in large irregular bursts. It shows whether they document their work or just push code. It shows whether they respond to issues or close them without acknowledgment. You cannot fake a two year commit history. You can fake a resume in an afternoon.

What makes this signal particularly useful for founders who do not code is that almost all of it is readable without technical expertise. You do not need to understand a React component to see whether the README explains the project clearly, whether the commit messages are thoughtful, and whether the developer engages with the people who use their work. Those things are visible from the surface and they tell you almost everything you need to know about what it is like to work with someone.

The one place where this signal breaks down is with developers who do their best work on private client codebases. Some genuinely excellent engineers have quiet public profiles because all of their real work is confidential. That is fine. Ask for a trial project. Give them a week and a small paid scope. The trial is a controlled version of the same signal, and it is the backup evaluation when the public record is thin.

Reading public work without writing code

The README test. Open any public project the developer lists on their profile. Read the README. A developer who can explain what the project does, who it is for, and how to run it, in plain English, in less than two minutes of reading, understands communication. That is the first quality a developer needs in a working relationship with a non technical founder.

The commit frequency chart. GitHub shows a grid of commit activity for the past year. You do not need to understand what was committed. You need to see whether there is a consistent pattern or whether all the commits pile up in one month. Consistent patterns suggest a developer who maintains habits. Burst patterns suggest a developer who scrambles and then disappears.

The issue tracker. If the repository has open issues, look at them. Look at how the developer responds to bug reports and feature requests from other people. Short dismissive responses are a signal. Long thoughtful responses that explain the reasoning behind a decision are a signal. No responses at all are a signal.

The project lifecycle. Did the project get finished? Does it have a release? Does it have users? A repository with one commit from three years ago is different from a repository with a stable release, a changelog, and a community. The first is a draft. The second is proof of follow through.

The developer who blogs about technical decisions

Technical blog posts are a cheat code for hiring managers. A developer who writes about architectural decisions, tradeoffs, and mistakes is giving you a window into their reasoning that no interview question can match. The quality of the writing does not matter as much as the specificity. A post that says "I chose Postgres over MongoDB for these three reasons" is worth more than ten posts about productivity habits.

I look for honesty about failure. A developer who writes about something that went wrong, and explains what they learned, is someone who processes mistakes rather than burying them. That habit carries directly into the working relationship.

What it actually costs to evaluate

The table above is not about choosing one method. It is about sequencing them. Public profile review should come before the interview, because it lets you ask better questions. The trial comes last, after everything else has already filtered the candidate.

What to look for in a developer's public work

• At least one project with evidence of real users or contributors beyond themselves.
• Commit messages that are readable and specific. "Fix login redirect bug on mobile" is better than "fix stuff."
• A README that explains the project without assuming you know the codebase.
• Responses to issues or pull requests that show engagement, not dismissal.
• Any evidence of iteration. A project that has been updated over time is more valuable than a project that was built in a weekend and never touched again.
• A personal site or blog with at least one post that explains a technical decision.

Expert opinion

The best hire I ever made was a developer I had never met before a two week trial. Their GitHub profile had three finished projects, a blog with eight posts, and two years of consistent commits. The resume had no big names on it. The public work was unmistakably real. We skipped two rounds of interviews and went straight to the trial. Four years later they are still the best engineering relationship I have had. The resume would have screened them out. The public work screened them in.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A founder I worked with was evaluating two developers for an early hire. One had a strong resume with logos from well known companies. The other had a quieter resume but an active GitHub with two finished projects, a technical blog, and clean commit history over eighteen months. The founder asked me to help evaluate both. I spent twenty minutes on each public profile. The first developer had a mostly empty GitHub and one tutorial repository. The second had evidence of real work, real users, and real documentation habits.

We ran both through a paid two week trial. The first developer was technically capable but communicated poorly and made assumptions without checking. The second was slightly slower but over communicated, documented every decision, and filed issues for every open question. The second hire worked out. The first would have been a recovery project within three months.

The lesson is not that resumes are useless. It is that public work is a faster and more reliable filter when it exists. The red flags in a developer portfolio post covers what to look for when the portfolio is polished but thin, and how recruiters can read a GitHub profile like a hiring manager goes deeper on the technical reading side.

Common mistakes when evaluating public work

1. Mistaking GitHub stars for quality. Stars measure virality, not craftsmanship.
2. Looking only at the most recent project. Habits show up over time, not in a single sprint.
3. Ignoring the README and only looking at the code. The README is readable to everyone. The code is not.
4. Treating no public work as a disqualifying signal. Some excellent developers work primarily on private codebases.
5. Overweighting follower count on social platforms. Following is about marketing ability, not engineering quality.
6. Not reading the issue tracker. How a developer handles other people's problems is a preview of how they will handle your problems.
7. Evaluating finished state only. The commit history shows the journey. The journey tells you more than the destination.
8. Skipping the trial when the public work is impressive. Public work is a signal, not a guarantee.

A 30 day hiring plan

1. Week one. For every candidate you are considering, spend twenty minutes on their public profile before scheduling the first call. Note the README quality, the commit frequency, and whether any projects have real users.
2. Week two. Run first calls. Ask about two or three specific projects you saw in their public work. Their ability to speak about their own work in detail confirms that the work was actually theirs.
3. Week three. Reference checks on the top two candidates. Three questions, fifteen minutes each. Would you hire them again. What kind of project would you not put them on. What would you want to know before working with them.
4. Week four. Paid two week trial with the leading candidate. A real slice of the product, not a throwaway test. Pay regardless of outcome.

For the full hiring process around the trial, the vetting framework for developer experience covers the reference and trial structure in detail. For what the developer should see when they start, the onboarding pack every new developer deserves covers the setup that makes a good hire successful.