What Technical Interviews Actually Score (It's Not Just Whether Your Code Runs)

Why candidates go quiet during the technical round

Ask most candidates why they go silent while solving a coding problem and the answer is some version of: I didn't want to interrupt my own thinking. It's a reasonable instinct, and it's not laziness or nerves — it's a habit trained into them by years of exams that worked on exactly one rule: work alone, work quietly, and the only thing that gets graded is the final answer on the page.

So the pattern repeats in the interview. The interviewer states the problem, the candidate goes quiet, thinks it through in their head or scribbles on paper, and only starts talking once they have something close to a full solution to present. From the candidate's side, this feels like maximum focus — the same deep-work silence that earned them marks on every timed test they've ever sat.

The trouble is that a technical interview was never actually testing the same thing as an exam, and treating it like one is a version of the same mismatch covered in why interview underperformance is usually a practice problem, not a knowledge problem — except here the practice gap isn't about knowing the material. It's about never having rehearsed narrating it.

“The habit that earned full marks on an exam is the exact habit that can cost you the interview.”

What's actually on the scorecard (and it isn't just 'did it run')

Cracking the Coding Interview, Gayle Laakmann McDowell's widely used technical-interview prep book, lays out the evaluation framework a large share of tech-company interviewers are trained to score against, and it isn't one row. It's five: Analytical Skills, Coding Skills, Technical Knowledge, Experience, and Culture Fit/Communication Skills. Correctness sits inside Coding Skills. It doesn't touch the other four.

Analytical Skills specifically covers things like problem structuring and how much assistance a candidate needed to get there — and the book is explicit that solutions are judged "not merely on correctness, but also on problem-solving approaches." None of that is observable from a finished block of code. It's only observable from what you say while you're getting there.

• Analytical Skills — how you structure the problem, the approach you choose, how much help you needed along the way
• Coding Skills — clean, organized, working code, including how you handle errors
• Technical Knowledge — the CS fundamentals and tech-specific knowledge behind your approach
• Experience — how your past projects and technical decisions inform this one
• Communication — clarity while explaining your reasoning, and fit with how the team works together

A candidate who solves the problem in total silence and then explains it afterward isn't failing this rubric on purpose. They're leaving most of it blank. And a blank row on a five-row scorecard doesn't get read as neutral — it gets read as missing data, and missing data doesn't earn the benefit of the doubt in a process built to compare you against other candidates who did fill it in.

“A row nobody can observe isn't scored generously. It's usually just left blank.”

Why interviewers need to hear you think, not just see what you typed

This isn't a quirk of tech-industry interview culture. It's downstream of a much older finding in cognitive psychology. In a 1980 paper in Psychological Review, "Verbal Reports as Data," Anders Ericsson and Herbert Simon made the case for what's now called the think-aloud protocol: when someone verbalizes their reasoning while they're actively performing a task, rather than explaining or justifying it afterward, that verbalization is a reasonably faithful window into the actual thought process going on in real time — not a performance layered on top of it.

That distinction is why the method spread far beyond psychology labs, into usability research, education research, and — in an applied, informal form — technical interviews. An interviewer asking you to talk while you solve a problem is running a live think-aloud protocol on your reasoning, because it's the only real-time signal they have into how you actually think, as opposed to whether you can produce a correct answer some other way.

The distinction Ericsson and Simon drew matters here too: narrating your reasoning as you go is closer to their protocol than narrating a polished explanation after you've already solved it silently. Interviewers can generally tell the difference, and only the first one gives them the row on the scorecard they're actually trying to fill in.

What silence looks like from the other side of the table

From inside your own head, working silently and being stuck feel completely different. From across the table, they look identical. Software engineering researcher Venkatesh-Prasad Ranganath has written about exactly this: candidates who go quiet during a coding interview often read to the interviewer as disengaged or unsure, even when they're neither — because silence is the only channel the interviewer has, and it carries no information about which of the two is actually happening.

It's the same reason a driving examiner sits in the passenger seat instead of reviewing your route afterward. Watching the outcome only tells you where you ended up. Watching the process — including the moments you check a mirror, hesitate, or correct course — is what actually lets someone evaluate the decisions in between. An interviewer with only a finished block of code has the destination. They have none of the decisions.

“Productive focus and being quietly lost look exactly the same from the other side of the table.”

The exam habit that works against you in a live interview

This mismatch hits Indian freshers particularly hard, for a structural reason rather than a skill gap. Most engineering coursework, campus aptitude rounds, and online coding tests in the Indian campus placement pipeline are built on exactly the format described earlier — solve alone, submit a final answer, and silence isn't just tolerated, in a proctored test it's required. Years of exactly that training produce candidates who are extremely good at silent, independent problem-solving, and who have had almost no structured reason to ever narrate their thinking to another person while working through it.

Then a live technical interview round shows up in the same recruitment process, scored on a completely different rule, with nobody explicitly flagging that the rule changed. Nothing about it is a lack of ability or preparation. It's a format switch that most prep material doesn't name directly, because most prep material is still written as if the technical round were another version of the test candidates already know how to take.

It's a close cousin of a mismatch covered elsewhere on this blog — group discussion rounds quietly reward whoever speaks first and most, not the strongest idea, and the technical round quietly rewards whoever narrates their reasoning, not just whoever reaches the right answer. Different round, same underlying lesson: know what's actually being scored before you walk in.

How to practice narrating without sounding scripted

None of this means filling every second with commentary, and brief silence while you get your bearings is genuinely fine — interviewers expect a short pause at the start of a hard problem. What changes the outcome is a handful of specific habits, not constant talking.

• State your understanding of the problem and its constraints out loud before you touch the keyboard, so the interviewer starts scoring Analytical Skills from question one, not from your first line of code
• Name the approach or data structure you're choosing and, briefly, the one you considered and rejected — that comparison is exactly what 'problem structuring' is measuring
• Narrate the edge cases you're checking for before you handle them, rather than silently patching them in afterward
• When you catch your own mistake mid-solution, say so instead of quietly fixing it — a narrated self-correction reads as a strength on the scorecard, not a slip
• If you need a moment to think through a hard step, say that too — "let me think through the approach for a second" turns an ambiguous silence into a signal the interviewer can actually read

This is a trained skill, not a fixed trait, and it responds the same way every other interview skill does — with reps, not more reading. How many mock interviews you actually need before it stops feeling performative is worth answering with real numbers rather than a guess.

If what's actually happening to you is closer to your mind going blank under pressure than a deliberate choice to stay quiet, that's a related but different mechanism — see why smart people go blank during interviews for what to do about that specifically.

And narrating a solution well is still, underneath it, the same skill as repetition building a capability that reading alone never does — the first few times it will feel unnatural. That's expected, not a sign it isn't working.

The same split between technical correctness and everything else on the scorecard shows up one role over, in what data analyst interviews actually score — a correct SQL query earns one row on a longer scorecard there too.

Key Takeaways

If you remember only a few things, remember these:

• Correctness is one row of a five-row scorecard (Cracking the Coding Interview's own framework) — Analytical Skills, Coding Skills, Technical Knowledge, Experience, and Communication are scored separately.
• Analytical Skills and problem-solving approach are only observable through what you say while solving, not through finished code.
• This isn't interview-culture trivia — it's an applied version of the think-aloud protocol, a 1980 cognitive-psychology method (Ericsson & Simon) for making real-time reasoning observable.
• From the interviewer's side, productive silent focus and being quietly stuck look identical. Silence carries no information about which one is happening.
• The habit of solving silently comes from years of exams and campus tests that reward exactly that — it's a format mismatch, not a lack of skill.
• State your understanding of the problem, name the approach you're choosing (and the one you rejected), narrate edge cases, and say so out loud if you catch a mistake or get stuck.
• This is a trained, rehearsable skill like any other interview skill — it gets more natural with real reps, not with more reading.