5 exercises on narrating your approach, considering edge cases, and stating assumptions out loud.
Key patterns
My first instinct is to... — commit to a direction provisionally.
Let me consider edge cases... — empty, null, single element, overflow.
Let me state my assumptions... — then invite a yes/no correction.
Let me dry-run this with... — trace a concrete example aloud.
0 / 5 completed
1 / 5
The interviewer reads out a problem and waits. You want to start narrating your approach before writing code. Which opening sounds most natural and confident?
Signpost your first idea, then justify it.
Interviewers score communication, not just the final code. Opening with My first instinct is... shows you have a direction while signalling it is still provisional. Useful thinking-aloud openers:
My first instinct is to... — commits to a direction without over-committing.
The naive approach would be... but that is O(n²), so...
Let me restate the problem to make sure I have it.
Option A signals panic, C is arrogant and skips reasoning, and D outsources the thinking. Always pair an idea with a brief reason (the hash-map look-up cost here) so the interviewer can follow your trade-off.
2 / 5
Halfway through coding you realise your approach breaks on empty input. What is the best thing to say out loud?
Narrate course-corrections; do not hide them.
Catching your own bug out loud is a strong signal. The phrase Let me consider edge cases... is the natural lead-in. Reusable phrases:
Let me consider edge cases: empty input, a single element, duplicates...
I spotted a problem — my loop assumes at least one element.
Let me add a guard clause and re-trace.
Option A loses all the credit for noticing; C is emotional and vague; D ignores the very gap you found. Senior candidates verbalise the edge cases (empty, null, overflow, off-by-one) deliberately rather than testing silently.
3 / 5
Before writing any code you are unsure whether the input list can contain negative numbers. How should you clarify the assumption aloud?
Make assumptions explicit, then invite correction.
Strong candidates surface assumptions rather than silently baking them in. The collocation is state my assumptions / flag an assumption. Patterns:
Let me state my assumptions: ... then a yes/no check.
I am going to assume X for now — tell me if that is wrong.
To keep things simple I will assume the input fits in memory.
Option A bakes in a silent assumption that may be wrong; C dismisses a real concern; D abdicates ownership. Note the difference from a clarifying question: here you propose the assumption and ask for confirmation, which keeps momentum while staying safe.
4 / 5
You have just finished coding and want to verify by tracing a small example aloud. Which is the most effective narration?
Trace a concrete example out loud.
A spoken dry-run (also trace through / walk through) proves your code without a compiler. The technique: pick a tiny input, name the iteration, and read each variable's value. Phrases:
Let me dry-run this with...
On the first iteration, i equals zero, so...
Tracing through, the accumulator becomes...
Option A skips verification; C and D mistake compilation for correctness. Tracing aloud also lets the interviewer catch a misunderstanding early and is your best tool when no IDE is available.
5 / 5
The interviewer goes quiet while you think. To avoid an awkward silent gap, which is the best thing to do?
Fill thinking time with structured commentary, not apologies.
Long silences read as being stuck. A brief running commentary keeps the interviewer in your head and gives them a chance to nudge you. Good fillers:
I am weighing two options...
Let me think through the trade-off out loud.
Give me a second to organise my thoughts — I am considering...
Option A creates dead air; C undermines your confidence; D shifts the work onto the interviewer. The goal is a calm, audible reasoning thread — the same skill you use narrating a design in a real team.