What Your Interviewer Is Writing While You Think

Your interviewer isn't waiting until the interview ends to form an opinion. They're taking notes right now, in real time, mapping what you say and do against a rubric they've been trained on. The scorecard is half-filled before you've written a single line of code.

Most candidates think they're being graded on the answer. They're not. What interviewers look for in coding interviews is evidence. Specific, quotable behaviors that let an interviewer write something concrete in the feedback form. Empty boxes read as no signal. No signal reads as no hire.

Knowing which moments matter, and what to do in them, is the gap between solving the problem and walking out with an offer.

The Notepad Is Open From Minute One

There's a scorecard. Four dimensions: communication, problem-solving, technical competency, and testing. At Google, each gets a score from 1 to 4. All 4s is a Strong Hire. One 1 in any category can tank the whole packet, even when everything else is solid.

The interviewer fills these boxes during the interview, not after. When you ask a good clarifying question, that's a note. When you explain your approach before coding, that's a note. When you sit in silence for three minutes contemplating your life choices, that's also a note.

Your interviewer isn't rooting against you. But they need material. No material means they can't advocate for you at the hiring committee, even if they liked you.

Clarifying First Is the First Graded Moment

The problem lands. Your instinct fires. Stop.

The minutes you spend on clarifying questions are graded as aggressively as anything else in the interview. Google's problem-solving rubric explicitly marks a score of 1 if the candidate skips them entirely. Not asking isn't neutral. It's a negative signal.

What strong candidates ask doesn't have to be clever. It has to be specific.

"Should I treat this as sorted or unsorted?" "Can the values be negative?" "Do we care about space here, or is time the priority?" These aren't stalling tactics. They're the questions a senior engineer asks before writing a single line of production code.

The gap shows up immediately. Weak candidates hear "find two numbers that sum to target" and immediately start coding. Strong candidates ask whether numbers can repeat, whether exactly one answer is guaranteed, and whether the array is sorted. Same problem statement. Very different opening.

A developer immediately jumping to hash maps the moment the interviewer finishes the problem statement Every problem statement: a chance to slow down. Every developer brain: absolutely not.

If you want a structured approach to this, this breakdown of what interviewers actually want to hear is worth reading before your next round.

Stating the Plan Out Loud Creates Quotable Evidence

Once you've clarified, articulate the approach before you type anything. Out loud. Not in your head, out loud.

Interviewers can't see inside your head. If you go quiet and then produce correct code, they have almost nothing to write in the problem-solving box except "solved the problem." That's a 3, not a 4. A 4 requires the interviewer to have witnessed you discuss trade-offs, articulate alternatives, and pick an approach deliberately.

Here's what that sounds like in practice:

"I'm thinking O(n) with a hash set. The brute force would be nested loops at O(n²), but that burns through the time limit. Hash set trades space for time and gets us linear. I'll go with that unless you want me to explore the space-constrained version."

Twenty-five seconds. Two rubric boxes filled. The brute force mention shows you understand the problem space. The deliberate trade-off shows engineering judgment. The question at the end invites collaboration.

Successful candidates waited until 27% of the interview had elapsed before running code. Unsuccessful candidates started at 23.9%. Doesn't look like much. In practice it's the difference between someone who builds a clean solution and someone who spends the back half debugging from a wrong starting assumption.

Silence While Coding Is Not the Same as Focus

This is where most technically capable candidates quietly lose the communication dimension without realizing it.

When you go silent to write code, the interviewer gets nothing. No note, no quote, no evidence. After a few minutes of silence they start wondering whether to intervene, whether you're stuck, whether you've taken a wrong turn. They can't help you if they can't see where you are.

Narrating doesn't mean talking nonstop. It means keeping the interviewer inside your thought process.

"I'm initializing a map to track what I've seen... iterating through the array now... here I'm checking if the complement is already in the map." One sentence every 30 seconds. Costs you almost nothing. Fills the communication box with clean evidence.

Developer goes completely silent for 5 minutes while the interviewer stares and takes increasingly concerned notes The interviewer is writing something down. You are not going to like what it says.

There's a failure mode that shows up constantly: candidates who vocalize half-thoughts. "Hmm, I wonder if I could... no, never mind." That's worse than silence. A better pattern is to complete the thought: "I considered X but ruled it out because Y." That shows structured reasoning. The unfinished half-thought shows confusion.

One veteran Google interviewer said it plainly: he's passed more candidates who arrived at the optimal solution without fully coding it than candidates who coded the optimal solution without explaining anything. Sit with that.

For more on why narration beats silence every time, this piece on technical interview communication has the data.

Test Your Own Code Before Being Prompted

Most candidates finish coding, look up at the interviewer, and wait for feedback. Strong candidates don't wait.

They pick a simple input, trace through it step by step, narrate the variable states, and then move to an edge case. Empty array. Negative numbers. All duplicates. Single element. The whole tour, unprompted.

Testing is its own scored dimension. Google's rubric for a Strong Hire on testing reads: "effortlessly tested typical cases, corner cases, identified and corrected bugs." A candidate who waits to be asked to test doesn't get that score. A candidate who tests unprompted, out loud, with edge cases, does.

There's a practical angle too: finding your own bug during a dry run is demonstrating exactly what good engineering looks like. You wrote it, you review it, you catch it. That's how production code should work.

The phrase that signals it: "Let me trace through this with the example before we go further." Three seconds. Strong hire territory.

Getting Stuck Is Fine. The Next 30 Seconds Aren't.

Every experienced interviewer expects candidates to get stuck. The question isn't whether it happens. It's what you do in the 30 seconds after.

Silence is the worst possible response. It leaves the interviewer with nothing to write about your diagnostic process. They can't help because they don't know where you're lost. They can't give a useful hint without knowing what you've already tried.

The move: narrate where you are. "I've got the base case working but I'm not sure how to handle the cycle in the graph case. I'm considering storing visited nodes in a set, but I'm not certain that handles the directed case correctly." Now the interviewer has something to work with.

When they give you a hint, take it. Not just literally, collaboratively. "That's a good point. If I track visited states rather than nodes, then each unique path becomes distinguishable. Let me revise the state definition." Hint responsiveness is a coachability signal. Interviewers are watching whether you incorporate feedback quickly and gracefully, because that's exactly what working with a senior engineer looks like on the job.

Candidates who resist hints, or who take them but can't extend the idea, leave the interviewer with a gap in the write-up they can't explain away. If you've ever frozen and gone quiet, this guide on recovering when stuck shows exactly what to say.

Follow-Up Questions Test Something Different

The follow-up is where the interview separates competent from exceptional.

A question about scaling from 100 to 10 million records isn't testing your algorithm. It's testing whether you can reason under new constraints, stay structured when the problem shifts, and communicate clearly when the ground moves.

The wrong response is to immediately pitch a new solution. The right response is to reason out loud about what changes: "The bottleneck changes at scale. The algorithm is fine for memory-resident data, but now we're worried about I/O and distributed state. If we can't fit the dataset in memory, I'd think about streaming it through and maintaining a fixed-size window rather than loading everything at once."

You don't have to arrive at the perfect answer. You have to show the process of getting there.

The Question Every Interviewer Asks Themselves

When writing feedback on a borderline candidate, interviewers ask themselves one question: would this person have gotten there with ten more minutes?

It's not on the rubric. But it drives borderline decisions more than any single score. A candidate on a clear trajectory, thinking out loud, eliminating wrong paths with stated reasons, incorporating hints gracefully, will get a leaning hire even with an incomplete solution. A candidate who went silent for 15 minutes and then produced correct code with no explanation might get a lower score.

The trajectory matters as much as the destination. None of the behaviors above are separate tips. They're the same thing: making your thinking visible so the interviewer can fill the scorecard with evidence that advocates for you.

If you want to practice all of this under realistic pressure, SpaceComplexity runs voice-based mock interviews with rubric feedback across every dimension covered here. Narrating your approach out loud, in a timed setting, is exactly how you make it automatic before the real thing.

The Behaviors That Fill the Scorecard

Ask specific clarifying questions before touching the keyboard. Not asking is a scored negative at most top companies.
Articulate the approach and trade-offs before you code. Thirty seconds that fills two rubric boxes.
Narrate while coding. Keep the interviewer inside your thought process, not locked out of it.
Test your own code before being prompted. Trace through examples and edge cases out loud.
When stuck, say where you are. Silence gives the interviewer nothing to write down.
When given a hint, take it collaboratively and extend it. Responsiveness is a coachability signal.
In follow-ups, reason out loud rather than jumping to an answer. Process beats destination.
Remember the trajectory question: "Would they have gotten there?" is what drives borderline decisions.