How to think out loud in a coding interview
Thinking out loud in a coding interview means saying your decisions, not your keystrokes: what you understood, the plan and its complexity before you type, why you chose each data structure, and what you expect when you trace a test. Interviewers score communication and problem solving from what they hear, so a silent correct solution earns less than most candidates expect.
Key points
- Restate the problem and ask about input size and edge cases before planning.
- Say a brute-force plan with its complexity first, then improve it out loud.
- While typing, narrate decisions (“a deque, because I drop from the front”), not syntax.
- Test by tracing a small example through the code and saying the state at each step.
- When stuck, say what you have tried and what you are considering. That invites a useful hint.
What to say in each phase
| Phase | Say | Skip |
|---|---|---|
| Clarify | The problem in your own words, input size, sorted or not, duplicates, empty input, what to return | Reading the prompt back word for word |
| Plan | A working approach and its time and space; then a better one if you see it | Typing before the interviewer has heard any plan |
| Code | Each decision and why: data structure, loop invariant, what a helper does | Every variable name and bracket |
| Test | A small input traced line by line, then the edge cases you listed earlier | “I think it works” |
| Complexity | Final time and space, and what dominates | A number without the reason |
A worked problem: a request limiter
Prompt: you receive a user’s request timestamps in seconds, sorted. The service accepts at most k requests in any 60-second window, and rejected requests do not count toward the limit. Return the indices of the rejected requests.
Clarify. Is the window [t − 60, t] or (t − 60, t]? Say you will treat a request exactly 60 seconds old as outside the window and confirm. Can timestamps repeat? Yes. What if k is 0? Then everything is rejected. Size? Up to a million requests, so anything quadratic is out.
Plan. Brute force: for each request, scan back over every request in the last 60 seconds and count the accepted ones: O(n × w), where w is the number of requests in a window, so quadratic in the worst case (every timestamp equal). Better: keep the timestamps of accepted requests in a queue. For each new request, drop accepted timestamps that are 60 or more seconds older; if fewer than k remain, accept and push, otherwise reject. Each timestamp enters and leaves the queue at most once, so O(n) time and O(k) space.
from collections import deque
def rejected(times, k, window=60):
accepted = deque() # timestamps of accepted requests
out = []
for i, t in enumerate(times):
while accepted and accepted[0] <= t - window:
accepted.popleft()
if len(accepted) < k:
accepted.append(t)
else:
out.append(i)
return outThe same problem, out loud
“Let me restate: sorted timestamps, at most k accepted in any 60-second window, and rejected ones don’t count. I’ll treat a request exactly 60 seconds old as expired; tell me if you’d prefer it inclusive.”
“Brute force scans back for each request. That’s too slow for a million, so I’ll keep only the accepted timestamps in a queue, oldest first.”
“A deque, because I drop from the front and add at the back, both constant time.”
“This while loop expires anything at least 60 seconds older than the current request. Then the queue length is exactly the accepted count in the window.”
Testing by tracing
Trace a small case aloud: times [0, 10, 20, 61, 62] with k = 2. At 0, the queue is empty: accept, queue [0]. At 10: accept, queue [0, 10]. At 20: nothing expires, two in the queue, reject index 2. At 61: 0 expires because 0 ≤ 1, queue [10], accept, queue [10, 61]. At 62: nothing expires (10 > 2), two in the queue, reject index 4. Result [2, 4].
Then the edge cases you listed while clarifying: empty input returns an empty list; k = 0 rejects everything because the length check fails at once; equal timestamps behave like any others. Saying the queue’s contents at each step is what makes the trace convincing; it also catches off-by-one errors in the window before the interviewer does.
When you are stuck
Silence is the most expensive way to be stuck. Say what you know, what you tried and where it breaks: “Scanning back works but is quadratic; I need the count of accepted requests in the window without recounting.” That gives the interviewer exactly what they need to offer a small hint, and taking a hint well is itself a positive signal in most rubrics.
“I’m stuck on keeping the count without rescanning. I’m thinking about which structure lets me forget old requests cheaply.”
Common mistakes
- Typing in silence for ten minutes, then explaining everything at the end.
- Narrating keystrokes (“now a for loop, i equals zero”) instead of decisions.
- Skipping the plan because the solution feels obvious.
- Testing by saying “this should work” instead of tracing a concrete input.
- Apologizing for a brute-force idea. Say it, give its complexity, and improve it.
- Treating a hint as a failure and going quiet.
Questions
How much should I talk while coding?
Enough that the interviewer could explain your approach to someone else: one sentence per decision. Long pauses while you type routine code are fine if you said what the code will do first.
What if talking slows me down?
It does at first. Practise the phases out loud on easy problems until the talking is automatic, then move to harder ones.
Should I write tests in code?
If the environment runs code, yes, after tracing one example by hand. If it does not, a careful spoken trace is the test.
Practise this out loud with Vera
Mockich’s coding round runs 45 min: two problems at regular and one deeper at lead, in an editor that runs your code. Vera asks for your plan and its complexity before you type, stays mostly quiet while you work, and gives at most three small nudges, never the answer. The report scores problem solving, code quality and correctness, complexity and optimization, testing and edge cases, communication (plus production thinking at lead) and quotes what you said.
Related guides
Sources
We read these sources on 2026-11-03; the phase order follows the Tech Interview Handbook (MIT) and the constraints-first habit of Interactive Coding Challenges (Apache-2.0), while the limiter problem, the code and the spoken lines are our own.
- [1] Tech Interview Handbook, Coding interview techniques (MIT)
- [2] Donne Martin, Interactive Coding Challenges (constraints, test cases, algorithm, code, test) (Apache-2.0)
- [3] Tech Interview Handbook, Coding interview rubrics (MIT)
- [4] Metaview, How to lead a coding interview
- [5] Formation, 5 common mistakes engineers make in technical interviews