Hiring your first engineer when you cannot judge one

Four things are judgeable by somebody who cannot read code, and they are enough. The questions they ask before they answer one. What they write down when they make a decision. What they do to a real defect of yours, in paid time, with the explanation attached. And whether they will accept a second reader on their work. Everything else in a normal hiring process — the CV, the framework list, the take-home you cannot grade, the pleasant hour of conversation — measures your comfort rather than their competence, and the gap does not surface until month four.

Start by accepting how little the credential carries, because the official description says so. The US Bureau of Labor Statistics lists the typical entry-level education for software developers, quality assurance analysts and testers as a "Bachelor's degree", and records both "Work Experience in a Related Occupation" and "On-the-job Training" as "None" (US Bureau of Labor Statistics, Software Developers, Quality Assurance Analysts, and Testers, Occupational Outlook Handbook). No licence, no required apprenticeship, no examination, no professional body that can strike anyone off. That is not a criticism of the trade — it is the reason a CV is a list of things somebody has been near rather than a filter, and why two people with identical résumés differ by more here than in most occupations.

The questions they ask before they answer one are the highest-signal thing available, and you are qualified to grade them, because they are questions about your business. Somebody who has operated software asks what happens when it breaks at three in the morning and who gets the call. Who the users are and what they do when the product is wrong. What the product must refuse to do. Whether any data must not leave a jurisdiction. Who else has access. Somebody who goes straight to the stack — which framework, which database — has told you what they enjoy, which is not the same information. The tell is whether any question they ask could only be answered by you.

What they write down is the second, and one page settles it. Ask for a short account of a technical decision they made last year, in three parts: what was decided, what the alternatives were, and what would have to become true for it to be revisited. You can read that page without being able to evaluate the engineering, and the diagnostic clause is the third. A decision with no stated reversal condition is one nobody really examined, and that paragraph is the artefact which makes a non-technical founder able to supervise craft at all. The division it rests on is set out in what a non-technical founder should own, and what to delegate.

The third is a paid trial built to be graded by you, which means the deliverable is not the code. Take a real defect with a symptom a customer has complained about. Pay for a day or two, under an agreement that assigns the work to your company. Ask for the fix and a note covering four things: what caused it, what else could have caused it and how they ruled those out, what would stop it recurring, and what else in the system has the same shape. You are grading the note. A weak one is three sentences or a wall of jargon; a strong one is readable by you and contains something you did not know about your product. Grade the conduct beside it — did they ask for access on day one or day three, did they warn you before it was late. Question a referee the same way, using the method professional buyers use: what was this person like in the week something went badly wrong, and can you describe something they explained to a non-technical person.

The fourth is structural rather than a screen, and it is the one founders skip. Google's Site Reliability Engineering book is direct about what a team is really deciding when it lets somebody take responsibility for a live system: "Successful SRE teams are built on trust—in order to maintain a service consistently and globally, you need to trust that your fellow on-callers know how your system works, can diagnose atypical system behaviors, are comfortable with reaching out for help, and can react under pressure to save the day." The question it tells teams to ask is "How can my existing on-callers assess the readiness of the newbie for on-call?" (Google, Accelerating SREs to On-Call and Beyond, Site Reliability Engineering). At your size there are no existing on-callers. That is the whole difficulty in one line: the readiness assessment has to be built by you, in advance, out of the only material you have.

The same chapter supplies the format. Google's Search SRE team runs new engineers through an on-call learning checklist which, the chapter notes, "does not directly encode procedures, diagnostic steps, or playbooks; instead, it's a relatively future-proof write-up focusing strictly on enumerating expert contacts, highlighting the most useful documentation resources, establishing basic knowledge you must gather and internalize, and asking probing questions that can only be answered once that basic knowledge has been absorbed." Write five such questions about your own system, choosing ones whose answers you already know. Where does customer data physically live. What happens if the payment provider is down for an hour. Which user can see which records. What is the largest thing the system does without a human approving it. How would we find out it had stopped working. Ask them in week three: you are not testing engineering, you are testing whether somebody has looked, and you can mark that.

It also names the anti-pattern a founder falls into by default, which is having no process at all: "Deluging students with menial work (e.g., alert/ticket triage) to train them; 'trial by fire'." The verdict deserves reading twice by anyone about to hand a new hire a bug list and go back to selling — "If you're lucky, the engineers who are already good at navigating ambiguity will crawl out of the hole you've put them in. But chances are, this strategy has alienated several capable engineers." Its alternative, "Encouraging reverse engineering, statistical thinking, and working from fundamental principles", matters twice over when the code was generated: there is no original author to ask, so reverse engineering is the only route to understanding there is.

Buy a second reader, and never let one person be the only human who has read the code. NIST's Secure Software Development Framework separates two things founders merge — code review, where "a person looks directly at the code to find issues", and code analysis, where "tools are used to find issues in code, either in a fully automated way or in conjunction with a person" — and its first example under performing one is to "Perform peer review of code, and review any existing code review, analysis, or testing results as part of the peer review" (NIST, SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, February 2022). With one engineer the peer does not exist unless you buy one. A few hours a month of an outside senior engineer, on the paths that carry money and identity, does two jobs: it catches what the tools do not, and it gives you the independent read on your hire's work that you cannot form yourself. A fractional CTO engagement is the same idea with the hiring plan attached.

Be clear about what this person is actually for, because getting it wrong is the expensive mis-hire. If you already have a product, building is the part that is done. What remains is the operate half — permissions enforced at the endpoint, migrations against real customer records, error paths, cost under load, a written definition of a wrong answer — the list in what breaks when an AI-built prototype meets real users. A candidate who is dazzling at producing features quickly is strong at the half you have already automated. Hire for the half you have not.

The related warning sign is a candidate whose plan for week one is to start over. It is sincere and almost always premature: the estimate is being made by the person who has learned least about the system so far. The conditions that genuinely justify starting again are narrow and testable, and they are in rewrite or repair an AI-built codebase. Ask anyone who proposes it to name the specific change they could not make in the system as it stands.

The first hire need not be an employee, and for many founders should not be yet. In Stack Overflow's 2025 Developer Survey, 13.9% of respondents described themselves as an independent contractor, freelancer or self-employed, against 69.8% in formal employment (Stack Overflow, 2025 Developer Survey: Work). A contract engagement with a defined first deliverable turns the hiring decision into an evidence-gathering one and is far easier to end. The paperwork is the same either way: the repository inside your company's organisation, every account in the company's name, written assignment of whatever gets produced. That list is the handover you must receive, and it applies to an individual exactly as it does to a firm.

Keeping them is the same problem in different clothes, and here the founder who cannot judge craft has an advantage. The same survey asked respondents to rank the attributes of their current professional job in technology: "Autonomy and trust to manage your own tasks" came first overall, "Competitive pay and benefits" second and "Solving real-world problems" third, while "You like your manager" ranked ninth of fifteen. The headline numbers are sobering — 24.5% described themselves as happy at work, 47.1% as complacent and 28.4% as not happy. Autonomy ranks first and is precisely what you are forced to give, since you cannot micromanage what you cannot read. The failure mode is the inverse: supervising hard on the parts you can see while the parts you cannot go unexamined for a year. Autonomy over craft, supervision over judgement, a second reader over anything that carries money.

What has to exist before day one, none of it technical. The repository, cloud account, domain and payment processor in the company's name rather than anyone's personal one. The four documents a founder owns — the refusal list, the wrong-answer list, the permission matrix, the record of decisions and their reversal conditions. A written first deliverable with a date. Whoever does your second read, named. And the comprehension questions for week three, written before the offer goes out, because writing them afterwards is how they turn into questions whose answers have already been supplied.

None of this makes you able to evaluate engineering, and it is not meant to. It makes the hire survivable while you cannot, which is the honest goal until there are two engineers who can assess each other. It is also worth saying plainly that a first hire is not always the right instrument: if what you need is a defined piece of work finished rather than a capability that has to live inside the company, the arithmetic is in an in-house AI team versus an AI development agency. A startup software development company worth talking to will tell you which of the two you are looking at, and will offer to be the second reader on the first person you hire — including when that person is not them. And if you would rather have the failure modes of what you have already built named before the job description is written, the free production-readiness diagnostic returns them in the order they are likely to bite — which doubles as a first list of things to ask a candidate how they would fix.