Your first engineer does not inherit a codebase, a team, or a process. They build all three while also shipping the product. Get this hire wrong and you spend the next year working around them. Here is the checklist we actually use.
I have made this hire twice, badly once and well once. The bad version looked great on paper: strong resume, clean whiteboard performance, glowing references from a big company everyone recognized. Six months in, every decision took a committee that did not exist yet, because that is how they had been trained to work. The good version had a thinner resume and a repo full of half-finished side projects. Eighteen months later that person was running engineering.
The difference was never raw skill. Both could code. The difference was a set of behavioral and technical signals that show up long before day one, if you know where to look. That is the same idea behind job fit scoring: you are not grading a person in the abstract, you are grading the specific match between what this role at this company at this stage actually demands and what the evidence shows this person does under pressure.
Why the first hire is different
A first engineer is not a junior member of an existing team. There is no existing team. Every convention they establish, every shortcut they take, every corner they cut becomes the default the next five hires inherit. Underdog's 2026 guide to founding engineer roles puts it plainly: early engineers "establish standards for code quality, decision-making speed, and knowledge documentation that shape future hires and culture". You are not hiring an output. You are hiring a template.
That is also why a resume tells you almost nothing here. A staff title at a company with four layers of review says someone survived a process, not that they can build one. What you actually need is signal: specific, checkable evidence of how someone behaves when there is no process to hide behind.
The 12 signals
These are not soft traits like "communicates well." Each one is something you can observe, ask about with a specific example, or check against a public record before the person ever starts.
- Ships without a spec. Give them an ambiguous problem in the interview, not a leetcode puzzle. Watch whether they ask three clarifying questions and start building, or wait for a document that does not exist yet.
- Has taken something from zero to one before. Not "worked on a new feature." Actually owned a product, internal tool, or side project from empty repo to real users, even a small one. The muscle for that first mile is different from the muscle for scaling mile forty.
- Debugs production calmly. Ask for a story about a live incident they caused. The best answers are boring: they found it, fixed it, wrote down why, moved on. The worst answers blame the deploy process.
- Chooses boring technology on purpose. Early engineers who reach for the newest framework because it is interesting are optimizing for their own resume, not your runway. Ask why they picked their last three tools and listen for tradeoffs, not trends.
- Writes docs nobody asked for. Check their GitHub for READMEs, comments, or a wiki page written before anyone else needed it. This is the single best proxy we have found for whether someone can eventually delegate and hire.
- Owns mistakes in public, not just privately. Look for a commit message, a postmortem, or a comment thread where they say plainly "this was my bug" without hedging. People who can do that in public tend to do it in a room with a founder too.
- Deletes their own code. Ask about a project they killed or a feature they ripped out. Engineers who can cut scope, including their own past work, tend to survive the constant re-prioritization of an early startup.
- Talks to users without being told to. Underdog's guide calls this out directly: the most valuable early engineers demonstrate "product sense, user empathy, and comfort across architecture, hiring, and customer interaction", not just deep technical range. Ask when they last sat in on a support ticket or a sales call by choice.
- Reviews AI-generated code like a skeptic, not a rubber stamp. This is the newest signal on the list and it is now one of the most important. More on this below.
- Has a consistent commit cadence, not a fundraising-week burst. Steady activity across 12 to 18 months tells you more than a flurry of green squares the month before they started job hunting.
- Can explain a technical decision to a non-technical person in one paragraph. Not dumbing it down. Compressing it. If they cannot do this for you in the interview, they will not be able to do it for a customer or an investor later.
- Wants ownership more than title. Ask what they would want to be called in eighteen months if the company does well. People chasing "Staff Engineer" over "the person who built the thing" are optimizing for the wrong outcome at this stage.
None of these show up on a resume. All twelve show up in a 45-minute conversation and a public commit history, if you know which questions to ask and which repos to actually read.
Why AI tools raised the bar, not lowered it
The obvious worry with signal 9 is that AI coding assistants make it harder to tell who actually understands what they shipped. That worry is now backed by data. Karat's 2026 survey of engineering leaders found that 71 percent report AI is making technical skills harder to assess, and that traditional code tests and take-homes no longer distinguish conceptual understanding from AI-generated output. Google has responded by rebuilding its own interview loop around this exact problem: a new "code comprehension" round has candidates debug and optimize an existing codebase with an AI assistant available, and interviewers are explicitly instructed to evaluate "AI fluency, including prompt engineering, output validation, and debugging skills" rather than raw output.
For a first engineer this matters more than for a hire number fifty. Everyone on your team of one is going to lean on AI tools to move fast, and that is correct. The question is not whether they use the tools. It is whether they can look at a plausible-sounding AI-generated function and say, specifically, why it is wrong, or whether they will ship it because it compiled. We built signal 9 into our own candidate scoring for exactly this reason: the interview exercise that separates people now is not "write this function," it is "here is 200 lines an assistant wrote, find what it got wrong and tell me why."
Each of the 12 signals maps to a specific piece of evidence, a commit, a quote from the interview, a public thread, not a gut feeling. When a founder asks "why did this candidate score an 8 on ownership and not a 5," the answer is one click away, the same way it works for reading a founder's GitHub before the first call. No black box, no vibes-only judgment call that nobody can defend six months later when it turns out to be wrong.
How we weight it
Not all 12 signals matter equally at every stage, and treating them as equal is its own mistake. Before product-market fit, signals 1, 2, 3, and 9 carry more weight than the rest, because the cost of someone who freezes without a spec or panics during an incident is existential when there is no one else to catch it. After you have a second and third engineer, signals 8, 11, and 12 start mattering more, because now the question shifts from "can this person survive chaos" to "will this person make the next five hires better."
This is the same logic behind any real job fit scoring system: the bar is not fixed, it moves with the role and the stage, and pretending otherwise is how companies end up hiring a great hire number twenty as hire number one.