The Two Tests Running in a Coding Interview: Why You Need to Explain Your Thinking

Two candidates interview for the same role. Candidate A goes quiet for twelve minutes and produces a flawless O(n log n) solution with no bugs. Candidate B says "let me think out loud here," walks through an O(n²) brute force first, explains why it's suboptimal, then half-optimizes it in the time remaining. Small bug at the end.

Candidate B gets the offer.

This happens all the time. It catches everyone who trained purely on algorithm correctness, because they never learned to explain their thinking during a coding interview. The reason: there are two evaluations running in parallel, and most candidates only know about one.

The Interviewer Is Running Two Simulations at Once

The first simulation is obvious: can you solve technical problems? Can you recognize patterns, reason about complexity, write working code?

The second simulation is: what would it be like to work with you on a real engineering problem?

That second one isn't a soft-skills afterthought. It asks whether you can decompose problems clearly, surface your assumptions so teammates can catch them, take feedback without shutting down, and stay coherent at 2am when production is on fire and clarity matters more than elegance.

Interviewers are proxy-testing collaboration. The interview room is a compressed simulation of what a real design discussion looks like. When you work in silence, you're telling them exactly what it's like to work with you on a hard problem. The answer they hear is: unpredictable.

What the Rubric Actually Asks For

Google's coding rubric scores four dimensions: Algorithms, Coding, Communication, and Problem-Solving. Each is 1-4.

Look at what a 4 in Problem-Solving requires. The candidate "had enough time to discuss trade-offs, related problems, and alternatives while asking clarifying questions." Not just a correct solution. Alternatives. Trade-offs. Discussion. You cannot score a 4 in Problem-Solving by going silent and producing perfect code. The rubric requires narration.

The Communication rubric is just as explicit. A score of 2 describes a candidate who "jumped right into coding without properly explaining themselves." A 1 is someone who "stayed silent for much of the interview."

At Meta and Amazon, testing is its own dimension. The question isn't "did you write correct code" but "did you articulate edge cases before running your solution." Silence fails this by default.

The rubric was never just checking correctness. Every dimension above a 2 requires you to surface reasoning that isn't visible in the code itself.

The Write-Up Problem Nobody Talks About

Most candidates never think about what happens after they leave the room. The interviewer writes a detailed report, often several paragraphs, that gets read by a hiring committee who has never met you. That committee makes the final call.

Think about what Candidate A's interviewer can write: "Candidate solved the problem correctly and wrote clean code."

That's it. Twelve minutes of watching someone type. One sentence.

Now think about what Candidate B's interviewer can write: "Candidate immediately clarified input constraints. Proposed a brute force approach, explained its O(n²) time complexity, then iterated toward a more efficient solution while narrating the reasoning. Acknowledged the edge case in the final implementation and described how they'd fix it with more time. Communication was clear and organized throughout."

The hiring committee reading report A has nothing to evaluate except a result. Report B gives them evidence of how the candidate thinks, how they handle complexity, whether they're coachable, and what it would be like to sit next to them in a design review. They can advocate for Candidate B. They can only acknowledge Candidate A.

A silent optimal solution gives the interviewer table stakes. A well-explained suboptimal solution gives them sentences.

LinkedIn post about a candidate who made a sharp joke about infinite stacks in an interview and got away with it

The interviewer who can quote you has so much more to work with than the one who watched you type for twelve minutes.

The Data Is More Nuanced Than You've Heard

Interviewing.io's analysis of over 100,000 technical interviews shows candidates scoring 4-4-2 (strong coding, strong problem-solving, weak communication) advance to onsites 96% of the time. Candidates scoring 3-3-4 (adequate coding, adequate problem-solving, strong communication) are three times more likely to be rejected.

Read that carefully. It isn't saying that talking a lot outweighs technical skill. It's saying weak technical skill with polished communication doesn't save you.

But the 4-4-2 vs 3-3-4 comparison obscures where communication actually does the work. Both are easy cases. The interesting ones are borderline: a 3-3-3, a 4-3-2, a candidate who finished with a bug. These are where the committee debates, and the debate turns on the quality of the write-up, which turns entirely on how much the candidate surfaced during the interview.

When interviewers talk about "the trajectory question," they mean: would this person have solved it with ten more minutes? They can only answer that if you showed them your thinking. A black box that produced a result tells them nothing about trajectory.

What a "3 in Algorithms" Actually Means

The Google rubric defines a 3 in Algorithms as: "Candidate solved the problem but not optimally." Hire-eligible. Not a rejection.

The difference between a 3 and a 2 isn't the final code. It's whether you demonstrated that you understood the problem space, reasoned about trade-offs, and showed awareness that optimization exists even if you didn't complete it.

An interviewer who watches you work through brute force and say "I know this is O(n²) and for large inputs we'd want something better, probably using a hash map to get O(n) lookups, let me sketch that" has everything they need to write a 3. An interviewer who watches you silently code a slightly-off optimal solution has very little, because they don't know if you understand what you did.

Awareness of your solution's limitations is worth more than an accidentally correct solution you can't explain.

Two Common Mistakes That Flip the Script

The first is staying silent when you're stuck. Silence under pressure is the highest-risk behavior in a coding interview. The five signals interviewers score you on include coachability and edge case awareness, neither of which is visible when you say nothing. When you say "I'm wondering if this subproblem has overlapping structure, which would suggest dynamic programming" you give them something. They can redirect you if you're wrong. They can write "showed methodical exploration of approaches" if you're right. Silence gives them nothing.

The second mistake is narrating every line of code. "Now I'm writing the for loop. Okay, I'm initializing i to zero" is not communication. Nobody hired a senior engineer because they narrated variable initialization. Narrate decisions, not syntax. The lines worth saying out loud are the ones that aren't obvious from the code: why you chose this data structure, what complexity trade-off you're making, what edge case you noticed and how you're handling it.

Code that says I don't know what I did but it works, please don't modify it - a brute force square function

What your write-up looks like when you solve it silently and can't explain a single decision you made.

Aim for one meaningful observation every sixty to ninety seconds. Enough that the interviewer never loses the thread of your reasoning. Not so much that you slow yourself down.

What You're Actually Proving

When an interviewer says they'd prefer a well-explained O(n²) over a silent O(n log n), they're not making an irrational bet. They're choosing the person they can verify.

The silent optimal solver might be a brilliant engineer. Or they might have memorized that specific pattern from grinding LeetCode last week and gotten lucky. The interviewer cannot tell. With no reasoning surfaced, there's no way to distinguish deep understanding from pattern matching.

The explained brute-force candidate is showing their work. When you can follow someone's reasoning, you can predict how they'll behave on problems you haven't seen. That's the prediction the hiring committee needs to make.

Technical skill is necessary. Communication is what makes that skill legible to everyone who decides your fate.

This is what trips candidates up: they prep for a correctness test and show up to a legibility test. SpaceComplexity runs voice-based mock interviews specifically because this legibility dimension cannot be practiced by solving problems silently. You have to narrate under pressure, repeatedly, until the habit is automatic before it matters.

How to Explain Your Thinking in Practice

A few concrete patterns worth building:

Before you code: Restate the problem in your own words. State one or two clarifying questions. Say which approach you're starting with and why, even if it's brute force.
While you code: When you pick a data structure, say why. When you see a potential edge case, call it out before you handle it. When you choose between two ways to write something, mention it.
When you're stuck: Say what you're considering. "I'm wondering if I can get this below O(n²) by precomputing something" is more useful than silence, even if you don't know the answer yet.
When you finish: Walk through one test case out loud before claiming you're done. State time and space complexity unprompted.

None of this requires constant talking. It requires making your reasoning visible at the moments it isn't self-evident from the code. If you want a script for how to narrate effectively under pressure, the think out loud guide covers the exact mechanics.