Hiring your first developer is the most expensive decision a non-technical founder makes blind. Not because the salary is large — because you have no way to check the work, no way to check the interview, and no second engineer to catch the first one's blind spots. You are betting the technical core of your company on a person you can't technically evaluate, using a process the candidate often understands better than you do.
I've sat on the other side of that table for a long time — running technical interviews, hiring engineers, and occasionally being the person a founder calls a year later because the first hire was wrong and now there's a codebase nobody else can touch. I've also been brought in before the hire, to sit on the founder's side and read the signal they can't. This article is the version of that conversation I have most often: the small number of questions that, asked properly, sort the engineer who thinks about your business from the one who only thinks about code.
The framing matters. These are not puzzles. They are not whiteboard tricks. A question is only useful in a first-developer hire if it surfaces a trait you can't fake and can't see on a CV — judgment, ownership, the ability to operate where the answer isn't clean. Five of them do most of the filtering.
Before the questions: stop letting the candidate run the interview
The single most common failure mode I see isn't asking the wrong questions. It's not asking any real ones — because the founder has quietly handed the technical evaluation to the candidate.
It looks reasonable from the inside. You're not technical, so you ask the developer to "walk you through their experience," they talk fluently for forty minutes about microservices and Kubernetes and a migration they led, you understand maybe a third of it, it sounds impressive, and you make an offer. You didn't evaluate them. You let them perform, graded the performance on confidence and vocabulary, and called it an interview.
Fluency is not competence. The candidate who can narrate an architecture in confident jargon and the candidate who can actually build and maintain it are overlapping but very different populations, and from outside the field you cannot tell them apart by listening. Worse, the failure is asymmetric: the smooth talker who can't deliver interviews better than the quiet engineer who can, because interviewing-as-performance is a different skill from the job.
So the meta-rule, before any specific question: the interview has to extract signal you can read, not a performance you have to trust. The five questions below are built for exactly that — every one of them produces an answer a non-technical founder can grade, because the signal is in the shape of the answer, not the technical detail.
And the anti-pattern worth naming loudest: do not outsource the whole technical interview to "a developer friend" who'll spend an hour on algorithm puzzles, and do not let the candidate propose the evaluation themselves. Both hand the steering wheel to the person being tested. This is one of the highest-leverage places a founder gets a fractional CTO in the room — someone whose entire job in that hour is to read the candidate you can't.
Question 1: "Tell me about the last time you shipped something you knew wasn't perfect — and why you shipped it anyway."
This is the most revealing question in the set, and it's not close.
What you're listening for is trade-off literacy — does this person understand that engineering is the art of deciding what not to build, on a deadline, with the consequences in mind? A developer who ships a real product makes that call every week: this edge case is rare enough to handle later, this code is ugly but we'll be lucky if this feature survives the month, this needs to go out Friday so the polish waits.
A strong answer sounds like a story with a reason attached. "We hardcoded the tax rates for launch because we only had two countries and getting the dynamic system right would've cost two weeks we didn't have — I left a comment and a ticket, and we did it properly once we added the third country." That's an engineer who thinks in cost and consequence, who knows that done-and-shipped often beats perfect-and-late, and who leaves a trail so the shortcut doesn't become a landmine. That is exactly the person you want owning a young codebase where everything is a trade-off.
The red flag is the candidate who can't answer it — or who hears "wasn't perfect" as an attack and insists they never ship anything below their standard. That's not high standards. That's someone who either hasn't shipped under real pressure, or who can't distinguish between "this is wrong" and "this is fine for now," which means they'll gold-plate the unimportant and miss the deadline that mattered. Perfectionism reads as virtue and behaves as a liability when you have one engineer and a runway.
Question 2: "Walk me through a bug that took you more than a day to find. What was it, and how did you finally catch it?"
Notice what this is not: it's not "reverse a linked list" or "find the missing number." Those test whether someone crammed algorithm puzzles, which correlates with almost nothing about maintaining your software. Real engineering is mostly debugging — sitting inside a system that's misbehaving for reasons that aren't in any documentation — and that's the skill you actually need to see.
You're listening for method under uncertainty. The good answer has a shape: here's what I observed, here's what I assumed, here's how I tested the assumption, here's how the assumption was wrong, here's what was actually happening. It's the narrative of someone who narrows a problem systematically — forms a hypothesis, checks it, discards it, moves the boundary — rather than someone who flails, changes random things, and waits to get lucky.
The detail is the tell. Real war stories have texture: the timestamp that didn't line up, the webhook that fired three times, the cache that was serving stale data for one user in a thousand. A candidate recounting a genuine multi-day hunt cannot help but include the specifics, because that's where the days went. A vague answer — "it was just a tricky bug, I eventually figured it out" — usually means there wasn't one, which means this person hasn't lived in production long enough to have scars, or doesn't reflect on their own process. For a first hire who'll be alone with your system when it breaks at 9pm, that reflection is the job.
Question 3: "Something you estimated as two days took two weeks. What happened — and what did you tell the people waiting on it?"
This question does double work. The first half tests whether they understand why software estimates blow up; the second half tests how they communicate when reality diverges from the plan — which, for a solo first hire reporting straight to you, matters as much as the code.
On the estimation half, a strong answer shows someone who's internalized that the happy path is a third of the job — they'll talk about the unknown-unknowns they hit, the third-party API that lied, the legacy column nobody understood, the scope that crept one reasonable request at a time. They know overruns are usually structural, not a personal failing, and they don't pretend they could have foreseen the unforeseeable.
But the half that really filters is the communication. When did they tell you it was slipping? The answer you want is: early, and with a revised plan attached — "by day two I could see the integration was fighting us, so I flagged it that afternoon and gave you a new range." The red flag is the engineer who went quiet, kept heads-down hoping to claw it back, and surfaced the bad news on the original due date when it was too late to react. With a team, a silent slipper gets caught in standup. With your first hire, nobody catches it but you, and only after the deadline's gone. Communication under slippage isn't a soft skill here — it's the early-warning system you're hiring instead of a manager.
Question 4: "When have you had to work in code you didn't write and couldn't ask the author about? How did you approach it?"
Almost every interview question implicitly imagines greenfield — a clean slate where the candidate builds their vision from zero. Your reality will not be greenfield for long. Within months, your first developer will be maintaining code they wrote and half-forgot, integrating a vendor's undocumented API, and inheriting whatever an agency or a previous contractor left behind. Comfort with other people's code is one of the most underrated traits in a first hire, and almost nobody screens for it.
You're listening for someone who treats unfamiliar code as a system to be understood before changed, not as a mess to be ripped out and replaced. The strong answer has patience in it: I read it first, I traced one real request end to end, I made the smallest change that worked and watched what it broke, I resisted the urge to rewrite until I understood why it was the way it was. That's an engineer who knows that working legacy code encodes hard-won knowledge — every weird branch is usually a bug someone already paid for — and that respecting it is cheaper than relearning the same lessons. I've written about why the instinct to rewrite is usually wrong, and the same temperament shows up here in miniature.
The red flag is the candidate whose answer to inherited code is always "I'd rewrite it." For a first hire that instinct is genuinely dangerous, because they'll soon be the legacy — and the founder who hires a serial rewriter ends up paying for the same features two and three times while the actual business waits.
Question 5: "Tell me about a time you didn't know the answer in front of a client or your team. What did you do?"
The first four questions probe judgment about code. This one probes character around not knowing — and for a first hire who is, by definition, your only source of technical truth, how they behave at the edge of their knowledge determines whether you can trust anything they tell you.
The answer you want is calm and honest: "I said I didn't know, told them I'd find out by end of day, and I did." That's someone secure enough to admit a gap, which means that when they do tell you something confidently, you can believe it. The whole value of a technical hire to a non-technical founder rests on this — you are going to take their word for things you can't verify, and an engineer who says "I don't know, let me check" is the only kind whose "yes, that's fine" is worth anything.
The red flag is the candidate who, in the story or in the room, cannot say "I don't know." They bluff, they deflect, they answer a slightly different question they do know — and you can sometimes catch this live by gently pushing past the edge of their expertise and watching whether they admit the boundary or paper over it. An engineer who fakes certainty is the single most expensive hire a non-technical founder can make, because you'll architect real decisions on confident guesses, and you won't find out they were guesses until the bill arrives. Intellectual honesty isn't a nice-to-have in this seat. It's the load-bearing trait.
The anti-patterns, stated plainly
Because they're worth naming on their own:
- Hiring off a list of technologies on the CV. "Knows React, Node, AWS, Postgres" tells you what they've been near, not what they can build or maintain. The buzzword list is the easiest thing to pad and the least predictive thing on the page.
- Whiteboard algorithm puzzles. Reversing a binary tree under pressure measures a skill your first developer will use approximately never. It selects for recent interview-cramming and against the experienced engineer who's been shipping, not grinding LeetCode.
- Letting the candidate define the evaluation. "How would you want to be assessed?" sounds enlightened and hands the test to the person taking it. You'll get the assessment they're best at, which is the opposite of what you need.
- Outsourcing the whole interview to one developer friend for an hour. A favour-based screen is better than nothing, but it's usually an hour of puzzles by someone who isn't accountable for the outcome and won't be there in week three when the hire matters.
Why this is really a CTO problem, not an HR problem
Here's the honest framing, and the filter.
Every one of these five questions has a right and a wrong answer — but you only know which is which if you can read the signal, and reading the signal is exactly the thing a non-technical founder doesn't yet have. You can ask "tell me about a bug that took a day" perfectly and still mis-grade the answer, because the texture that separates a real war story from a plausible fiction is itself technical judgment.
That's the real reason hiring your first developer is dangerous solo. It's not that the questions are secret. It's that the grading requires the very expertise you're hiring to acquire — a chicken-and-egg problem that the first hire, uniquely, can't solve for you, because the first hire is the thing being graded.
This is the most concentrated, highest-leverage thing I do as a fractional CTO: sit on the founder's side of one or two interviews, ask the calibrated version of these questions, and read the answers you can't. One wrong first hire sets a young company back a year — a codebase only they understand, an architecture chosen for their convenience instead of your business, a culture of confident guessing. The cost of getting a second opinion on that hire is a rounding error against the cost of getting it wrong.
And the filter, plainly: if you're about to hire your first engineer and there is genuinely no technical person on your side of the table — not the candidate, not a vendor selling you something, not a recruiter paid on placement — you are flying blind on the one decision that's hardest to reverse. That's the exact seat I'm describing. The honest move is to put someone technical in the room before the offer, not a year after, when the rescue costs ten times more than the second opinion would have.
Takeaways
- Don't let the candidate run the interview. Fluency in jargon is a performance, not proof of competence — build questions that produce signal a non-technical founder can grade.
- Q1 — the deliberate shortcut. Trade-off literacy beats perfectionism in a one-engineer codebase. Listen for cost-and-consequence reasoning; the "I never ship anything imperfect" answer is a red flag.
- Q2 — the multi-day bug. Real engineering is debugging, not algorithm puzzles. Real war stories have texture; vague ones usually didn't happen.
- Q3 — the blown estimate. Tests both why software overruns and, more importantly, when they tell you it's slipping. A silent slipper is dangerous when they're your only hire.
- Q4 — inherited code. "I'd rewrite it" is a red flag for a first hire — they'll soon be the legacy. You want patience with code they didn't write.
- Q5 — not knowing. An engineer who can say "I don't know, let me check" is the only one whose "yes" you can trust when you can't verify it yourself.
- The anti-patterns: CV tech-lists, whiteboard puzzles, candidate-defined evaluations, and one-hour favour screens all hand the steering wheel to the wrong person.
- The filter: grading these answers requires the expertise you're hiring to get. If there's no technical person on your side of the table, put one there before the offer — not after the wrong hire.
