A non-technical founder interviewing a developer often tries to do the one thing they cannot, judge technical skill, and neglects the things they genuinely can assess. That gets it backwards. You will not fake your way into evaluating code quality, and pretending to leaves you fooled by whoever sounds most confident. The better approach is to split the interview: assess the things you are actually good at judging, how clearly someone communicates, how they solve problems, whether they are honest, and get technical help for the part you cannot. You do not need to become an engineer to interview one well. You need to know which parts are yours to judge and which are not.
Key Takeaways
- Stop trying to judge code quality; you cannot, and pretending gets you fooled.
- Assess what you genuinely can: communication, problem-solving, and honesty.
- Get technical help, an advisor or partner, for the actual skill evaluation.
- Communication is itself a core, judgeable trait in anyone you will work with.
Interview for What You Can Actually Judge
There is a lot in a developer worth evaluating that has nothing to do with reading code, and those are precisely the things a non-technical founder can assess well. How clearly does this person explain a technical topic to you, without jargon or condescension? That communication ability is not a soft nicety; it is essential for someone you will work with closely, and being unable to explain their work simply is a real warning sign. How do they reason through a problem when you pose one? You can follow the shape of good problem-solving, curiosity, structure, asking clarifying questions, even without judging the technical specifics. And are they honest and straightforward, or evasive and overselling? You can read that as well as anyone. Interview hard for these, because they are yours to judge and they matter enormously.
Get Help for the Part You Cannot
The one thing you genuinely cannot do is evaluate whether the person can actually write good code, and the answer is not to fake it but to get help. Bring in a technical advisor, a trusted engineer friend, a fractional CTO, or hire through a partner whose vetting includes real technical assessment, so the skill evaluation is done by someone qualified (staff augmentation for non-technical founders). Combining your read on communication, problem-solving, and honesty with an expert's read on the technical ability gives you a complete picture that neither could produce alone. The mistake is trying to cover the technical gap yourself; the fix is covering it with someone who can.
| You can judge | Get help to judge |
|---|---|
| Clarity of communication | Actual code quality |
| Problem-solving approach | Technical depth |
| Honesty and directness | Engineering judgment |
| Whether you can work with them | Whether they can build it well |
A Concrete Version
You are a non-technical founder interviewing a developer. The failing approach: you try to assess their technical skill directly, ask questions you do not fully understand, and end up impressed by the most confident talker, who may or may not be any good. The working approach: you spend your part of the interview on what you can judge, whether they explain things to you clearly, how they reason through a problem you describe, whether they come across as honest, and you have a technical advisor separately assess the actual engineering ability. You come away with a real read on the person and an expert read on the skill, and the confident-but-shallow candidate who would have fooled you gets caught by the technical check.
The Honest Counterpoint
Splitting the evaluation is the right approach and depends on having access to trustworthy technical judgment, which not every founder does. If you truly cannot find any technical advisor, hiring becomes riskier, and leaning on a vetting partner whose assessment you trust becomes more important, or bringing on a fractional technical leader before you hire. It is also true that communication and problem-solving, while genuinely judgeable and important, are not a full substitute for technical ability, a wonderful communicator who cannot code is still the wrong hire. So judge what you can rigorously, get real help for what you cannot, and do not let a candidate's strength in the judgeable areas paper over an unverified gap in the technical ones.
The Bottom Line
Interviewing a developer when you are not technical means giving up on the thing you cannot do, judging code, and doing well the things you can: assessing communication, problem-solving, and honesty, which are genuinely yours to evaluate and which matter a great deal. Get technical help, an advisor or a vetting partner, for the actual skill evaluation rather than faking it and getting fooled by confidence. Combine your read on the person with an expert read on the code, and you interview a developer effectively without pretending to a technical judgment you do not have.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
