Your first hire needs to be good at shipping across the whole stack, not exceptional at one layer of it. You don’t have the surface area yet to keep a specialist busy in their specialty — a frontend expert will end up writing backend code anyway, badly, out of necessity. Hire for range first, depth later.

The trait that matters most: judgment without you in the room

At this stage you can’t review every decision. Your first hire will make calls when you’re asleep, in a meeting, or just not looking. What you’re really hiring for is: will their default decision, unsupervised, be close to the one you’d have made? Everything else is trainable.

What to actually test

Skip the algorithm puzzle. Give them something close to your real work:

• A real, small bug from your actual codebase, or one you construct in the same style. Watch how they investigate, not just whether they find it.
• A short pairing session on a real feature. You learn more from 45 minutes of watching someone think than from any take-home.
• A question about a past decision: “Tell me about a time you shipped something that turned out wrong. What did you do next?” You’re listening for ownership, not the mistake itself.

What to look for beyond code

• Communicates without being asked. Do they tell you a task is stuck before you have to ask, or do you find out three days later?
• Comfortable with ambiguity. Early-stage specs are half-written by definition. Someone who needs a full ticket to start will bottleneck on you constantly.
• Cares about the actual users, not just the code. Ask what they’d cut from a feature if the deadline moved up a week — a good answer reveals whether they understand why the feature exists at all.

The offer

Move fast once you’ve decided. Good early-stage candidates have other offers, and a slow process reads as disorganization they’ll expect from the whole company. Be honest about the risk: cash is probably below market, equity is a lottery ticket, and the job includes doing things outside their title. People who take that deal knowingly are usually the ones who work out.

The mistake to avoid

Hiring a mini-you is tempting and wrong. You need someone whose strengths cover your gaps — if you’re strong on backend and weak on frontend polish, don’t hire another backend-only engineer because interviewing them feels comfortable. Hire for what the company is missing, not for who’s easiest to talk to in the interview.

After the yes

The offer accepted is not the finish line. The first month with them is where the judgment call gets tested for real — give them a small, real, low-risk piece of ownership immediately, and watch how they handle it before you hand them anything bigger.

---