How to Approach a Coding Interview Problem (Before You Touch the Keyboard)

The problem lands. Your brain fires. You recognize the pattern. Your hands move.

Twelve minutes later you've written clean, well-structured code for the wrong problem. The interviewer watched the whole thing happen in real time and said absolutely nothing, because they're not supposed to redirect you unprompted. The clock ran out. You failed a round you were probably qualified for.

Two moves prevent this. They take about two minutes total. Most candidates skip both of them.

The Twelve-Minute Mistake

Here's what panic coding looks like from the outside: the interviewer reads the problem, you nod, and your fingers are already moving. You found the pattern. You know this one. You're in flow state.

What you don't know is that the input is guaranteed to be non-empty (you're handling the empty case), the values are always positive (your negative-check branch is dead code), and the interviewer wanted an in-place solution (you allocated a new array). None of this was explicitly stated. None of it needed to be. You just had to ask.

The interviewer watches this play out. They can see what you're building. They know it's not quite right. But under most interview protocols, they don't redirect you unprompted, especially early. Their job is to observe, not guide. So they observe.

The average wrong turn costs eight to ten minutes. A clarifying question costs thirty seconds.

The StackOverflow experience, in one image. In interviews you're playing both roles at once: the person with a question and the one who immediately starts building the wrong thing.

Under pressure, the brain substitutes confidence for preparation. You feel like you're moving fast when you're actually moving wrong. The fix is a physical one, and we'll get to it.

Two Moves, Done in Order

It's not complicated. Two moves, done in order, every time.

Move one: ask at least one clarifying question. Not to stall. Not to look thoughtful. To catch the assumption that would have killed your solution.

The useful questions are structural. Can the input be empty? Can values be negative? Can there be duplicates? Is the array sorted? Is there a space constraint? One of these takes thirty seconds to ask and might completely change which algorithm is correct. You're not asking because you don't know how to solve it. You're asking because every production engineer alive has been burned by an assumption that seemed obvious and wasn't.

Pick the one that matters most for the problem type. For a two-pointer problem, ask if the array is sorted. For a tree problem, ask if it can be null. For a graph problem, ask if there can be cycles. One question. Targeted. Then move on.

Move two: state your approach before writing a single line. Not a monologue. Thirty seconds. Something like: "I'm thinking a sliding window here. O(n) time, O(k) space where k is the window size. The invariant is the window shrinks from the left when the sum exceeds the target. Does that sound right before I start coding?"

Then pause. Let them react. If they have a concern, you want to hear it now, before you've written anything. If they say "go ahead," you've just gotten confirmation. Either way, you've earned credit for the approach separately from the code.

That's it. Clarify, narrate, code. Two minutes before you type anything. Every round, every time.

Why This Signals Seniority

Junior engineers optimize for looking fast. Senior engineers optimize for not shipping the wrong thing.

No one with real production experience codes blind. When you've deployed a bug at 2am because you assumed the user ID was always an integer, you stop assuming. When you've spent a week refactoring because you built to the wrong spec, you start asking. The instinct to clarify before you build isn't caution. It's scar tissue.

When a strong candidate asks a clarifying question in an interview, the interviewer doesn't think "they don't know the answer." They think "this person has been burned before." That reads as experience.

The experience: you learn to ask after learning not to. Interview habit-building just compresses the timeline.

The plan narration does something separate: it gives the interviewer something to react to. If your approach has a flaw, they can redirect you before you've written anything. That's a better outcome for both of you. If it's correct, you've shown your reasoning explicitly, which earns you credit on the problem-solving dimension even if you hit a bug later.

Google's Communication rubric scores a 2, which is below expectations, for candidates who "immediately jumped into coding." That's not a minor note. It goes into the write-up that gets read by the hiring committee. The feedback literally says "jumped to code without clarifying." That's a documented signal that follows you through the process.

A candidate who starts typing immediately gives the interviewer nothing to work with for the first ten minutes except a stream of code they haven't narrated. There's no signal there. There's no evidence of thought. Just output.

The Bug Tax

Clarifying and narrating don't just prevent mistakes. They buy back time when things go wrong.

Everyone hits a bug in the last fifteen minutes. Not everyone has something to anchor to when it happens.

When you've narrated your plan, you have an agreed-on invariant to debug against. "The logic here should match what I described: the window shrinks from the left when this condition fails." That's a real anchor. You can trace back to it. You can show you understand where the actual problem is.

Candidates who jumped straight to code have nothing. They're debugging something they never fully articulated, under time pressure, in front of someone who's watching. That's the hardest kind of debugging. The interviewer sees a candidate scrambling.

The other effect is forgiveness. When you narrated the approach and then hit a bug, the interviewer has already seen the problem-solving. They know you understood the structure. The bug becomes a fixable detail rather than evidence that you don't know what you're doing. The write-up reflects that difference: "had a clean approach but hit an off-by-one at the end" lands completely differently than "seemed confused about the approach throughout."

That gap, between a known approach with a bug and a mysterious mess, is the gap between an advance and a no-hire on a close call.

Making It Automatic

The habit fails under pressure if it's just an intention. Intentions don't survive adrenaline. The habit needs a physical trigger.

Here's the one that works: when the problem finishes being read, put your hands in your lap. Don't let them touch the keyboard. Read the problem twice. Ask one question. Then move your hands back up to code.

The physical act of moving your hands creates a mandatory pause. You can't type with your hands in your lap. The pause is the whole point. Most candidates fail this because their hands are already moving while their brain is still recognizing the pattern. The physical constraint breaks the automatic response.

For the plan narration, use a fill-in-the-blank template so you're not inventing the structure under pressure:

"My approach is [algorithm/data structure].
Time complexity: [X]. Space complexity: [Y].
The core idea is [one sentence].
Does that make sense before I start?"

Fill in the blanks. Don't improvise the frame. The template keeps you from rambling and covers exactly what interviewers need to hear. If you can't fill in the time and space complexity, that's a signal you don't understand the approach well enough to start coding it yet.

The strongest candidates don't have this habit because they're senior. They're senior, in part, because they built this habit.

You build it in practice, not by reading about it. Knowing the two moves is not the same as having them run automatically when you're nervous and the clock is on screen. That gap between knowing and doing is closed by reps under realistic conditions.

The place to build it is during clarifying questions practice specifically, not general problem solving. You need to practice the habit in the same context where it needs to show up.

The Real Reason Interviewers Care

There's a meta-point worth saying out loud.

Interviewers are not just evaluating whether you can solve the problem. They're evaluating whether you're safe to hire. That means: what does working with you look like? Do you ship things without understanding the requirements? Do you go quiet and produce output with no signal about your thinking? Do you need to be managed closely or can you run independently?

The clarify-then-narrate habit answers all of these questions favorably, before you've written a line of code. It shows you don't build until you've confirmed what you're building. It shows you communicate what you're thinking. It shows you're someone who could be trusted to work on a real system without supervision.

The two minutes you spend upfront aren't just about preventing the wrong solution. They're you showing the interviewer what kind of engineer you are.

That's a much better use of two minutes than diving straight into a HashMap you might not need.

---

The fastest way to build the habit for real is reps under pressure that feel like the actual interview. SpaceComplexity runs voice-based, rubric-scored mock interviews that specifically flag when you skip the clarify-and-narrate step, so you can fix it before it costs you an offer.