Developer interview questions for non-technical founders (and what good answers sound like)

If you cannot read code, interviewing a developer feels like negotiating in a language you do not speak. Most non-technical founders respond in one of two ways: they outsource the decision to a friend who codes, or they hire whoever sounds most confident.

Both can work. Both often fail.

The good news is that most of what predicts success on a small team is not about code at all. It is about how someone thinks, communicates, and takes ownership. You are well placed to judge those. Here are twelve questions that help, grouped by what they reveal.

Past work: have they actually shipped?

1. “Walk me through something you built that real people use.”

Strong answer: specific product, specific users, what they personally built, and what happened after launch. Red flag: only side projects, tutorials, or vague team credit (“we built a platform for…“).

2. “What broke after it launched, and what did you do?”

Everything breaks after launch. People who have shipped have stories. Strong answers include how they found out, how they fixed it, and what they changed so it would not happen again. Red flag: “Nothing major really broke.”

3. “If you rebuilt that project today, what would you do differently?”

Strong answer: concrete technical and product regrets. Shows reflection and growth. Red flag: “I’d do it the same way.” Or blaming the previous team for everything.

How they work: will you understand each other?

4. “How would you break down a feature like [a real feature from your roadmap]?”

Pick something real. Strong answers start with questions for you (who uses it, what happens when X), then split the work into small, shippable steps. Red flag: an estimate before any questions.

5. “How do you tell someone a task will take longer than expected?”

Strong answer: early, with a reason, and with options (“I can ship the basic version Friday, or the full one next Wednesday”). Red flag: they have never had to, or they wait until the deadline.

6. “What do you do when the requirements are unclear?”

Strong answer: ask, write down their assumption, confirm it, then build. Red flag: “I just build what makes sense.” Sometimes fine. Often expensive.

Quality: will it keep working?

7. “How do you know your code works before you hand it over?”

Strong answers mention testing it themselves, automated tests for important paths, and checking on a real device or browser. Red flag: “QA will catch it,” on a team with no QA.

8. “How do you use AI coding tools, and how do you check what they write?”

Almost every developer uses them now, which is fine. Strong answers describe reviewing every line, keeping changes small, and specific times the AI was wrong. Our post on hiring a Cursor developer goes deeper on this. Red flag: “It’s pretty accurate now, I don’t need to check much.”

9. “Explain how [a feature from their past work] works, as if I’m a new customer.”

This one is a gift for non-technical founders. You are testing whether they can explain technical things in plain language, which you will need from them every week. Strong answers are clear, patient, and free of jargon. Red flag: jargon, condescension, or frustration.

Ownership: will they act like it’s their product?

10. “Have you deployed code to production yourself? Walk me through how.”

Strong answer: a clear description of their deploy process and how they check it worked. Red flag: someone else always did that part. On a small team, there is no someone else.

11. “Tell me about a production problem you caused.”

Not one they fixed. One they caused. Strong answers are honest and specific, and they focus on what changed afterwards. Red flag: they have never caused one. That is either untrue or means they have not shipped much.

12. “What would you need from me in your first week?”

Strong answers: access, a walkthrough of the product, priorities, the people to ask. Shows they have started somewhere new before and know what makes it work. Red flag: “Nothing, I’ll figure it out.” Independence is good. Not needing any context is not realistic.

Listen for these patterns

Across all twelve questions, a few patterns matter more than any single answer:

• Specifics over generalities. Names, numbers, dates, tools.
• “I” when it was them, “we” when it was the team. Both, honestly assigned.
• Comfort saying “I don’t know.” People who never say it will not tell you when they are stuck.
• Questions back to you. Curiosity about your users and business is one of the best predictors we see.

Interviews are the start, not the decision

Even a great interview is a weak predictor of real work. The strongest signal comes from watching someone work on a real task for about a week, paid, after an NDA. You do not need to read the code to judge that. Did it work? Was it on time? Did they keep you informed without being chased?

That is how every placement at Hiring.co starts. Every candidate has already cleared a live technical review and a reference check. Then the paid trial week happens in your repo, on your task. You can interview the candidate first or skip straight to the trial. If a hire does not work out later, we replace them at no extra cost.

The full process is on how we vet developers and our vetting page. If you would rather not run this alone, book a call. I will scope the role with you, and we will introduce candidates who fit, usually within a week.