What I Would Fix First in Problem Interviews (Technical Founders)

If a technical founder is going to fix one habit in their problem interview process, the single highest-leverage change is this: stop solutioning during the call.

That is the change. Most other improvements follow from it. Most of the bad outcomes from technical-founder interviews trace back to it.

Why This Is the Bottleneck

Technical brains are built to solve problems. The instant a problem appears, the brain reaches for an architecture. This is genuinely useful most of the time. In a problem interview, it sabotages the conversation.

The moment you start designing aloud, three things happen. The interviewee politely engages with your design. The questions shift from "what did you actually do" to "what would my idea fix." And you stop hearing the parts of the problem that do not fit your design.

You can have great questions, great audience filter, great notes. If you solution out loud, the data is contaminated.

The Specific Discipline

When you have an idea about how to solve what you are hearing, write it down silently. Do not say it. Keep asking about the past. Keep asking what they did. Keep asking what broke.

The notes you take during a good interview will have two columns - what they said, and your private hypothesis about what to build. The interviewee should never see column two during the call. After the call, you can use column two as a starting point for the design. During the call, it does not exist for them.

Why Engineers Find This Hard

Engineers value being useful. Listening to a problem and offering a solution feels like the helpful thing to do. Sitting on the solution feels rude, almost negligent.

It is neither. The interviewee is not paying you for solutions. They are doing you a favor by sharing data. The polite thing is to receive the data without contaminating it. Your solution is irrelevant to them in this moment, and offering it actually wastes their time more than holding it.

The Cheap Test

After your next interview, look at your notes. Count how many times your notes describe what you said versus what they said. If the ratio is anywhere near even, you talked too much. The ratio in a working interview should be heavily skewed toward what they said.

If you find your own ideas in the notes, that is fine - but the ideas should appear after the interview, in a separate section, not interleaved with the interviewee's words. Interleaving is how you confuse signal with hypothesis.

What to Do When the Urge Hits

Have a stock redirect ready. When the interviewee says something that triggers your design instinct, instead of designing, ask, "before you got to that point, what were you actually trying to do?" Or: "tell me more about what you tried first." Both pull the conversation back to the past, where the data lives.

If you absolutely must share a thought, share it as a question. "If something existed that did X, would that have helped, or would the real problem still be Y?" That preserves the conversational shape - they answer about their experience, not about your idea.

What Happens When You Stop Solutioning

The interviews get longer. The interviewee fills the space you stopped occupying. You hear specific stories you would have skipped over. You capture vocabulary you would have missed. The patterns across calls get sharper because the conversations are no longer warped by your hypotheses.

Most importantly, you sometimes hear things that disconfirm your initial design. You did not invite them with leading questions. They emerged from the customer's own world. That kind of disconfirmation is gold and it only shows up when you are not pushing your design.

The One-Sentence Fix

If you remember one thing about technical-founder problem interviews, remember this: write your solutions in your private notebook, not into the conversation. Most other improvements follow from that single discipline.