A technical interview grades two things simultaneously: whether you can get to the right answer, and how you think when you are not sure. Talking out loud while you solve does not slow you down. It makes your chunking visible — which is what the interviewer is actually scoring when the candidate in front of them gets the same answer as the last five.

When to use Think-aloud

Use the think-aloud protocol any time you are solving a problem in real time in front of an interviewer — coding, system design, product sense, case, or estimation.

Coding problems on a whiteboard or in a shared editor
System design interviews ("design Twitter")
Product sense prompts ("how would you improve X?")
Back-of-the-envelope estimation ("how many piano tuners in Chicago?")
Architecture or debugging walkthroughs

How to use it

Clarify before coding. Ask two or three scoping questions to confirm constraints — input type, scale, edge cases. Interviewers often have additional information they will only share if asked.
Name your decomposition. "I see two subproblems here: parsing the input and building the index." Decomposing aloud is the chunking they are grading.
State a naive solution first. "The brute-force approach would be O(n²) because…" Even if it is wrong, naming it shows you can see the landscape before optimizing.
Verbalize as you implement. "I'm going to use a hash map here because lookups are O(1) and I don't need ordering." One sentence per decision.
Test and summarize tradeoffs at the end. "This runs in O(n log n) time and O(n) space. If memory is constrained we'd need to trade time for space."

Example

Them

Design a URL shortener like bit.ly.

On your HUD

A few clarifying questions first — are we optimizing for read speed or write speed? What's the expected daily volume of shortened URLs?
Assuming 100M new URLs per day, read-heavy: I'd use a key-value store like Redis for the mapping, with a CDN in front for the redirects.
The core tradeoff is that a centralized counter is a single point of failure — so I'd switch to a distributed ID generator like Snowflake for production scale.

What Kennan would surface in this moment, in the same first-person bullet format as the in-app HUD.

Common pitfalls

Going silent and solving in your head. If you are quiet, the interviewer has no signal. An incomplete solution with visible reasoning often outscores a correct answer with none.
Skipping clarification. Solving the wrong problem well is a failure mode. Two minutes of clarification is always worth it.
Optimizing before you have a working solution. Get to correct first, then get to efficient.

Where it comes from

Ericsson & Simon, Protocol Analysis (1980) · Berardi-Coletta et al., JEP (1995) · Chase & Simon (1973)

In your next meeting

Kennan watches for the conversational pattern this framework addresses and surfaces a first-person line you can read off your HUD, in the same shape as the example above. Frameworks are receipts; the user-facing output is a sentence, not a citation.