When you cannot read code, the interview feels like a test you are unqualified to grade. You ask your prepared questions, they give confident answers, and you have no reliable way to tell a strong engineer from a good talker. So you fall back on gut, or on how impressive the resume sounds, and you hope. There is a better signal available to any founder, technical or not, and most people ignore it: the questions the candidate asks you.
A senior engineer's questions reveal how they think in a way their answers cannot. Answers can be rehearsed. The questions someone reaches for, unprompted, in the last ten minutes of a conversation, expose what they actually care about and whether they understand the job they are interviewing for. You do not need to read a line of code to evaluate this. You just need to know what good questions sound like and to leave real room for them.
Great engineers interrogate the business, not just the tech
The most reassuring thing a first-engineer candidate can do is ask sharp questions about the business. Who are the customers. How do you make money. What happens if the current plan does not work. How much runway is there, honestly. These are not off-topic questions from someone who should be asking about your stack. They are the exact questions of a person who understands that a first engineer's job is to keep a company alive, not to write elegant code in a vacuum.
An engineer who only asks about technology, which framework, what does the architecture look like, what is the test coverage, is telling you something too. Not that they are bad, but that they may see this as a coding job rather than a company-building one. In a first-hire seat that gap matters enormously, because the person who does not care whether the product finds a market will happily build the wrong thing beautifully. The candidate who asks what you would do if the next raise does not come is already thinking like an owner.
Watch for questions about failure and tradeoffs
Strong engineers are drawn to where the bodies are buried. They ask what has broken before, what the worst part of the codebase is, what decision you most regret, where the technical debt is heaviest. This is not negativity. It is how experienced people assess real risk, and it is the same instinct that makes them good at the job: they go looking for the failure modes before they commit.
They also probe tradeoffs rather than accepting your framing. If you describe a plan, a great candidate pushes on it. What did you consider and reject. Why this order. What are you optimizing for at the expense of what. A candidate who accepts everything you say without friction is either being polite or is not the senior operator you need. You want the person who, kindly, disagrees with you in the interview, because that is the person who will save you from an expensive mistake in month four.
The questions that should make you nervous
Just as revealing are the questions that are missing or wrong. A candidate for a first-engineer role who asks only about hours, process, and how much oversight they will get is telling you they want structure you do not have. Someone who asks nothing at all, or produces the same three generic questions anyone would ask any company, has not engaged with what makes your situation specific. That incuriosity does not improve after they join.
Be a little wary, too, of the candidate whose every question is about title, equity percentage, and reporting lines before they have shown any interest in the actual problem. Compensation questions are legitimate and you should welcome them, but the sequence tells you something. The engineer who spends forty minutes fascinated by the problem and five minutes on terms is oriented differently from the one who leads with terms and never gets curious about the work. Both exist, and for a first hire the first kind is worth far more.
Make room for the signal
None of this works if you talk for the whole hour. The most common way founders throw away this signal is by filling every minute with their own pitch and questions, then tacking on a rushed any questions for me as the meeting runs out, when the candidate is tired and just wants to be polite. Deliberately leave fifteen unhurried minutes at the end and treat what they do with it as data, not as a formality.
You can even prompt it honestly. Tell them you want them to interview you, because a first engineer is a two-way bet and you would rather they find the deal-breakers now. Then watch. The ones who take that seriously and dig in are showing you exactly how they will engage with your product and your customers. This pairs naturally with the rest of a non-technical founder's toolkit, and it is why I lean on borrowed expertise and structured signals in how to interview a senior engineer when you cannot read code. It also sets up the last check, because the themes a candidate probes in the room are the same ones worth confirming with the reference questions that actually tell you something.
Frequently asked questions
What questions should a strong engineering candidate ask me?
The reassuring ones are about the business and about risk: who the customers are, how you make money, how much runway there is, what has broken before, and what tradeoffs your current plan makes. These show the candidate thinks like an owner, not just a coder.
Is it a bad sign if a candidate only asks about the tech stack?
Not disqualifying, but a yellow flag for a first-engineer role. It can mean they see this as a coding job rather than a company-building one. A first hire needs to care whether the product finds a market, not only whether the architecture is clean.
What questions from a candidate should worry me?
Questions focused mainly on hours, oversight, and rigid process suggest they want structure an early startup cannot provide. So does asking nothing, or only generic questions, which signals a lack of curiosity that rarely improves after hiring.
I am non-technical. Can I really evaluate a senior engineer this way?
Yes. Evaluating the quality of a candidate's questions needs no ability to read code, only knowing what good questions sound like and leaving real time for them. Pair it with reference checks and a borrowed technical read. If you want a second opinion on a candidate, book a call.