Interview Questions a Non-Technical Founder Can Ask to Evaluate Developers (And What Good Answers Sound Like)

You're not going to catch a bad developer by asking them to reverse a linked list on a whiteboard, especially if you're not technical enough to judge the answer anyway. What you can catch, reliably, is bad judgment: the kind that shows up in how someone explains a decision, owns a mistake, or scopes a feature you describe to them in plain English. Below is a script of interview questions a non-technical founder can ask to evaluate a developer, in the order to ask them, with what a strong answer sounds like next to what should worry you.

This is written for the moment right before you hire: a candidate you sourced yourself, or a developer an outsourced partner has proposed to work on your project. Either way, you're the one in the room who can't read the code. You can still read the person.

Why you can't evaluate code, but you can evaluate judgment

Coding tests and whiteboard puzzles measure something real, just not the thing that predicts whether a hire works out. A developer who's great at algorithm questions can still ship features nobody asked for, miss deadlines without saying so until the day they're due, or disappear into technical decisions they never explain to you. One analysis of what actually predicts long-term success in grouping interview questions into company fit, self-learning, and teamwork found those three categories more predictive than coding challenges, and all three are things a non-technical founder can judge without writing a line of code themselves.

That's the shift this script makes. Every question below tests communication, honesty, accountability, or pragmatism, not syntax. You're not grading their code. You're grading how they think out loud, and whether you'd trust that thinking with your budget.

How to run the interview, step by step

For each answer, sort it into one of three buckets as you go: strong, mixed, or weak. Don't average them in your head at the end. A single weak answer on honesty or accountability should outweigh three strong answers on everything else.

1. Block 45 minutes, in one sitting

Don't split this across two short calls. You need to compare how someone answers question three against how they answer question six, and that comparison is harder to make across different days and different moods. Forty-five minutes is enough for six questions, follow-ups, and ten minutes at the end for their questions to you.

2. Decide you don't need a technical person in the room for this part

You don't. This list exists specifically so you don't need one for a first-round screen. If you later want someone to weigh in on a specific architectural choice, like whether a proposed tech stack is the right one for your scale, that's a narrower and more expensive ask, and it's covered later in this piece.

3. Ask: "Explain a recent technical decision you made, like I'm not technical"

This tests communication, which is the single most important skill you're hiring for, since you'll depend on it for the life of the relationship. A guide to interviewing developers without a technical background recommends exactly this kind of plain-language translation test as a baseline screen.

A strong answer picks a real decision, states the tradeoff in plain terms ("we could ship faster this way but it would cost us more to change later"), and doesn't reach for jargon to sound smart. A weak answer either buries you in acronyms, or oversimplifies to the point that you can tell there's no real tradeoff being admitted at all.

4. Ask: "Tell me about something you shipped that you knew wasn't perfect, and why"

One developer who screens candidates for a living argues the real risk is a founder who can't check the work, and warns against letting a candidate design their own evaluation criteria by only describing their successes.

A strong answer names something specific: a shortcut taken under a deadline, a piece of tech debt they accepted on purpose, and what it would take to fix it properly. A weak answer claims they don't ship imperfect work, or can't come up with an example at all. Nobody who has shipped real software is free of this, so an answer that dodges it is a bigger flag than an honest admission of a messy decision.

5. Ask: "Describe a time a non-technical stakeholder pushed back on your approach. What did you do?"

This tests whether they can be challenged by someone who doesn't share their vocabulary, which is exactly the dynamic you'll be in with them every week.

A strong answer shows they took the pushback seriously, either changed course and can say why, or held their ground and can explain the reasoning in terms you'd have understood at the time. Watch for two different weak answers here, not just one: dismissing non-technical input as something to manage around, or caving to any pushback just to avoid friction. Both mean you won't get honest pushback from them later, when you actually need it.

6. Hand them a real feature and ask: "How would you scope this, and what's the first thing you'd cut?"

Use an actual feature from your product plans, not a hypothetical. If you haven't put your requirements into writing yet, you need a brief to interview against before this step is worth much, because a vague prompt only produces a vague answer. Give the candidate a real product problem, not a hypothetical one, and watch whether they propose a solution or just agree to build whatever you described.

A strong answer asks clarifying questions before committing to anything, breaks the feature into phases, and names a specific piece they'd cut or defer if the timeline got tight. A weak answer agrees to build everything exactly as described, with no questions and no proposed cuts. That isn't confidence, it's a developer who hasn't scoped anything in their life, or one who'll tell you yes now and renegotiate the deadline later.

7. Ask: "How do you learn something you don't already know how to build?"

This is a self-training question, and it matters more than it sounds like it should: your product will eventually need something this person hasn't built before, and you want to know what happens then.

A strong answer names a specific recent example: a library, a pattern, or a tool they didn't know six months ago and now use regularly, plus how they got up to speed. A weak answer is vague ("I just figure it out") or implies they already know everything they'd ever need to build your product, which is a claim nobody competent actually makes.

8. Ask: "What would you want to know from me before giving me an estimate?"

This is the question that tells you whether you're about to get a real number or a guess dressed up as one.

A strong answer asks about your constraints: existing systems they'd need to work around, what "done" looks like for the feature, how firm your deadline is, and what you're optimizing for if something has to give. A weak answer hands you a number immediately, with no questions at all. Anyone who can price work without knowing the constraints is either guessing or padding the estimate to cover for not knowing.

A well-run shop can still move fast once it has those answers. At Appsoluty, tasks get estimated in hours before they're quoted at a dollar figure, billed at $70 an hour, so you see the projected cost before you commit to anything, and work usually starts within a few days of the first call once a short discovery phase is done.

9. Leave ten minutes for their questions, and pay attention to what they ask

What a candidate asks you, unprompted, tells you what they're optimizing for. Questions about your users, your constraints, or how success gets measured are a good sign. Questions only about hours, payment terms, and whether you'll sign off on things quickly are not disqualifying on their own, but they're worth weighing against everything else you just heard.

If an outsourced partner put this developer in front of you, not you

Everything above still applies, but the question underneath changes. You're not deciding "would I personally hire this person off the street." You're deciding "does the partner that staffed them do this consistently, for every developer they put in front of a client." That's a question about the partner's process, not just the person in the room.

Ask the agency directly how they vet the people they staff, and listen for specificity. A vague "we only work with vetted senior developers" is not an answer. A concrete one names the mechanism: at Appsoluty, for example, every subcontractor is someone the team has personally known and worked with for years, operates under an NDA and a framework agreement, and uses a company-issued machine, not a personal laptop with who-knows-what on it. That's the kind of detail that tells you whether "vetted" means a real process or a marketing word.

This is also where it's worth checking the partner's own track record before you get to this interview at all. If anything about how the engagement has been pitched to you feels off, before you even meet the developer, that usually shows up in red flags at the agency level, and they're worth ruling out first.

When it's worth paying for an hour of outside technical judgment

Most advice aimed at non-technical founders stops at "bring in a technical person you trust," offered as if it costs nothing and applies every time, without saying when it's actually worth the cost versus when the checklist above is enough on its own. It usually isn't free, and it usually isn't necessary for every hire.

Skip it when you're hiring for a single role, the work is a fairly standard build (a CRUD app, an integration, a typical mobile app), and your budget and timeline can absorb one bad month if the hire doesn't work out. This script is enough for that case.

Pay for an hour of outside judgment when you're choosing between genuinely different technical approaches you can't evaluate yourself (a build-versus-buy call, a choice of platform that's expensive to reverse), when the hire is meant to be a long-term technical lead rather than a single contributor, or when the budget on the line is large enough that a wrong call costs you more than the advisor's fee many times over. If what you actually need is ongoing technical judgment on every decision, not just a second opinion on one hire, that's a different and bigger decision than this interview, and it's worth thinking through separately rather than backing into it one hire at a time.

Red flags that end the interview early

Some answers are bad enough that you don't need to finish the script.

The candidate gets visibly irritated or condescending when you ask a "simple" question, instead of just answering it. They agree to an unrealistic deadline on the spot, without asking a single clarifying question first. They can't describe any way they check their own work before calling it done. They badmouth every previous client or employer, with nothing that sounds like their own responsibility in any of it. They're vague about who, specifically, would be working on your project, which matters more with an outsourced team than a solo hire: a team that can tell you exactly who touches your code, by role, is a different proposition than one that says "our team will handle it." Any one of these is reason enough to stop and move on to the next candidate.

Once you've made a hire, the interview script above stops being useful and a different set of problems starts, mostly around keeping the relationship on track week to week. That part has its own playbook, separate from anything covered here.

FAQ

Do I need a technical co-founder to do this?

No. Every question in this script is designed to be judged on communication, honesty, and reasoning, not on technical correctness you'd need a co-founder to verify. A technical co-founder solves a different problem (ongoing equity-level involvement in every decision), not this one.

How many questions is enough for one interview?

The six in the script, plus the time-budget and closing steps around them, are enough for a single 45-minute interview. Adding more dilutes your attention and makes it harder to compare answers against each other. If you want a second opinion, run a second interview with a different person on your side, rather than adding a seventh question to the same one.

What if I still don't understand the answer they gave me?

That's useful information on its own. A developer who can't restate a technical answer in a way you understand, after you've told them you're not technical, has failed the communication test even if the underlying decision was sound. Ask them to try again in different words before you move on, and watch whether they adjust or just repeat themselves louder.