Hiring Your First Engineer: Judging Technical Work When You Cannot Judge Code

What am I actually deciding when I make this hire?

You are choosing the technical foundations, not just filling a seat. The first engineer will pick a language, a framework, a hosting arrangement, a data model, and a set of conventions, and every one of those choices constrains what the next several engineers can do and how quickly. Reversing them later is possible and expensive, and the expense is usually paid in months rather than in cash.

You are also setting the hiring pool for everyone who follows. Choices that are unusual or highly specialized narrow the set of people who can join and work productively, while conventional choices widen it. That is not an argument for the most popular option in every case, and it is an argument for asking any candidate to justify an unconventional choice in terms of the constraint it solves.

Finally, you are deciding what your own involvement will look like. An engineer who explains their reasoning in terms you follow keeps you able to participate in technical trade-offs. One who does not will make decisions you cannot evaluate, which is workable when you trust them completely and dangerous when the first serious disagreement arrives.

How do I assess technical ability if I am not technical?

Do not attempt to evaluate code you cannot read, and do not use a proxy such as a well-known former employer as a substitute. Instead, buy the evaluation. An experienced engineer you trust, engaged for a few hours as an advisor, can review a work sample and interview the candidate technically at a fraction of the cost of a wrong hire. This is the single highest-return expenditure available to a non-technical founder at this stage.

What you can assess yourself is explanation. Ask the candidate to describe a technical decision they made where the obvious choice was wrong, and listen for whether they can make you understand the trade-off without either oversimplifying or hiding behind terminology. Someone who can teach you the shape of a problem in ten minutes will keep you informed for years; someone who cannot will leave you dependent.

You can also assess estimation and honesty about uncertainty. Describe something you want built and ask how long it would take and what they would need to know to answer better. Confident precise estimates from limited information are a warning sign. A candidate who names the assumptions that would change the answer is showing you how they will communicate when a deadline is at risk.

What kind of work sample actually discriminates?

Use a problem drawn from your real backlog, scoped to a few hours and stripped of anything confidential. Artificial puzzles measure preparation for puzzles. A real problem measures how someone approaches ambiguity, what they clarify before starting, what they choose not to build, and whether their solution fits the constraints you actually have.

Pay for the time and say so upfront. It changes who is willing to participate, particularly people currently employed with limited spare hours, and it changes the tone of the exercise from an audition to a paid piece of work. Cap the scope explicitly and mean it, because a candidate who spends fifteen hours on a four-hour exercise has told you something about how they will handle scope elsewhere.

Review the submission with the candidate rather than in isolation. The conversation about why they made each choice, what they would do differently with more time, and what they deliberately left out is more informative than the artifact. Someone whose work looks modest but whose reasoning is excellent is usually a better bet than the reverse, particularly at the first hire where judgment compounds.

Should the first engineer be senior, and what does senior mean here?

Seniority in this context means having personally owned the consequences of their own architectural decisions over time, not years of experience or a title. Someone who has built systems, watched them break under real load, and fixed what they got wrong brings something a talented engineer who has only ever worked inside a mature codebase does not, which is knowledge of what fails.

The trade-off is cost and availability. Genuinely experienced engineers are expensive in cash and ownership and are usually being courted elsewhere, and an early company may not be able to compete on package. What an early company can offer is scope: full ownership of technical direction, direct contact with users, and the absence of the layers that experienced engineers frequently leave larger employers to escape.

A less senior first engineer can work when paired with an experienced technical advisor who reviews design decisions periodically. This arrangement costs a fraction of a senior salary, provides the pattern knowledge the hire lacks, and gives the hire someone to learn from. It requires that the advisor has real time and real authority to push back, not a nominal role.

Is a contract-to-permanent trial a good idea?

It gives both sides real information that no interview produces: how the person works over weeks, how they handle being wrong, how they communicate when something slips, and whether you enjoy working together. For the candidate it is equally informative, and candidates who have been burned by a misrepresented role often welcome it.

The constraints are practical and legal. Strong candidates in demand frequently will not leave a stable position for a trial, so this arrangement selects from a narrower pool. Worker classification rules differ by jurisdiction and a trial structured carelessly can create obligations or exposure you did not intend, so the arrangement should be documented with local advice rather than agreed informally.

If you run one, define it precisely: duration, what will be delivered, what is being assessed, what the compensation is, and what happens at the end in both directions. Ambiguity here produces the worst outcome, which is a trial that drifts into an indefinite contract nobody has decided about while the person does the job without the commitment either way.

What should I ask about how they will work with me?

Ask what they would need from you in the first month, and listen for whether the answer includes anything about the business rather than only about tooling and access. An engineer who wants to understand the customers and the commercial constraints will make better technical trade-offs than one who wants a specification, because at this stage there is no specification.

Ask how they have handled being asked to build something they thought was wrong. The answer reveals whether they push back with reasoning, comply silently and resent it, or refuse. All three exist, and the first is the one that works in a small team where you will frequently be wrong and need to be told.

Ask what they want to be doing in two years, and take the answer seriously. Some excellent engineers want to keep building and have no interest in managing, and a company that assumes the first engineer becomes the engineering leader creates an unwanted promotion. Knowing this at the offer stage lets you plan the second and third hires with the actual person in mind.

What should the first ninety days look like?

Ship something small and real in the first two weeks, even if it is minor. It establishes that the path from decision to production works, which is often not true at the start, and it gives both of you early evidence about pace and communication rather than waiting three months for a large piece of work to reveal it.

Ask for the decisions to be written down as they are made, in a few sentences each: what was chosen, what the alternatives were, and why. This costs the engineer almost nothing at the time and is enormously valuable when the second engineer joins, when something breaks at an inconvenient moment, or when the first engineer eventually leaves. It also lets a non-technical founder or an advisor review reasoning without reading code.

Set the expectation that they will identify the biggest technical risk they have found and tell you plainly. New engineers frequently notice something concerning in the first month and say nothing, either from politeness or because they assume it is known. Asking explicitly makes it a normal disclosure rather than a criticism, and the answer is often the most useful thing you learn all quarter.

What to take away

• ▸This hire sets architecture, tooling, and the standard later engineers inherit, so reversal costs months.
• ▸If you cannot read code, engage an experienced engineer as a paid reviewer for the work sample and technical interview.
• ▸Use a paid, scope-capped problem from your real backlog and review it in conversation with the candidate.
• ▸Judge seniority by having personally lived with the consequences of their own decisions, not by years or title.
• ▸Document any trial arrangement precisely and take local advice, since classification rules vary by jurisdiction.
• ▸Ask for short written decision records from week one; they are what the second engineer inherits.