How to Run Technical Interviews When You're Not Technical

You're doing $40K MRR, you need to hire a developer, and you have no idea how to tell a good one from a bad one.

This is one of the most common spots bootstrapped founders get stuck. You can evaluate a salesperson. You can evaluate a designer. But a developer sits across from you and starts talking about microservices and you nod along and hope they're not running a scam.

The good news: you don't need to understand code to hire a good developer. You need to understand whether they can solve your actual problems. That's a different skill, and you already have it.

Here's the framework I use with every founder who comes to me after a bad hire.

The Real Problem with How Most Founders Interview Developers

Most non-technical founders do one of two things:

They hand the process to a technical friend or contractor to screen candidates. The technical person evaluates correctly for pure coding skill, but not for whether someone can function well in a bootstrapped startup with no team, unclear requirements, and a runway deadline.

Or they find a list of interview questions online ("What's the difference between SQL and NoSQL?") and quiz the candidate on trivia they found five minutes before the call. The candidate answers fine, gets hired, and three months later nothing is shipping.

Neither approach tests what you actually need to know.

What You Actually Need to Know

When you're a non-technical founder hiring your first developer (or replacing one who quit), you need answers to four questions:

1. Can they communicate clearly with a non-technical person?
2. Do they default to shipping or to over-engineering?
3. Can they work independently and tell you when they're blocked?
4. Have they solved problems that look like yours before?

None of these require you to know what a REST API is.

The Interview Framework

Round 1: The Problem Walk-Through (30 minutes)

Before the call, pick a real feature you need to build. Something your product actually needs in the next 90 days.

On the call, describe it in plain English the way you'd describe it to a user: "We need users to be able to invite their team members and set what they can see and do."

Then ask: "How would you approach building this?"

You're not evaluating whether their technical approach is correct. You're evaluating:

• Did they ask clarifying questions before jumping to an answer?
• Did they explain their thinking in terms you could follow, or did they retreat into jargon immediately?
• Did they mention tradeoffs ("we could do this the fast way or the right way")?
• Did they give you a rough time estimate, or did they dodge the question?

Good candidates treat this as a conversation. They ask about your existing setup, what you're built on, how many users you have now. They want context before they give you an answer.

Bad candidates launch into a solution in the first 60 seconds without asking a single question. They're performing expertise rather than solving your problem.

Round 2: The Past Work Deep Dive (30 minutes)

Ask them to walk you through the last production system they built or maintained. Not a side project. Actual software that real users depended on.

As they explain it, ask:

• "What would you do differently if you started over?"
• "What broke in production that you didn't expect?"
• "How did you handle that?"

You're listening for self-awareness and ownership. Developers who've shipped real software have war stories. They'll tell you about the time the database migration went wrong at 2am, or the feature that seemed simple but took three times longer than expected.

Developers who haven't shipped much real software will give you a very clean story with no friction in it. Real software has friction.

Also ask: "Who else was involved? What was your specific contribution?"

This matters because many developers list projects they touched briefly as projects they "built." You want someone who can point clearly to what they owned.

Round 3: The Scenario Questions (20 minutes)

These are short hypotheticals framed around your actual situation. Adjust them to match your business.

On scope and communication: "It's Thursday. You're supposed to ship a feature on Friday. You realize Wednesday night it's going to take until Monday. What do you do?"

Good answer: They tell you Thursday morning, explain what's left, and give you options. Do you cut scope to ship something Friday, or delay until Monday?

Bad answer: They work through the weekend and surprise you Monday with a late delivery.

On prioritization: "You have three tasks this sprint. Two are features customers asked for. One is cleaning up some old code that isn't causing problems yet. How do you approach this?"

Good answer: They do the customer-facing work first. They might mention they'd flag the tech debt for later. They understand that shipping value is the job.

Bad answer: They spend days on the cleanup because it was "bothering them." Or they never mention the tech debt at all, because they don't think about it.

On working with you specifically: "You get a task from me and the requirements are unclear. What do you do?"

Good answer: They ask questions before they start building. They probably have a habit of summarizing what they understood before beginning.

Bad answer: They start building what they think you meant and show you something you didn't want.

Round 4: The Reference Call

This is not optional.

Call at least one person they actually reported to. Not a peer. Not a friend who worked alongside them. Someone who assigned them work and depended on the output.

Ask three things:

1. "If you were hiring for a role they could do well, would you hire them again?"
2. "What kind of environment do they do their best work in?"
3. "What's something they struggle with?"

Listen for hesitation on question one. Listen for specificity on question three. "They need clear requirements" is useful. "Oh, they're great" is not.

What to Look For in a Take-Home Task

A small take-home exercise is worth doing, but only if it's scoped to real work. Not a trick puzzle. Not a generic algorithm challenge.

Give them something your product actually needs: "Here's a description of a small feature. Show me how you'd approach it. You don't need to build the whole thing, but show me your thinking."

You're evaluating:

• Did they ask clarifying questions before starting, or did they just build?
• Is the output documented well enough that you could hand it to someone else?
• Does their solution match the scope of the problem, or did they over-engineer it?

A developer who builds a perfectly architected system for a task that needed a working prototype has told you something important about how they'll spend your runway.

The Red Flags That Shouldn't Need a Technical Expert to Spot

These show up in conversation, not in code review:

• They can't explain what they built in terms a non-developer would understand. If they can't explain their own work clearly, they won't be able to work with you effectively.
• They've never shipped something that failed. Everyone has deployed something that broke. If they haven't, they haven't shipped much.
• They get defensive when you ask "what would you do differently?" Self-awareness is a sign of experience.
• They talk about what they want to build rather than asking about what you need. Some developers have a strong preference for certain tools or architecture and will try to apply them to your problem regardless of fit.
• They can't give you a straight answer on timeline. "It depends" is always partly true, but a good developer can bracket the estimate. "Somewhere between two days and two weeks depending on X" is useful. "It's really hard to say" is not.

When to Bring in Technical Help

You can run this process yourself for most early hires. But there are times when you need a technical eye on the actual work.

If the role requires a specific technology your product depends on heavily (database architecture, payment systems, security-sensitive infrastructure), you want someone to actually look at their code or ask more specific technical questions.

If you're hiring someone to inherit a large existing codebase, someone should read through that codebase with them and see how they respond to unfamiliar code.

If the hire is a senior lead who will make architectural decisions that will cost you a lot to reverse later, the conversation framework above isn't enough on its own.

These are cases where a technical advisor earns their cost in one bad hire avoided.

The Hire You're Actually Making

When you're bootstrapped and hiring your first or second developer, you're not hiring a code-writing machine. You're hiring a technical partner who will operate with significant autonomy, communicate with you constantly, and make hundreds of small decisions every week that you won't be in the room for. For a full walkthrough of the hiring process from job post to onboarding, see how to hire your first developer when you're non-technical.

That's a different hire than a developer joining a team of twenty at a funded company with a tech lead reviewing every PR.

The process above is designed for that reality. It won't find you a developer who's perfect on a whiteboard. It will find you one who can actually function in your business.

If you're heading into developer interviews and want a technical advisor in the room, or if you've already made a hire that isn't working out, that's exactly what I do.

Book a call and we'll figure out your situation.