Interviewing engineers when you're not technical
You can't judge the code. You can judge judgement, ownership and evidence, and you can borrow the rest.
By Macro Merge · · 5 min read
The short version
- 1You can't assess the code, but you can assess the person: how they make trade-offs, explain decisions and own outcomes.
- 2Borrow technical judgement for one structured round. Don't hand over the whole decision.
- 3Ask about real systems they built, what broke and who found out first. Specifics are hard to fake.
If you're a non-technical founder hiring your first engineers, the interview can feel like a test you aren't qualified to set. The candidate talks about architectures and frameworks, and you nod. Afterwards, you try to work out whether they were good or just confident.
Here's the reassuring part: you can assess more than you think. For the part you can't, you can borrow judgement without handing over the decision.
What you can assess yourself
You can't judge whether their code is good. You can judge most of what makes an engineer right for your company:
- How they make trade-offs. Do they ask about your customers, deadlines and budget before suggesting a solution?
- How they explain decisions. Can they make a technical choice understandable to you, without jargon and without talking down?
- Whether they own outcomes. When they describe past work, do they talk about what happened to the product and its users, or only about the technology?
- Evidence over adjectives. Can they point to things they built that are still running, and tell you what broke?
- Fit with your stage. Have they worked somewhere this small and unstructured before? Did they enjoy it?
None of these are soft extras. For an early hire, they often matter more than raw technical depth.
Questions that work, and what to listen for
“Tell me about something you built that's still in use. What broke after launch, and who found out first?” Listen for specifics: real systems, real failures and what they changed afterwards. Weak answers stay general or blame others. Strong answers often sound like “a customer told us before we noticed, so I set up alerts and...”
“What's a technical decision you'd make differently now?” Everyone has one. You're listening for honesty, and for reasoning about the situation at the time, not for a perfect record.
“Explain the hardest problem you solved last year, so that I understand it.” This tests communication directly. Did you understand it? Did they check whether you did?
“Here's a real choice we're facing. What would you need to know before deciding?” Use a genuine trade-off from your company. Good candidates ask questions first. Candidates who jump straight to an answer, or to their favourite technology, are telling you something.
“What would you not do in your first three months here?” Restraint is underrated. Someone who wants to rebuild everything immediately is a risk to a small company.
Confidence is easy to perform. Specifics are hard to fake.
Borrow technical judgement for one round
For technical depth, bring in someone who can judge it. The options, roughly in order of usefulness:
- An engineer you trust. An advisor, an investor's technical partner, or a senior engineer you know. Ask for one structured hour per finalist, and pay for their time if they aren't already committed to you.
- A structured technical assessment. A realistic task, or a guided conversation about a system the candidate built, run by someone technical against criteria agreed in advance.
- References from technical colleagues. A former tech lead or peer, asked specific questions (more on that below).
Agree in advance what the technical round is for. “Can this person design and run our backend without supervision?” is a better question than “Are they good?”. Then make the final decision yourself, using everything you've learned. The technical round is one input. You're the one who knows what the company needs.
A simple interview structure
- Your conversation, 45 minutes. The situation, what they want next, how they make decisions. The questions above.
- Technical depth, 60 to 90 minutes. With your borrowed expert. A walk through a system they built, or a realistic exercise.
- A working session, 60 minutes. A real problem from your company, discussed together. You see how they think, and they see how you work.
- References, two or three calls. Including at least one person who managed them and one technical peer.
Four steps, finished within two weeks. Good engineers have options, and a long process loses them.
What to avoid
- Puzzles and trivia. Brain teasers and quiz questions found online test interview preparation, not the job.
- Judging by confidence or jargon. The most fluent talker isn't necessarily the strongest engineer.
- Long unpaid take-home tasks. Two days of unpaid work filters out people who are employed and busy, who are often the people you want. Keep tasks to a few hours, or pay for them.
- Copying a big company's process. Six rounds and a hiring committee make sense at scale. At your stage, they mostly slow you down.
- Letting the technical expert decide alone. They can tell you whether someone is capable. They often can't tell you whether someone is right for your situation.
Getting real answers from references
References are most useful when you ask questions that can't be answered with “they were great”.
- “What did you rely on them for?”
- “What would you not give them to do?”
- “How did they handle a decision they disagreed with?”
- “Would you hire them again for a small, early team? Why?”
Listen for hesitation as much as for words. Ask the candidate to suggest referees, and also ask to speak to a specific person who came up in their stories.
Where we fit
When we introduce engineers, each one comes with a note on why they fit your brief and what to test in your interviews. For technical roles, candidates also do an AI-run interview built around your brief, and a person reviews every result. It doesn't replace your judgement. It gives you something specific to probe, which is exactly what non-technical founders usually lack.
If this is your first engineering hire, read what matters in a first engineer too.