How to interview developers when you're not technical

You can interview developers well without being technical: judge what you can (communication, ownership, honesty and product sense) and get help with what you can't (code quality). Run a short screening call, a walk-through of something they built, a review by a technical person, a paid trial on a real task and two reference calls.

This guide covers the interviews themselves. For timing, the profile to look for and what to pay, start with my guide to hiring your first developer.

What you can judge without reading code

More than you'd think. In a team of one to five engineers, hires rarely fail because someone can't code at all. In my experience they fail because the person doesn't own problems, doesn't tell you bad news early, or builds what's interesting instead of what users need. You can assess all of that yourself:

• Communication: can they explain a technical decision to you in plain English, without fog or condescension?
• Ownership: do they describe outcomes they were responsible for, or tasks they were handed?
• Judgment: do they talk about trade-offs, or present every choice as obvious?
• Honesty: do they admit what went wrong and what they don't know?
• Product sense: do they ask about your users, your business and your runway?

What you can't judge: code quality, architecture, security habits, and whether their estimates are realistic. That's the technical reviewer's job, so plan for one from the start.

How to interview developers: a five-stage process

Each stage filters for something different. Cut candidates as soon as you have a clear no; it's kinder to everyone than dragging a doubtful candidate through a paid trial.

Aim to go from first call to offer in two to three weeks. Strong developers usually have other options, and a slow process loses them.

Questions to ask a developer, and what good answers sound like

Use these across the screening call and the walk-through. You're listening less for a “right” answer than for specifics: names, numbers, decisions and consequences. In my experience, vague answers to specific questions are the clearest warning sign of all.

Ask every candidate the same core questions, and score each answer from 1 to 3 straight after the call, before impressions blur. It's the simplest way to compare people fairly when you can't judge the technical detail.

Ownership and communication

• “Tell me about a product you helped build that real people used. What was your part?” Good: a clear line between their work and the team's, real users, and what happened after launch. Warning sign: “we” all the way through with no “I”, or only projects that never had users.
• “Explain how that product works as if I were a new customer. Now explain it as if I were joining your team.” Good: two different, clear explanations pitched at the right level. Warning sign: jargon both times, or impatience with the request.
• “Tell me about a time you disagreed with a product decision.” Good: they raised it with reasons, offered an alternative, then committed once the decision was made. Warning sign: they quietly built it their own way, or they've never disagreed with anything.
• “How do you keep a non-technical manager informed?” Good: short written updates, regular demos, risks flagged early. Warning sign: “they can look at the commits.”

The walk-through: what did you build, what trade-offs did you make, what broke?

Ask them to share their screen and show a real product, live if possible. Then work through these:

• “What problem did this solve, and for whom?” Good: they start with the user and the problem. Warning sign: they start with the framework.
• “What was the hardest trade-off you made, and what did you give up?” Good: something concrete, like choosing a simpler design to launch sooner and knowing which shortcut would need fixing later. Warning sign: “there weren't really any trade-offs.”
• “What broke in production, and what did you do?” Good: a specific incident, how they found out, how they fixed it and what they changed so it wouldn't happen again. Warning sign: nothing ever broke, or it was always someone else's fault.
• “If you rebuilt it today, what would you change?” Good: specific improvements with reasons. Warning sign: “I'd rewrite it all in a newer framework,” with no reason beyond fashion.

Working style

• “How would you estimate this feature?” Describe a real one from your roadmap. Good: clarifying questions, a breakdown, a range and stated assumptions. Warning sign: an instant single number.
• “How do you use AI coding assistants, and how do you check what they produce?” Good: specific uses, everything reviewed and tested, and they can explain every line they ship. Warning sign: they treat generated code as finished work.
• “What do you need from me to do your best work?” Good: clear priorities, quick decisions, access to users and uninterrupted time. Warning sign: nothing at all.
• “Why did you leave your last two roles?” Good: honest, specific reasons that don't all blame other people. Warning sign: a pattern of short stints they can't explain.

How do you check a developer's code if you can't read it?

You borrow someone who can. It's the step founders are most tempted to skip, and the one that protects you most. Your reviewer can be a trusted senior engineer you pay for a few hours, a technical advisor, or a fractional CTO; vetting candidates is a core part of what a fractional CTO does for non-technical founders. It shouldn't be the candidate's friend, or anyone who would end up reporting to the candidate.

Give the reviewer the role spec, the candidate's code samples (public repositories or work they're allowed to share) and, later, the trial output. Ask them to look at:

• Is the code readable and organized, so another engineer could take it over?
• Are there tests where they matter, such as payments, permissions and data handling?
• Are there obvious security mistakes, like passwords or keys stored in the code?
• Does the commit history show steady, explained work, or one giant upload at the end?
• Can the candidate explain their choices in a 45-minute technical conversation?

Then ask for a plain-English verdict: hire, don't hire, or hire if one specific concern checks out. A reviewer who says “it's fine, I guess” hasn't finished the job.

How to run a paid trial task

A trial shows you how someone works, which no question can. Design it carefully:

• A real feature or fix from your backlog, small enough to finish in two to five days.
• Written acceptance criteria that describe “done” from the user's point of view.
• One or two deliberately open questions, to see whether they ask or guess.
• Work in a repository your company owns, under a short agreement assigning the code to you.
• Payment at their normal rate, agreed before they start.
• A demo to you at the end, and a code review by your technical reviewer.

While it runs, keep a simple scorecard:

• Questions: did they ask sensible questions before starting, or guess at the open points?
• Updates: did they keep you informed without being chased?
• Candor: did they flag problems early, or did you discover them at the demo?
• Result: does it meet every acceptance criterion when you click through it yourself?
• Code: what did your reviewer think of the work under the surface?

If you've never written acceptance criteria, the approach in how to scope an MVP works just as well for a trial task.

How to check a developer's references

Call, don't email, and ask the candidate for a former manager and a peer who worked closely with them. Then ask:

1. How did you work together, and for how long?
2. What were they best at?
3. What did you have to manage around?
4. How did they handle a missed deadline or a production problem?
5. Would you hire them again? For what kind of role?
6. Is there anything I should have asked but didn't?

Listen for hesitation and faint praise. “They were fine” is not a yes. An enthusiastic, specific “I'd hire them again tomorrow” is what you're hoping for.

Red flags when interviewing developers

• They can't explain their own past work clearly, even with simple follow-up questions.
• Every failure in their story was someone else's fault.
• They want to rebuild your product in their favorite stack before they understand it.
• Instant, confident estimates without a single question.
• No curiosity about your users, your business or your runway.
• They refuse any form of assessment. Declining unpaid test projects is reasonable; refusing both a paid trial and a code review is not.
• Pressure to decide fast, or unusual payment requests such as large sums up front.
• They can't explain parts of the code they submitted for the trial.
• Their account of past roles doesn't match what references tell you.

The bottom line

You don't need to read code to interview developers well. Judge communication, ownership and honesty yourself with specific questions, hand the code to a technical reviewer, and make the final call on a paid trial and two honest reference calls.

Once you've hired, the job shifts to giving them clear outcomes and a weekly rhythm, which I cover in managing developers as a non-technical founder.