21 October 20258 min read
The usual advice to a non-technical founder is to find someone technical to do the interview, which is correct and useless, because if you had that person you would not be reading this. The more useful version is narrower: there are parts of this assessment you can do better than most engineers, parts you cannot do at all, and a cheap way to buy the second set for about an hour.
Worth saying first: you are not trying to establish that someone is a strong engineer in the abstract. You are trying to establish that they can do the specific work you have, and will tell you the truth about it while they do. Those are largely non-technical questions.
What you can assess directly
Four things, and they predict more of the outcome than most people expect.
- Whether they can explain their own work to you. Not simplified into meaninglessness, but explained: what the problem was, what they chose, what it cost.
- What they ask you. Good engineers interrogate the requirement before estimating it. Someone who accepts a two-sentence brief and quotes a number has told you something.
- How they handle not knowing. Ask about something outside their area and watch whether they say so plainly or start generating fog.
- What they regret. Everyone with real experience has a decision that went badly. A candidate with no such story either has not shipped much or is managing you.
None of this requires reading code, and all of it is hard to fake for forty minutes.
The explanation test, run properly
Pick one thing on their CV and ask them to walk you through it as if you were a new joiner on the business side. Then ask a follow-up they cannot have rehearsed: what would you do differently now, and what was the part that took longest for reasons nobody expected.
You are listening for structure. A strong answer moves from problem to constraint to choice to consequence, and includes at least one thing that went wrong. A weak answer is a list of technologies. If you find yourself unable to summarise the story afterwards in three sentences, that is a real finding, not a failure of your own understanding.
The estimate conversation
Describe a piece of work you actually need. Ask how they would approach it and what would make it take twice as long. The second half is the whole question.
Experienced people name specific risks: the data is probably messier than described, the third-party API may not support what the feature assumes, the existing code in that area might not have tests. Inexperienced or careless people give you a duration and a reassurance. You do not need to evaluate the technical accuracy of the risks to notice whether any were named.
What you cannot assess, and should stop pretending to
You cannot judge whether their code is any good, whether their architectural instincts are sound, or whether the approach they described is the obvious one or an eccentric one. Personal charm, fluent English and confidence will not substitute here, and they are exactly the qualities that will mislead you if you try.
This is a real gap and it has to be filled by someone else. The good news is that it takes one hour, once, per shortlisted candidate.
Who to borrow, and how to brief them
Ranked roughly by how much you should trust the result: an engineer you know socially who has no stake in the outcome; a fractional or interim technical lead paid for a couple of hours; an engineer at a friendly company, offered the same favour in return; a contractor hired specifically to run technical interviews.
Brief them in writing, briefly. Tell them the work the person will actually do, what your existing system is, and the one question you most want answered. Then ask for the output in a specific shape: would you hire this person for this work, what are they weak at, and what would you watch in the first month. Without that shape you get a rating out of ten, which is not usable.
The provider's own senior engineer can join the call and is often genuinely helpful, particularly on stack-specific detail. Just hold the obvious point in mind: they are not neutral, and their assessment should be treated as an input rather than the verdict.
Reading a work sample without reading code
If you receive a repository or an exercise, there are things you can see. Is there a README explaining how to run it and why it is built that way? Are there tests at all? Is the commit history a sequence of intelligible steps or one commit called final? Did they write down what they would do with more time?
None of these prove the code is good. All of them show whether the person communicates about their work in writing, unprompted, when no one is watching. Over a remote engagement across time zones, that habit matters roughly as much as the code does.
The failure mode to guard against
Non-technical assessors systematically over-reward fluency. The candidate who talks well, agrees readily and never says a discouraging word interviews beautifully and is often the weaker hire, because the qualities you enjoyed in the interview are the ones that will hide problems from you later.
A blunt correction: at least once in the conversation, propose something slightly wrong about your own product or plan and see whether they push back. The person who disagrees politely with the person about to hire them is showing you the single most valuable behaviour you can buy remotely.
Then treat the first month as the real interview
No interview process fully substitutes for working together, and yours is thinner than most, so build the follow-up in deliberately. Agree a small, real, finishable piece of work for the first two weeks with a clear definition of done, and a written check-in at the end of the first month covering what shipped and what got in the way.
Structure that as a fair, paid trial with symmetric exit terms rather than an unpaid audition, and both sides get an honest answer early. Where you are hiring through a provider, the same applies with one addition: agree up front what replacement looks like, so that a mismatch is a scheduling problem rather than a negotiation.