What Working Problem Interviews Look Like (Non-Technical Founders)

Working problem interviews look almost trivial when they go well. There is no clever trick on display. There is just one person asking another person to describe their week, and the magic is that the founder learned something they did not expect to learn.

Here is what a working interview looks like when run by a non-technical founder, broken down into the moments that matter.

It Starts With a Boring Setup

A good interview opens with the founder making the conversation feel low stakes. Something like, "I am researching how people handle X right now, I am not selling anything, I just want to learn from people who have lived through it." That single sentence does a lot of work. It signals you are not pitching, which lowers the other person's guard. It signals you respect their time and their experience. It signals you will be listening more than talking.

The interviews that go badly almost always start with the founder describing the product or apologizing for not being technical. Neither belongs in the opening. The opening is just permission to ask questions.

It Lives in Specific Stories

The single best signal that a problem interview is working is that the other person is telling you about a specific moment. Not in general, not abstractly, not "people like me usually" - but "last Tuesday I was trying to" or "a few months ago we had this thing where."

If they slip into the abstract, your job is to gently pull them back. "Can you walk me through the last time that came up?" or "Do you remember a specific instance of that?" or "What did you actually do that day?" Stories carry data. Generalizations carry feelings.

It Has Pauses

One of the most underrated tools in problem interviews is silence. After someone finishes a thought, count to three before responding. Almost every time, they will keep going. The most useful sentence in the interview is usually the one they offer after that pause.

Non-technical founders often find this easier than engineers do. Engineers want to fill silence with a follow-up technical question. You can just sit. The other person will reward the patience with more honesty.

It Surfaces Workarounds

If the problem is real, there is almost always a workaround. A person doing a thing the hard way. A spreadsheet held together with macros. A weekly hour spent copying data between two tools. A junior employee whose job is essentially to be the connective tissue.

When you hear about a workaround, slow down. Ask how often, ask how much it costs, ask who does it. The presence of an ugly workaround is one of the strongest signals you can find. A real workaround means a real problem.

It Sometimes Kills the Idea

You will know a problem interview is working when, occasionally, you walk out of it feeling deflated. Maybe the person told you the problem is not as urgent as you thought. Maybe they said the existing tool you assumed everyone hated is actually fine. Maybe they had no opinion at all.

That feeling of deflation is a feature. The interviews that disconfirm your assumption are the most valuable, because they save you the months of building you would have done otherwise. Founders who never feel deflated by interviews are usually founders who are not really listening.

It Ends With Patterns, Not Decisions

One interview is a data point, not a verdict. A working process produces patterns over ten to fifteen calls. The same workaround keeps coming up. The same vocabulary keeps repeating. The same trigger keeps showing up at the start of every story.

When you start to see those patterns, you have something real. Not a guarantee, but a foundation that does not depend on your hope. That is what a working problem interview process produces. Not certainty, but warranted confidence.

What It Feels Like in Your Notebook

After a good interview, your notes are full of quoted phrases, specific situations, named tools, and a few things that surprised you. After a bad interview, your notes are full of paraphrases, your own ideas, and confirmations of what you already believed.

The fastest test for whether your interviews are working is to look at your notes from the last three calls. If they could have been written without the calls, the calls were probably not working. If they could not have been, you are doing the work right.

The Non-Technical Edge

Non-technical founders consistently report that interviewees feel comfortable telling them more than they would tell a technical co-founder. There is no architectural opinion to defend. No reflexive solutioning. No urge to debate the technical setup.

This is one of the genuine advantages of being non-technical in this specific activity. The interviews you run can be richer, more honest, and more discovery-oriented than the ones a technical founder would run. Use that. The data quality you produce here is your edge.