Technical interviews
Technical interview practice: how to think out loud, not just solve.
A technical interview is scored on your thought process, not only on whether you land the right answer, so the skill worth practicing is saying your reasoning out loud. The interviewer is watching how you break a problem down, what you assume, which trade-offs you name, and how you react when they nudge you. Most people grind problems silently and then freeze the moment they have to explain. Below: what a technical screen actually tests, how to think out loud, the common formats you should expect, and how to rehearse the spoken part against an AI interviewer that scores every answer.
What it tests
The screen measures how you reason, not just whether you arrive.
A silent, correct answer and a narrated, correct answer are not scored the same. The interviewer already knows the answer to the problem in front of you; what they can't see, unless you say it, is how you got there. So they listen for the reasoning: the assumptions you check before you write anything, the approach you sketch before you commit, the trade-off you flag when you pick one path over another. This is why the structured technical interview is worth the effort employers put into it. The structured interview is the single strongest predictor of job performance they have, at an operational validity of .42, above general cognitive ability at .31 (Sackett, Zhang, Berry & Lievens, 2022), and it earns that by scoring behavior in the room rather than a résumé line.
The practical read is that a candidate who talks through a partial solution clearly can outscore one who reaches the answer in silence. When you go quiet, the interviewer has nothing to grade but the final artifact, and if it's wrong they have no idea whether you were one insight away or lost. Narration is what makes your thinking legible, and legible thinking is what they're there to rate.
How to think out loud
Four moves turn silent problem-solving into a legible answer.
Thinking out loud is a skill, and like any skill it has a shape. These four moves keep a technical answer legible from the first sentence, and they hold whether you're working a small problem verbally or walking through code on a screen.
-
State your assumptions
Before you solve, say what you're taking as given. Input size, edge cases, what "done" means. It shows judgment and buys you a correction before you spend effort on the wrong problem.
-
Narrate your approach
Sketch the plan in one or two sentences before you write. "I'll do the brute-force version first, then look for a faster one." The interviewer can follow you, and can steer early if you're off.
-
Name the trade-offs
When you choose, say why. Faster but more memory, simpler but slower, clearer but longer. Naming the cost of your choice is the signal of a working engineer, not a memorized answer.
-
Handle the nudge
When they push back or point at a case you missed, treat it as a hint, not a verdict. Say what you now see, adjust out loud, and keep going. How you recover is often what they're really testing.
None of this is a script to recite. It's the order your reasoning should surface in, so you stop going silent under pressure and the interviewer can score the thinking you actually did. The hard part is that all four moves happen out loud, in real time, which is exactly the part you can't rehearse by reading.
Common formats
The technical formats you should expect.
Technical screens come in a few recurring shapes. They differ on the surface, but every one of them is scored on the same thing: whether you can make your reasoning audible while you work.
"Walk me through how you'd approach this."
A small problem, no editor, just you talking. They want to hear you decompose it, name a plan, and reason about cases before any code exists.
"Explain what this does and why."
You narrate code, yours or theirs, line by intent. Say what each part is for, where it could break, and what you'd change. See the explain-your-project guide.
"How would you build something like this?"
A high-level discussion, not a diagram contest. They listen for how you scope the problem, name components, and reason about trade-offs at the seams.
"Are you sure? What about this case?"
The nudge when you're wrong or shallow. They're testing recovery: whether you can hear the hint, adjust out loud, and keep your composure.
Problem → Solution
Grinding problems silently trains the solving. It never trains the explaining.
You can solve a hundred practice problems alone at your desk and still go quiet the moment someone is listening, because the skill the screen scores is the live exchange, not the answer on the page. Saying your reasoning out loud under pressure, fielding "are you sure?", and being shown where your explanation lost the interviewer is a different act from working in silence. Practicing the skill beats reviewing it: at a one-week delay, a tested group recalled 56% of material versus 42% for a re-reading group (Roediger & Karpicke, 2006), and specific, immediate feedback is what turns a rep into an improvement (Wisniewski, Zierer & Hattie, 2020).
Rehearse the spoken part out loud and get scored on where the explanation slipped. In Rehearsal Room you work a technical prompt out loud against an AI counterpart that pushes back with follow-ups and the occasional "are you sure?", and the forensic debrief afterward grades the reasoning: whether you stated your assumptions, whether the interviewer could follow your approach, whether you named a trade-off, and whether you recovered when nudged. It flags the exact point the explanation lost the room and the line worth keeping. Rehearsal, not cheating, because you build the ability to explain before the screen, not during it.
Take a problem you can already solve on paper and try to talk through it cold, then read the score on each move: assumptions, approach, trade-offs, recovery. Carry the weakest one into the next rep and drill it. Repeated reps are what make it stick, and dropping practice after one clean run collapses the gain (Karpicke & Roediger, 2008), so run a handful of prompts across a week until narrating your thinking feels automatic.
Questions & answers
Technical interviews, in plain terms.
What does a technical interview actually test?
Your thought process more than your final answer. The interviewer already knows the solution; what they're grading is how you break the problem down, the assumptions you check, the trade-offs you name, and how you react when they push back. A clearly narrated partial answer can score above a silent, correct one.
How do you practice technical interviews?
Solve problems, then practice explaining them out loud, against prompts you didn't pre-script, with feedback on the reasoning. Grinding problems silently trains the solving but not the explaining, which is the part the screen scores. Say your approach aloud, field a follow-up, and get shown where you lost the listener.
How do you talk through code in an interview?
State your assumptions first, sketch your approach in a sentence before you write, say why you pick one path over another, and when the interviewer nudges you, treat it as a hint and adjust out loud. Narrate intent, not syntax: what each part is for and where it could break.
What is the most common mistake in a technical screen?
Going silent. When you stop talking, the interviewer has nothing to grade but the final artifact and no idea whether you were one step away or lost. The fix is to keep your reasoning audible even when the answer isn't finished yet.
Is there a tool to practice technical interviews out loud?
Yes. Rehearsal Room lets you work a technical prompt out loud against an AI interviewer that pushes back, then scores your reasoning and flags the exact point your explanation lost the room in a forensic debrief. It runs in your browser and is built to drill the spoken skill, not to feed you answers.
Practice thinking out loud. Get scored on where the explanation slips.
Work technical prompts out loud against an AI interviewer and get a forensic debrief on your reasoning, from assumptions to recovery. Rehearsal, not cheating.
Start practicing →More from Rehearsal Room: explain your project · git interview questions · co-op interview practice · all interview guides.