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.
