Free Think Out Loud Coding Interview Practice

This is live narration under pressure — not explaining a finished solution. A real problem appears; you clarify, pick an approach, take a pushback, and keep talking while you work. Short sentences beat silence.

Practise now

Different skill

The LeetCode Communication Coach scores how you explain a finished solution (restate → approach → example → Big O → edge). This page scores how you think out loud while solving — clarifying questions, trade-offs, and recovery when stuck. Open the LeetCode Communication Coach.

Live spoken order

Six pressure beats while you solve. “Test it” is optional when time remains.

1. Clarify
Ask before you assume.
One or two questions: sorted? empty allowed? return type? Interviewers score curiosity that de-risks the build.
“Before I start — can I assume…?”
2. First idea
Say the first solution that comes to mind.
Even if it is brute force. Silence reads as confusion. “My first instinct is …” buys you time.
“My first instinct is…”
3. Trade-off
Name one advantage and one cost.
“This is simple but slow.” Show you can see a second option before you commit.
“The trade-off is…”
4. Justify
Say why you are choosing this approach now.
Tie it to a constraint you just heard: input size, memory, or time. One sentence is enough.
“I am choosing this because…”
5. Narrate while coding
Talk through what you are writing.
Not a lecture — short status lines: “I am storing the complement,” “I move left past the duplicate.”
“I am writing… / Right now I am…”
6. Stuck / recover
Name the blocker, then the next check.
“I am stuck on the empty-input case. I will write that first.” A bridging phrase beats a long pause.
“I am stuck on… So I will…”
7. Test it · optional
Optional — walk one case out loud.
Dry-run a tiny input or name the case you would assert. Nice when time remains.
“Quick check — if the input is… I expect…”

Phrases under pressure

Clarify

“Before I start — is the input sorted?”
“Can the array be empty, and what should I return then?”
“Just to confirm: we need indices, not the values themselves?”

Decide

“My first instinct is a brute-force scan, then I will see if I can do better.”
“That is simple but slow — I would switch to a hash map if n is large.”
“I am choosing the map because I need a fast lookup and I can afford the memory.”

Under pressure

“I am writing the map lookup now — stop me if you want a different direction.”
“I am stuck on the empty-input case. I will write that guard first, then come back.”
“Good hint — if n is millions, O(n²) is out; I will switch to the linear pass.”
“I see a bug: I forgot to update the pointer. I will fix that before continuing.”

Practise under pressure

A problem statement is on screen. Do not write a polished solution talk. Narrate how you would start live: clarify, first idea, trade-off, justify, what you are writing, and what you say if you stall. Use Drill mode for one skill in 30–45s, or Interview mode for a multi-turn simulated interviewer.

3 free scored runs left this hour.

Problem on the board

Easy · Hash map

Given an array of integers nums and an integer target, return the indices of the two numbers that add up to target. Exactly one solution. You may not use the same element twice.

2 ≤ nums.length ≤ 10^4
Exactly one valid pair
You may not reuse the same index

Example: nums = [2,7,11,15], target = 9 → [0,1]

Single-skill drill · 30–45s

The problem just appeared. In 30–45 seconds, ask two useful clarifying questions out loud. Do not start coding.

Model script (per problem)

Problem

Generated for Two Sum — not a hardcoded Two Sum monologue.

1. Clarify
Before I code: is the array sorted, and can values be negative? I will assume unsorted with possible negatives unless you say otherwise.
2. First idea
My first instinct is a brute-force pair check — for each index try every later index.
3. Trade-off
That is correct but O(n²). With a large input I would trade memory for a hash map of seen values.
4. Justify
I am choosing the map because I need a fast complement lookup and I can afford O(n) space for typical interview sizes.
5. Narrate while coding
I am writing a map, scanning left to right. At each number I look up target minus that number; if it is there I return the two indices, otherwise I store the current one.
6. Stuck / recover
If I stall I will write the empty-pair guard and one tiny example on the side, then come back to the loop.
7. Test it
I would dry-run [2,7,11,15] target 9, and check a case where the pair sits at the two ends.

FAQ

Questions

LeetCode explainer = you already know the solution and present it. Think out loud = the problem is new on screen; you clarify, decide, take pressure, and narrate while working.

Clarify first, then first idea, one trade-off, why this approach, short status lines while coding, and a recovery line if you stall. A bridging phrase beats a pause.

Keep commentary to one line per decision. Do not translate a paragraph in your head. “I will use a map. If I stall I will write the empty case.” is enough.

On a UK/US panel, long silence usually reads as being lost. Name the next step, then go quiet for ten seconds of typing if you need to.

No. You get a few free scored runs per hour. Clips are scored and discarded. Sign up if you want more.

More questions? Email us at contact@mocklyenglish.com.

Course: How to explain your thoughts · LeetCode Communication Coach

Quick answer

Think out loud under pressure: clarify, first idea, trade-off, justify, narrate while coding, recover when stuck. Different from explaining a finished LeetCode solution — drill mode and a simulated interviewer keep you talking live.

Related in this path

People like you