How to Interview Engineers When You Aren't One

One of the most common questions I get from non-technical founders is some version of: "How am I supposed to hire engineers when I cannot evaluate their code?" It is a fair question. The conventional advice — "have a technical friend do a whiteboard interview" — is both inaccessible (not every founder has the right friend) and wrong (whiteboard interviews are bad predictors of real performance).

This article is the version of the answer I give when a founder asks me seriously. A non-technical founder can absolutely run an effective engineering interview. You cannot assess technical depth in the same way an engineering peer can, but you can assess most of what actually matters: judgment, communication, ownership, pragmatism, and cultural fit with your company. Those predict performance better than a live-coding exercise.

Here is how to do it.

The principle: hire for judgment, outsource the skill check

You can reliably evaluate someone's judgment and communication without being technical yourself. You cannot reliably evaluate their code. So the structure is simple: you run the interviews that assess judgment and communication, and you hire someone (a fractional CTO, a trusted engineering friend, an external technical reviewer) to run a focused skill check in a single 60-minute slot.

This is not a workaround. It is actually a better process than a founder who is a mediocre engineer trying to run a technical interview. You get rigor on the parts you are good at, and expertise on the parts you are not.

The four interviews a non-technical founder should run

These are the four interviews I recommend a non-technical founder personally conduct. Together they take about 3 hours of candidate time and give you enough signal to make a confident decision, with the technical interview added by your technical helper.

Interview 1: The story interview (30 minutes)

Walk through the candidate's last 2–3 roles. For each role, ask four specific questions:

"What was the project you are most proud of, and what was your specific role in it?"
"What did not go well, and what would you do differently?"
"Who did you work with most closely, and what did that relationship look like?"
"Why did you leave, or why are you thinking about leaving?"

What you are listening for: specificity. A strong candidate talks about concrete details — names of systems, specific decisions, trade-offs they made. A weaker candidate speaks in generalities. "We built a platform" is weak. "I was responsible for the billing service, which handled about 2 million transactions per month, and the hardest decision was whether to use Stripe Billing or build our own subscription logic" is strong.

Red flag: the candidate blames all failures on other people or circumstances. Every senior engineer has broken things. The ones who have grown can tell you exactly how.

Interview 2: The scenario interview (45 minutes)

Give the candidate a realistic scenario from your business and walk through it with them. It does not need to be code. It needs to be a decision.

Examples of good scenarios:

"We have 200 customers and one of them, who represents 30% of our revenue, has asked for a feature that would require us to add a new data model that no other customer would use. How would you think about that?"
"Our API response times have slowly climbed from 200ms to 800ms over the last three months. Nobody is complaining yet, but it is noticeable. How would you approach finding and fixing the cause?"
"We are about to ship a new feature. On staging, it works. On production, one of our three largest customers hits an error that we cannot reproduce. What is your first hour?"

What you are listening for: how they think. Do they ask clarifying questions before diving in? Do they consider multiple approaches? Do they identify the trade-offs rather than jumping to one answer? Do they talk about how they would involve other people?

You do not need to know whether their proposed solution would technically work. You need to know whether their thought process is organized, pragmatic, and honest about what they do not know.

Interview 3: The craft interview (45 minutes)

Ask the candidate to walk you through a project from their past in real detail. Tell them beforehand: "Pick any project from the last 2 years that you are allowed to discuss, and be ready to go deep. I want to understand what it does, why you built it that way, and what you would change."

Then you sit back and ask the 5-year-old's favorite question: why.

"Why did you pick that database?" "Why did you structure it that way?" "Why did you not do X instead?"

You are not judging whether their answers are correct. You are judging whether they have answers. A senior engineer has reasons for every major decision, even if the reason is "it was the default and we had bigger problems to solve, but in hindsight I would have done Y." A candidate who cannot explain their own choices is either junior pretending to be senior, or senior in title only.

Interview 4: The values interview (30 minutes)

This one is pure culture and mutual-fit. Talk about your company honestly — the stage, the chaos, the ambiguity, the things you are bad at. Ask them how they feel about each. Ask them what would make them thrive and what would make them miserable.

The goal is not to sell. It is to find out whether they actually want this job. Engineers who accept startup offers they should not have accepted are the source of many founder heartbreaks. A 30-minute honest conversation up front saves months of regret.

What you cannot evaluate, and how to cover it

You cannot evaluate how well they code. You cannot evaluate whether their knowledge of your specific stack is deep enough. You cannot confidently tell a strong senior engineer from a mediocre one on pure technical skill.

For those, you need a technical interviewer. A fractional CTO running one 60-minute session can tell you most of what you need to know on the technical side. The session should include a short live code walkthrough (not a whiteboard problem — a review of code the candidate has written and is willing to discuss) and a focused technical discussion on the candidate's depth in the areas your product actually needs.

If you do not have someone who can do this, hire one for the hour. I have done these sessions for non-technical founders many times and the ROI is absurd relative to the cost of making the wrong hire.

The traps to avoid

A few patterns I see non-technical founders fall into that hurt hiring outcomes.

Being intimidated by technical language. Some candidates will bury you in jargon to seem impressive or to obscure weakness. If you do not understand something, say so and ask them to explain it like you are smart but not technical. A strong engineer will do this cleanly. A weak one will be unable to and the fog will clear.

Hiring on "feel" without structure. Your gut is useful but not sufficient. Use a consistent set of questions across candidates so you can compare them. Write down the answers. Rate them on the same dimensions.

Skipping reference checks. Reference checks are the highest-signal tool in hiring and founders skip them because they feel awkward. Do them anyway. Ask the references specifically: "Would you hire this person again?" and "What would they need to work on to reach the next level?" Listen for hesitation.

Hiring for pedigree. A resume full of big tech companies does not predict startup success. Some of the worst startup hires I have seen came from the biggest names. Evaluate the person, not the logo.

Letting the timeline rush you. Every founder has felt the pressure to hire "by end of month" because there is too much work. Every founder who has hired under that pressure has regretted at least one of those hires. If the right person is not in the pipeline, extend the search instead of lowering the bar.

Scoring and decisions

After interviews, sit down and score the candidate on five dimensions: judgment, communication, ownership, craft, and mutual fit. Scale 1–5 per dimension. Make the decision on total and on variance — a candidate who is 5, 5, 5, 5, 2 may be a hard no depending on which dimension the 2 is on. Values and ownership 2s are usually disqualifying. Craft 2s can sometimes be worked around.

Then compare across candidates you have actually interviewed, not against an abstract ideal. "Best candidate I have seen for this role" is the realistic standard.

Counterpoint: your gut matters, just calibrate it

Structure matters, but so does instinct. If you have interviewed 20 candidates and your gut says candidate #17 is the right one but the scorecard says #14, take your gut seriously and interrogate the scorecard. The structure is there to catch the biases you cannot see, not to override the well-calibrated intuition you have developed through the process.

As you do more interviews, your gut gets better. Early on, lean on the structure. Later, trust the blend.

Your next step

If you have an engineering hire coming up, write down the four interviews above as your interview plan. Add a technical round run by someone else. Use the same questions for every candidate. You will be amazed how much clarity structure provides when the candidates are different but the questions are constant.

Where I come in

I run the technical round of engineering interviews for non-technical founders as a common part of my fractional CTO engagements. Usually it is a single 60-minute session plus a 20-minute debrief with the founder, and it is often the deciding factor in the hire. Book a call if you have an engineering hire coming up and want a technical co-pilot on the interviews.