How businesses can find builders to hire by what they've shipped

If you've posted a job recently, you know the pattern. Hundreds of applications, most of them a poor fit, and a nagging sense that the people you actually want never applied.

That isn't bad luck. Joel Spolsky described it back in 2006 in "Finding Great Developers": "The great software developers, indeed, the best people in every field, are quite simply never on the market." He estimated that a great developer applies for maybe four jobs in their whole career. They move through people they already know.

So if you want to hire builders, whether that's an engineer, a designer, a technical contractor or a first employee, you have to find them before they're looking. The best signal you have is what they've already built.

Why résumés don't tell you much

Paul Graham made the point in "Great Hackers." Even good engineers find it hard to tell who's great. "You also can't tell from their resumes." His conclusion was that the only reliable way to judge someone is to work with them on something.

You can't work with everyone before you hire them. But you can get much closer than a résumé and a forty-five-minute interview by looking at finished work and doing a small project together.

A fair warning about public work

Shipped work is a strong signal, but its absence isn't a red flag. When someone asked Hacker News what hiring managers look for in an applicant's GitHub, the answers were split. Some wanted clear READMEs, sensible commits and a project that's easy to understand. Others said they don't use it at all: "Not everyone uses github as a portfolio," and many people do their best work in private repositories for employers.

So treat public work as one way in, not a filter. Plenty of excellent builders have nothing public because everything they shipped belongs to someone else. Ask them to walk you through it instead.

Step 1: Describe the work, not the title

Before you look at anyone, write down what this person will ship in their first ninety days. "Rebuild onboarding so new accounts reach their first report in under five minutes" tells you far more about who you need than "Senior Full-Stack Engineer."

It also gives candidates something real to react to, and the good ones will tell you if your plan is wrong.

Step 2: Look for evidence of finishing

Starting things is easy. What you want is a record of finishing them:

• Products with users. Even a small side project that a few hundred people use regularly means someone handled support, bugs and boring edge cases.
• A trail of releases. Changelogs, launch posts, release notes. Consistent small releases show reliability.
• Things they owned end to end. A feature, a migration, a launch, where they can explain every decision.
• Open-source contributions that were merged, where they had to work to someone else's standards.

Step 3: Ask them to walk you through something they shipped

This is the best interview question there is, and it works whether the work is public or not. Ask:

• What was the problem, and who had it?
• What did you decide not to build?
• What broke after launch, and what did you do?
• What would you do differently now?

People who actually built something answer in specifics. People who were nearby answer in generalities.

Step 4: Do a small, paid trial

If you can, work together on a small, clearly scoped project and pay for it at a fair rate. A day or two is usually enough. It's the closest you'll get to Graham's "work with them on something," and it's fairer to the candidate than a long unpaid take-home.

Pick something real but self-contained, so they aren't blocked waiting on access to everything.

Step 5: Meet people before you need them

Since great builders rarely go looking, the businesses that hire them well are already in the room when they become available. In San Francisco that means:

• Co-working sessions in cafés and coworking spaces
• Demo nights, where you see people show what they built
• Hackathons, where you see how people work under time pressure
• Small builder meetups rather than big recruiting mixers

Go regularly, and go to learn rather than to recruit. A builder who has talked to you about their side project three times will take your call when they're ready to move.

Step 6: Be clear about the offer

Builders get approached a lot. The fastest way to stand out is to be specific: the role, the salary range, the equity, the team, and what they'd own. Vague "exciting opportunities" go straight to archive.

Where The Build Nation fits

The Build Nation is a free, real-time network for builders, investors, mentors and businesses, live in San Francisco. It's designed around output, which makes it a good place to see what people have built before you ever talk about a job.

Member profiles show work, not popularity: what someone is building, things they've shipped, their stage, their field and an 18-week proof-of-work grid. Likes and followers never count toward anything. You can see exactly what goes into a profile on how ranking works. Profiles never show anyone's location or who they're connected to.

On your own profile, you can set "Here to" to hiring builders, so people know why you're reaching out. You can host a quick meetup at a coworking spot, say a co-working session or a demo afternoon, and meet builders working nearby. If you and someone both choose "Want to meet", a chat opens so you can talk properly.

What it isn't: a job board, a recruiting database or a mass-messaging tool. There are no recruiter features, and we'd ask you not to treat members as leads. Use it to meet builders as people, see their work, and start the conversation early.

The short version

The builders you want are busy shipping, not applying. Find them by their work, judge them by what they've finished, try a small project together, and be in the room before they're looking.