The first engineer is the hardest hire a non-technical founder ever makes, and not because of the salary. It is hard because you cannot yet judge the work. You can read a resume, sit through an interview, and still have no way to tell competent from confident. Worse, this one person sets the habits the codebase will keep for years: how things get tested, how they get deployed, whether anyone can pick the work up later. Hire well and the next five hires are easier. Hire badly and you inherit a system only one person understands, and that person is now hard to replace. So you do not try to evaluate code you cannot read. You evaluate everything around it.
Hire a generalist who ships, not a specialist
Founders often write the job description for the company they hope to be in three years, and they end up asking for a specialist in a stack that does not exist yet. The first engineer should be the opposite: a generalist who is comfortable owning the whole thing, from the database to the deploy, and who would rather ship a plain version this week than design the perfect one for a month. Depth comes later, with the second and third hires. What you need first is someone who reduces the number of unknowns every week, not someone who is the best in the world at one layer of a product you have not validated.
You are hiring an engineer, not a cofounder replacement
Be careful with the candidate who wants to redesign everything before they have shipped anything. It reads as ambition, and sometimes it is, but for a first hire it is usually a warning. The person who says the current approach is fine for now and here is the one thing I would change first is almost always more valuable than the person with a grand rewrite. You want judgment about what to leave alone, which is the same instinct that makes a good first month of a technical engagement productive. A first engineer who cannot resist rebuilding the foundation will spend your runway proving they are smart.
How to evaluate work you cannot read
You have more signal than you think, it is just not in the code. Can they explain a technical trade-off to you in plain language, without making you feel stupid and without hiding behind jargon? That is the single most predictive thing you can test, because it is what you will rely on every week once they are hired. Ask them to walk you through something they built and why they made the choices they made. Listen for whether they talk about the users and the constraints, or only about the technology. And take references seriously, especially the question of whether the people who worked with them would work with them again. A strong reference from a former teammate outweighs a polished interview every time.
The paid trial is the real interview
Nothing you learn in conversation matters as much as watching someone do a small piece of real work. Carve out a genuine task, something you actually need, and pay them fairly to do it over a few days. Not a whiteboard puzzle and not free labor, a real scoped problem with a real deadline. You will learn in a week what months of interviews would hide: whether they ask good questions before they start, whether they communicate when something is blocked, whether they ship something that works or something that demos. Removing that uncertainty early is the same logic that lets a studio go from idea to MVP in weeks, and it applies just as cleanly to a hire.
What good looks like
Ninety days in, a good first engineer has made themselves legible. You know what they are working on and why, in plain language, without having to ask. Work ships on a predictable rhythm rather than in heroic bursts. And there is a written trail, the smallest amount of documentation that lets the next person understand the system, because the first engineer knows they will not be the last. If you are making this hire without a technical partner to lean on, this is exactly the kind of decision a fractional CTO is built to de-risk: we run the search, structure the trial, and read the work you cannot. Tell us where you are stuck and we will help you make the call.