Skip to content
← Field Guide

Chapter 01

How to hire your first engineer

Your first engineering hire will shape your product more than any technology decision you make. Get it right and everything downstream gets easier. Get it wrong and you'll spend two years and a painful rewrite finding out.

The three hires founders get wrong

The big-company senior engineer. Fifteen years at a household name sounds like safety. But someone who's only worked inside mature infrastructure, with platform teams and code review queues and a design system, often can't operate without them. You need someone who has shipped from zero.

The genius who can't communicate. If you're non-technical, your first engineer is also your translator. A brilliant engineer you can't understand — or who can't explain a trade-off in plain English — leaves you making blind decisions. You'll feel it in every roadmap conversation.

The friend-of-a-friend contractor who never leaves. A contractor who slid into being your de facto tech lead was never screened for that job. Sometimes it works. Usually you find out at your first due diligence that nobody ever made an actual hiring decision.

What to screen for instead

  1. Has shipped a product from zero to real users — ideally more than once. Ask what broke, what they'd do differently, and listen for specifics.
  2. Explains technical trade-offs in plain English. In the interview, ask them to explain something they built to you like you're the CEO — because you are.
  3. Pragmatism over purity. Ask what they think of rewrites. The right answer involves reluctance.
  4. Comfortable being wrong in public. Zero-to-one work is a string of corrected guesses. Ego kills small teams.
  5. Has opinions about what not to build. The best early engineers delete more roadmap than they add.

The generalist rule

Before 10 engineers, hire generalists who lean toward your core problem. A "backend person" who won't touch the frontend is a luxury you can't afford at three people. Specialists come later, when the thing they specialize in is actually your bottleneck.

How to run the process when you can't evaluate the work

You can't grade the code. Fine — you can grade everything around it:

  • Reference checks are your code review. Call the founder or manager from their last zero-to-one project. Ask: "Would you hire them again as your first engineer?" The pause tells you everything.
  • Pay for a real work sample. A day-rate project on something adjacent to your product beats any whiteboard puzzle. Watch how they ask questions.
  • Borrow senior judgment for the final round. One hour of an experienced CTO interviewing your finalist is the cheapest insurance you'll ever buy. (Yes, we do this. Anyone senior you trust works too.)

Comp, honestly

Your first engineer is a partner in everything but title. Underpaying with a big title and vague equity promises selects for people who couldn't get a real offer. Pay near-market cash plus meaningful equity, and be explicit about what the equity is worth today — which might be nothing. Candor here screens in the people you want.