Coding Interview Approach: You Started Coding. You Already Lost.
- Jumping to code immediately scores a Communication 2 on the Google rubric, a clear negative signal before you've written a single line
- The first five minutes generate more rubric material than any other phase, covering communication and problem-solving before code exists
- Successful candidates wait until roughly 27% through the interview (about 12 minutes in a 45-minute session) before running their first test
- Three steps before coding: restate the problem out loud, narrate a brute force with its complexity, then commit to a direction the interviewer can push back on
- Priors are sticky: an interviewer who watched you skip clarification reads every later bug as a judgment failure, not a normal engineering mistake
- The feedback form needs quotes: "typed for 25 minutes and got it working" gives the interviewer nothing to write; "identified the O(n²) case and pivoted" is a sentence worth filing
The problem hit your screen. Your hands went to the keyboard. The interviewer made a note.
Not a good one. Your coding interview approach just cost you points before you typed a single character.
The First Five Minutes Are the Whole Game
Your 45-minute interview front-loads the signal. The first five minutes set the interviewer's prior about your engineering judgment, and that prior colors everything that follows.
The feedback form has four dimensions: algorithms, coding, communication, and problem-solving. In the first five minutes, you have no code. You literally cannot score coding points yet. But you can score communication and problem-solving points by asking smart questions and thinking out loud. When you skip to the editor instead, you're donating the highest-ROI window of the interview to the "please hire me, I type fast" strategy. It never works.
What the Interviewer Is Already Writing
When a candidate opens an editor immediately, one thought runs through the interviewer's head:
This person hasn't asked about constraints. They don't know if the input is sorted. They're about to build the wrong thing and not know it for fifteen minutes.
That's a negative prior. And priors are sticky. They're the most annoying kind of sticky, too, like a git blame that follows you everywhere. Every bug you hit later gets read as "see, should have clarified." Every pause gets read as "lost." The interviewer who watched you think before typing reads those same bugs as normal engineering.
The candidate who clarified first made mistakes that look like execution. The candidate who jumped to code made mistakes that look like judgment.
One of those ends with a job offer.
The Rubric Has an Actual Score for This
The Google engineering rubric gives Communication a 2 out of 4 for candidates who "jump to coding without exploring the problem." A 2 is a clear negative signal. The kind that makes a hiring committee say "I'm not sure about this one" and nobody pushes back because nobody else is sure either.
You: "It's a sliding window, I got this, easy." You, twelve minutes later: "Oh god. Switch cases are functions now."
Successful candidates don't run their first test until about 27% through the interview. For a 45-minute session, that's roughly 12 minutes of clarifying, thinking out loud, and sketching an approach before a single line executes.
The number isn't magic. What fills those 12 minutes matters: questions that expose constraints, a narrated approach the interviewer can push back on, and a shared understanding of what "done" looks like before you start building. Read more about what specifically goes into the feedback form and you'll see why the pre-code phase generates so much of it.
You're in a Conversation, Not a Test
Most engineers frame the interview as "solve this problem in 45 minutes." That framing is why they fail. With that frame, thinking out loud feels like falling behind. Every second not typing feels wasted. You end up racing a ghost.
The correct frame: you're having a technical conversation, and the code is the conclusion.
Your interviewer isn't grading the answer. They're grading the reasoning. They need material to write in the feedback form. "Candidate identified that the naive O(n²) solution would time out and immediately discussed an O(n log n) approach using a sorted structure" is a sentence worth writing. "Candidate typed for 25 minutes and got a working solution" gives them nothing to quote. Nothing quoted means nothing to defend in the hiring committee meeting. And if there's nothing to defend, there's nothing to hire on.
Your Coding Interview Approach: Five Minutes Before You Type
Before writing a line of code, do three things out loud.
Restate and clarify. Paraphrase the problem back. Ask about constraints: Can values be negative? Are there duplicates? Is the input sorted? One well-placed question can save fifteen minutes of building the wrong thing, and it signals that you actually think before you build. That's what they're hiring for. These are the clarifying questions that actually matter.
Narrate a brute force. Say it out loud: "Nested loops, O(n²). Too slow for n=10^6. Let me think about what I can precompute." You just demonstrated constraint recognition and complexity awareness. That's a rubric point, scored before you've touched the keyboard.
Commit to a direction. Before opening the editor: "I think a sliding window works here because the subarray property is monotonic." If you're wrong, the interviewer redirects you now, not after twenty minutes debugging something that was never going to work. The earlier the redirect, the more time you have. Time is the only resource you can't get back.
Five minutes. Then code.
The best interviewers describe the same thing from strong-hire candidates: "They asked a few questions, talked through their approach, and the code almost wrote itself." The code wasn't the impressive part. The reasoning before it was.
SpaceComplexity runs voice-based mock interviews where you practice exactly this: the clarification, the narration, the approach discussion that LeetCode grinding never touches.