How to Explain a LeetCode Solution Out Loud in an Interview

How do you explain a LeetCode solution out loud in an interview?

Narrate in four passes: restate the problem, walk through a brute force, propose the optimization with its complexity, then code while talking. The interviewer is grading your reasoning, not your typing speed. A clean solution explained badly fails more often than a brute force explained well.

Pass 1: Restate the problem (60 seconds)

Read the problem out loud, then paraphrase it back. This catches misreads early and shows the interviewer you're not just pattern-matching to a memorized solution. Ask:

• "Can the input be empty?"
• "Are values unique, or can there be duplicates?"
• "Is the input sorted?"
• "What's the expected input size — should I optimize for time, space, or both?"

If the interviewer answers with shrugs, pick reasonable defaults and state them. "I'll assume non-empty input with up to 10⁴ elements" is engineering judgment. Coding silently is not.

Pass 2: Walk through a brute force (2 minutes)

Always have a brute force ready to discuss, even if you'll never code it. The format:

"The naive approach is to do X for every Y. That's O(n²) time and O(1) space. I think we can do better, but let me make sure that's actually correct first."

Then trace it through a tiny example (3-5 elements) on the whiteboard or shared editor. You'll catch off-by-one bugs, confirm you understood the problem, and give the interviewer a chance to redirect you if you're solving the wrong problem.

Levels.fyi's interview analysis — drawing on thousands of post-loop debriefs — consistently flags "jumped to code without confirming the problem" as the most common reason strong candidates get downgraded.

Pass 3: Propose the optimization with complexity (2 minutes)

This is where the offer is won or lost. The pattern:

"We can avoid the nested loop by [data structure / observation]. That trades O(n) extra space for O(n) time. The intuition is [one-sentence why]."

Then state the complexity out loud before coding:

• "Time: O(n) — single pass through the input."
• "Space: O(n) — hash map sized to the input."
• "Edge cases I want to handle: empty input, single element, duplicates."

Saying complexity before coding signals you understand the structure of the algorithm, not just the syntax. It also gives the interviewer a chance to nudge you if your complexity claim is off — and that nudge is gold.

Pass 4: Code while narrating (5-10 minutes)

Now you write. Two rules:

1. Speak every non-trivial line. "I'm initializing the result as an empty list. Now I iterate through the input — and for each element, I check whether its complement is in the hash map…"
2. Don't apologize for typos. Fix them silently. Apologizing every time you backspace tanks the perceived signal density of the recording.

When you finish, trace through your code with the same small example you used in Pass 2. Catch bugs live. End with: "Time complexity is O(n), space O(n), and edge cases I've handled are empty input, single element, and duplicates. Anything you'd like me to refactor?"

That last question matters. It hands the interviewer back the lead and signals you can take feedback.

What to do when you get stuck

Get stuck out loud. Silent stalls read as panic; verbal stalls read as engineering:

• "I'm going to think for thirty seconds — is that okay?"
• "I don't immediately see the optimization. Let me try a smaller example."
• "What if I sort the input first? That's O(n log n) — better than O(n²), worse than O(n)."

Per the Pragmatic Engineer's writing on interview signal, the difference between a hire and a no-hire often comes down to whether the candidate kept the room informed when they hit a wall. The technical bar matters less than you think; the communication bar matters more.

About the author: Alex Chen is the founder of InterviewChamp.AI and writes about the modern tech interview from the inside — what changed, what works for new grads, and where the old playbook fails.