Your first three engineering hires are a bet you can't diversify. A founder's guide to early startup hiring: screening for judgment, generalists over specialists, and firing fast.
A friend who runs a much bigger company once told me his first bad hire cost him "maybe two weeks of onboarding, then we moved on." He has 200 engineers. One weak hire in 200 is rounding error. When I hired my first bad engineer at Shpper, we had four people. That one hire wasn't 25% of the team. He was 25% of the culture, 25% of the code review standard, and 100% of the reason two good people started writing sloppier PRs, because the bar had visibly dropped and nobody stopped it.
That's the whole thing I want to argue here. Your first three engineering hires are not seats you're filling. They are the genetic code of every engineer you'll ever hire after them. And the standard hiring playbook, the one written by and for companies with a hundred people and a recruiting funnel, is not just unhelpful at this stage. It's actively wrong. You cannot diversify this bet. You're putting a third of your future on one person, three times in a row, before you have any of the machinery that's supposed to make hiring safe. If you're a founder about to make your first engineering hire, this is the mental model I wish someone had handed me before I made mine.
Big companies hire against a system. There's an existing codebase with conventions, a code review culture, a definition of done, senior people who set the tone, and a blast radius small enough that a mediocre hire gets absorbed. The system carries the person.
At three people, there is no system. The person carries the system. Whatever your first three engineers do becomes "how we do things here," permanently, because there's no prior "how we do things here" for them to conform to. They're not joining a culture. They are the culture, in the most literal sense.
This inverts the math. In a big org, hiring is a variance-reduction game: you filter out the bottom, and the average catches everyone. In an early-stage startup at headcount three, hiring is a variance-amplification game. One person's habits, good or bad, propagate to everyone who comes after. I've watched a single engineer's obsession with writing tests turn into a company-wide reflex that outlasted his own tenure by years. I've also watched one person's "I'll clean it up later" become the unspoken license for an entire team to ship debt.
So the frame isn't "is this person good enough?" It's "do I want twenty of this person, because that's what I'm signing up for." Every early hire is a template. You're not filling one seat; you're setting the default for the next thirty.
Put rough numbers on it. At 200 engineers, a bad hire touches maybe 1% of your code and interacts closely with five or six people. At three engineers, a bad hire touches a third of your code, sits in every architecture conversation you have, and is a peer to everyone. There is no hallway of good engineers to dilute their influence. Their pull requests set the review bar. Their shortcuts set the debt tolerance. Their "good enough" becomes your "good enough." The influence isn't proportional to headcount; it's inversely proportional. The smaller the team, the larger each person looms.
The instinct is to screen for skills. Skills are the wrong primary filter this early, and not because they don't matter. They matter enormously. But skills are the easiest thing to observe and the easiest thing to fix. What's hard to observe and nearly impossible to fix is everything else.
Here's roughly the order I actually weight things at this stage:
Notice that the two things at the top are the two things a big-company interview loop is worst at measuring, and the two things at the bottom are what most technical interviews spend all their time on. That mismatch is the whole problem. A candidate can grind LeetCode for a month and ace your algorithm round while having zero of the judgment that actually matters at three people. The signal you're optimizing for is often the one that predicts the least.
The concrete test I use: I describe a real, messy decision we actually faced, one where there was no clean answer, and I ask what they'd do. I don't care about the answer. I care about how they interrogate the problem before answering. A recent one: should we ship a half-migrated Firestore schema to hit a demo date, or hold and slip a week? There's no right answer; there's only how you reason about it.
The people who immediately start asking sharp questions are the ones who'll hold up when the ground is shifting under them:
That last distinction, reversible versus irreversible, is the single clearest tell of good engineering judgment. Someone who instinctively separates a two-way door from a one-way door is someone I want in the room when we're deciding fast under pressure. Someone who just picks an answer and defends it, without probing what they don't know, is someone who will confidently walk the team off a cliff.
This one has a clear answer, and I'll state it plainly: at three engineers, hire generalists. Almost always.
A specialist is a bet that the shape of your work is stable enough to justify depth in one area. At three people, the shape of your work changes every quarter. One month you're deep in Flutter animation performance, the next you're debugging a Firebase security rule that's leaking data, the week after you're writing the CI pipeline because deploys are taking an hour and everyone's blocked. A specialist gives you one deep column and a lot of "that's not my area." A generalist gives you coverage across the whole surface, which is exactly what a three-person team lives or dies on.
The exception is when your entire product is the specialty. If you're building a video codec, your first hire is a codec person, full stop. If your moat is a machine-learning model, hire the ML person first. But for most product startups, "the specialty" is shipping working software fast, and that's a generalist's game.
There's a subtler point here about risk. Early specialists create fragile dependencies. If your one backend expert is the only person who can touch the backend, you've built a single point of failure into a three-person org, which is roughly the most dangerous place to have one. Generalists create redundancy. Any one of them can cover for any other one, which is what lets you sleep when someone takes leave or, eventually, quits.
I made this mistake once and paid for it. Early on I hired a very strong specialist for a narrow, deep problem, and he was genuinely excellent at it. But when that problem was solved, three months in, he had nothing to grip. He wasn't slow because he was bad. He was slow because his shape didn't fit a team that needed everyone to swing at whatever was in front of them. The lesson: at this stage, hire for range, not for peak. You want people who are a strong 8 across the whole board, not a 10 in one square and a 3 everywhere else.
You have no structured loop, no rubric refined over a thousand candidates, no bar-raiser program. Good. Don't fake one. A copied FAANG interview loop with a founder role-playing a "system design round" is theater, and strong senior candidates see through it in about ninety seconds.
What actually predicts performance this early is watching someone do the real work. So make the interview be the work:
Here's a small framework I keep in my head for scoring the pairing session. I'm not filling in a spreadsheet during the call, but afterward I ask myself:
| Signal | Green flag | Red flag |
|---|---|---|
| First move on the bug | Reproduces it, reads the error | Starts changing code randomly |
| Being wrong | "Huh, interesting, let me check" | Defends the dead hypothesis |
| Unknown territory | "I don't know, here's how I'd find out" | Bluffs |
| Your codebase | Curious, asks about tradeoffs | Silently judges or silently drowns |
| Debugging style | Forms a hypothesis, then tests it | Shotguns changes hoping one sticks |
The one rule I won't break: every candidate for the first three writes real code in front of me, or with me, before an offer. No exceptions, no "they're too senior for that." Especially if they're too senior for that. The more impressive the resume, the more important it is to see the actual work, because the gap between reputation and reality is where the expensive mis-hires live.
Here's the uncomfortable part. The best generalist engineers, the exact people you want, have options. They can go to a company with a real salary, a real brand, and a real chance the thing still exists in two years. You have none of that. You have a logo you made in an afternoon and a runway you don't fully talk about.
So stop competing on the axes you'll lose. You will not win on comp, security, or prestige. You can win on three things a big company structurally cannot offer:
The counterintuitive move is to disqualify people during the sell. Tell them the hard version. If a candidate needs a comfortable, low-risk environment, you want them to self-select out now, not blow up your three-person team in month four. The pitch and the filter are the same conversation. Every honest sentence about the risk is doing double duty: it attracts the person who's energized by it and repels the person who'll resent it in six months.
Most reference calls are worthless because the questions are worthless. "Was she a good engineer?" gets you "Yes, she was great!" every time. Of course she was. The candidate picked the reference.
The trick is to ask questions that are hard to answer with reflexive praise, and to listen to the shape of the answer more than the content. My actual list:
Two rules. First, listen for what's not said. A reference who raves about someone's brilliance and never once mentions reliability is telling you something. Second, always ask for a back-channel reference, someone the candidate didn't list. That's the call that actually predicts. On one hire, the listed references were glowing and the back-channel gave me a careful, three-sentence answer with a lot of silence in it. I hired anyway. I shouldn't have. The silence was the whole message, and I chose not to hear it.
Let me be direct about the cost, because founders lie to themselves about this. A mis-hire at headcount three is not a 33% problem. It's closer to a whole-company problem, for a stretch. The damage compounds across four channels:
Here's the hard-won rule: you will know within four to six weeks, and you will wait four to six months. The gap between those two numbers is where startups quietly rot. The signals show up fast: they need everything spec'd out, they go quiet when they're stuck, the code needs heavy rework every time, other people start routing around them. And you explain it all away, because firing someone at a four-person company feels catastrophic and you hired them, so admitting it is admitting your own miss.
Unwind it fast, and unwind it clean:
The mistake I made was waiting. I knew at week five and moved at month five. Those four months cost me a resignation from someone I didn't want to lose, who'd simply gotten tired of carrying the slack and watching me not act. That's the real bill for a slow unwind, and it's paid by your best people, not your worst. The bad hire moves on and lands somewhere better suited to them. The engineer who quit because you hesitated is the one you never get back.