L58 · Mock Set 2 — Narrated & Recorded

Series: LeetCode — From Basics to Interview-Ready · Session 58 / 65 · Phase 4 · Interview simulation

Watch first

Watch these before you record, with a notepad, and do the following for each: pick one 60-second stretch and transcribe roughly what the candidate says. You are building a vocabulary of interview speech, and transcribing one minute teaches more than watching thirty.

Pay attention to sentence shape, not content. Notice how often a competent candidate says "so what I'm going to do is…" before typing, and how rarely they let three seconds of silence pass without labelling it.

Why this session exists

The previous session measured whether you can solve. This one measures whether an interviewer can tell that you solved.

Those are different, and the gap between them costs more offers than algorithmic weakness does. An interviewer cannot see your reasoning. They see typing and hear silence, and from that they must construct an assessment of how you think. If you solve the problem in twenty minutes of near-total quiet and then present a finished answer, you have given them almost nothing to grade — and worse, you have given them no opening to help you when you go down a wrong path.

Hearing yourself is brutal and it is the fastest fix available. Every specific verbal habit that undermines you — the trailing-off sentences, the twelve "um"s per minute, the four minutes of dead air while you think, the way you say "this is probably wrong but" before every correct idea — is invisible from the inside and unmissable on playback. Most people fix eighty percent of it after watching one recording, because the problem was never skill. It was that nobody had ever shown them the tape.

I want to be blunt about the discomfort. Watching yourself think out loud is genuinely unpleasant the first time. Do it anyway, once, and the return on that hour is larger than any equivalent hour of problem grinding at this stage.

Blank-file warm-up

None. Cold by design, same as L57.

But there is a two-minute setup that is not optional: verify the recording actually captures audio before you start. Record five seconds, play it back, confirm you can hear yourself. Discovering a silent recording after forty-five minutes of narration is a uniquely demoralising way to waste a session.

Any screen recorder works — OBS, QuickTime, the built-in recorder on your OS, or a Zoom meeting with yourself that records locally. What matters is screen plus microphone in one file.

Pattern anatomy

The pattern here is a narration protocol — a fixed set of things you say out loud, in a fixed order, so that speaking becomes structural rather than something you have to remember to do.

The invariant: the interviewer always knows what you are currently doing and why. Silence longer than about fifteen seconds violates it. So does typing without having announced what you are about to type.

# NARRATION PROTOCOL — say each of these out loud, in this order.
#
# 1. RESTATE (30s)
#    "So we're given X, and we need to return Y. The constraint is n up to 10**5."
#    Restating in your own words catches misreadings before they cost you ten minutes.
#
# 2. CLARIFY (30s)
#    "Can the input be empty? Can values be negative? Are duplicates possible?"
#    Ask two or three real questions. Not performative ones — questions whose answers
#    would actually change your approach.
#
# 3. EXAMPLE (60s)
#    Work one small example by hand, out loud, on the shared editor.
#    This is where you catch a wrong understanding for free.
#
# 4. BRUTE FORCE (60s)
#    "The obvious approach is nested loops, that's O(n**2), which given the constraints
#     is too slow — but let me use it as a baseline."
#    Never skip this. A stated baseline proves you understand the problem, and it gives
#    the interviewer a place to nudge you from.
#
# 5. OPTIMISE (2-3 min)
#    "The redundant work is recomputing the sum for each window. If I maintain a running
#     sum instead, each step is O(1), so overall O(n)."
#    Name the pattern. State the new complexity. Get agreement before typing.
#
# 6. CODE (8-10 min)
#    Narrate structure, not syntax. "Now the outer loop over right, expanding the window."
#    NOT "now I type f-o-r space r-i-g-h-t". Announce sections, then type them.
#
# 7. TRACE (2 min)
#    Walk your example through the finished code, out loud, line by line.
#    Say what breaks before the interviewer has to say it.
#
# 8. COMPLEXITY + EDGE CASES (60s)
#    Time, space, and the three inputs that could break it. Unprompted.

Print that. Keep it visible during the mock. Following a script feels artificial for the first ten minutes and then becomes invisible, which is exactly what you want.

The cue

Narration discipline is the deciding factor whenever these conditions hold — which is to say, in essentially every real interview:

1. Someone is watching you work and will assess your thinking. They cannot read your mind and will grade what they observed.
2. The problem is ambiguous in at least one respect. All real problems are. Silence means you resolved the ambiguity privately, possibly wrongly, and nobody caught it.
3. You might go down a wrong path. Narration is what lets an interviewer redirect you at minute four instead of minute eighteen. Silence forfeits that help entirely.
4. The role involves collaboration. Every engineering role does, and the interview is partly a simulation of working with you.
5. You are stuck. This is the counter-intuitive one — narration matters most when you have no idea. "I'm considering two framings and neither is working, here is what I've ruled out" is a strong signal. Silence while stuck is the weakest possible state, and it is the default nobody trains out of.

Guided solve

The session is solo, so here is the protocol rather than a worked problem.

Setup (5 minutes). Pick two unseen Mediums. Start the recorder. Confirm audio. Put the narration protocol somewhere visible. Set a 25-minute timer per problem.

Problem 1 (25 minutes). Run the protocol end to end. The rule for today is stricter than it sounds: if you notice you have been silent, say what you are thinking about, even if it is "I don't know yet". Especially then.

Two phrases to use deliberately, because they buy you real time without dead air:

• "Let me think about that for a moment" — then think for up to fifteen seconds. This is a socially normal pause. Unannounced silence of the same length is not.
• "I'm going to write the brute force first so we have something correct to improve on" — this legitimises a slow start and prevents the panic-optimising that produces broken code.

Problem 2 (25 minutes). Same protocol. Between the two, do not review the recording — that would let you self-correct before the second sample, and you want two comparable data points.

Playback (20 minutes). This is the session. Watch both recordings at 1.5× and count, with actual tally marks:

• Dead air over fifteen seconds. How many, and how long was the longest?
• Filler words. Count them in one representative minute and multiply. The number is usually shocking and it drops fast once known.
• Hedging before correct statements. "This is probably wrong, but..." preceding an idea that was right. Count these separately; they are the most damaging and the easiest to remove.
• Unannounced typing. Sections of code that appeared without you saying what they were for.
• Skipped protocol steps. Which of the eight did you drop? Almost everyone drops step 4 (brute force) and step 7 (trace).

Pick exactly one habit to fix. Not five. One, chosen because it appeared most often, and you carry it into L61.

Solo timed

Two unseen Mediums, 25 minutes each, narrated throughout, recorded.

• Medium 1 — before optimising anything, state the brute force and its complexity out loud. Most people's recordings show them jumping straight to a half-formed optimisation and then losing four minutes reconstructing what the problem even was.
• Medium 2 — deliberately narrate one wrong turn. When you abandon an approach, say why out loud: "this doesn't work because it requires the array to be sorted and it isn't". Explaining a rejection is one of the strongest signals available and almost nobody does it.

Timing rubric

75 minutes, and unusually for this track the playback is the load-bearing block. Protect it.

• 0–5 min · Setup. Pick two unseen Mediums by title. Start the recorder. Record five seconds, play it back, confirm audio. Protocol sheet visible.
• 5–30 min · Problem 1, narrated. 25 minutes hard.
• 30–55 min · Problem 2, narrated. 25 minutes hard. Do not review recording 1 in between — you need two uncontaminated samples.
• 55–75 min · Playback and tally. Both recordings at 1.5×, tally marks on paper, then pick exactly one habit.

Within each 25-minute problem:

If you must sacrifice something, sacrifice optimality of the final solution, never steps 1–4 or 7–8. A correct brute force, fully narrated and traced, grades better than a silent optimal solution.

Self-scoring checklist

Score from the playback, not from memory. Memory of your own narration is systematically generous. Two points each.

1. Longest dead-air stretch under 15 seconds? (2 = yes; 1 = one breach; 0 = several, or one over 45s.)
2. All eight protocol steps present in both recordings? (2 = all sixteen; 1 = one or two dropped; 0 = more.)
3. Structure narration rather than syntax narration? (2 = you announced blocks by purpose; 1 = mixed; 0 = mostly keystroke commentary or silence.)
4. Zero hedges before correct statements? (2 = none; 1 = one or two; 0 = it is a verbal tic.)
5. Complexity and edge cases given unprompted, before finishing? (2 = both problems; 1 = one; 0 = neither.)

8–10 → communication is not your bottleneck; return to algorithm work. 5–7 → one specific habit to fix; carry it to L61. 0–4 → run another recorded mock within a week; this is the highest-leverage repair available to you right now.

Performance criteria

Calibration targets for a narrated Medium at this point in the track.

Speech density. You should be speaking during roughly 60–80% of the session. Under 40% and the interviewer is guessing at your reasoning. Over 90% and you are probably narrating syntax, which is noise.

Dead air. No stretch over 15 seconds unannounced. Announced pauses ("let me think about that for a moment") do not count and are unlimited within reason.

Communication quality — the four things an interviewer is actually listening for:

• Did you restate the problem? Catches misreadings for free and takes 30 seconds.
• Did you ask a real clarifying question? One whose answer would change your approach. "Can the input be empty?" qualifies; "is this an array?" does not.
• Did you state a baseline before optimising? This is the single clearest competence marker in the protocol.
• Did you explain a rejection? Saying why an approach fails is a stronger signal than saying why one works, and almost nobody does it.

Edge-case coverage, spoken. Empty input, single element, all-identical values, maximum constraint. Named out loud before submitting, not discovered by a failing test. Roughly forty seconds; skipping it is pure discipline failure.

Recovery visibility. At least one moment per session where you were stuck and the tape shows you narrating through it rather than going quiet. If the recording contains no such moment because you were never stuck, the problems were too easy — pick harder ones next time.

Recovery scripts

The point of a script is that it runs when your working memory is full. Read these aloud twice before recording so the words are already in your mouth.

You need thinking time:

"Let me think about that for a moment."

Then think, for up to fifteen seconds. That is a socially normal pause. The identical fifteen seconds unannounced reads as being stuck.

You have gone quiet and noticed it:

"Sorry — I've been quiet. What I'm turning over is whether the array being unsorted rules out the two-pointer approach. I think it does, which pushes me toward a hash map."

Naming the silence and then filling it costs one sentence and completely resets the impression.

You are fully blank:

"I don't have the approach yet, so let me work a small example by hand and see what falls out."

Working an example aloud is the most reliable unsticking device available, and it looks like method rather than flailing. It also frequently works, which is the main reason to do it.

You said something wrong out loud:

"Actually, scratch that — that doesn't work, because it assumes the intervals are disjoint and they aren't. Let me back up."

Self-correction is a positive signal, not a negative one. Candidates who never walk anything back are usually the ones who never said anything.

You want to hedge and should not:

Replace "this is probably wrong but maybe a heap?" with "I think this is a heap problem, because we need repeated access to the minimum." Same content, same uncertainty, entirely different read. If you genuinely are uncertain, put the uncertainty on the claim, not on yourself: "I'm not certain the heap is optimal here, but it's correct and it's O(n log n)" — that is confident and honest at once.

Ten minutes left and nothing runs:

"I'm going to stop optimising and make the brute force work, so we have something correct. Then I'll talk through how I'd improve it."

Say this out loud. It converts a visible failure into a visible engineering decision.

Common failure modes

Narrating syntax instead of structure. "Now I'll write a for loop, i equals zero, i less than n" tells the interviewer nothing they cannot see. "Now the outer loop walks the right edge of the window" tells them your model. The recording makes this distinction obvious immediately.

Going silent exactly when it matters. Narration collapses at the moment of difficulty, which is the moment the interviewer most wants to hear from you. Watch for it on playback — the dead air will cluster precisely around the hard part.

Hedging before correct ideas. "I might be way off here, but maybe a heap?" when a heap is the answer. It reads as low confidence, and interviewers calibrate partly on confidence. Say "I think this is a heap problem, because we need repeated access to the minimum" instead. Same content, entirely different signal.

Explaining after coding rather than before. Writing twenty lines in silence and then narrating what you wrote is a summary, not collaboration. The interviewer needed the explanation at minute three, when they could still have redirected you.

Skipping the trace. Walking your own code through an example, out loud, catches bugs and demonstrates rigour simultaneously. It is the highest-value two minutes in the whole protocol and it is the first thing dropped under time pressure.

Fixing everything at once after playback. Attempting to correct five habits simultaneously in the next mock produces stilted, over-managed narration and none of the habits stick. One habit per mock.

Complexity

The session's time budget, since there is no single algorithm:

Per problem: 25 minutes narrated, which is roughly 4 minutes of protocol steps 1–4, 3 minutes of design, 15 minutes of coding with narration, and 3 minutes of trace plus complexity.

Playback: 20 minutes at 1.5× covers both recordings. Do not skim — the dead air is the data, and skipping through it removes exactly what you came to measure.

Overhead of narration on solve time: expect roughly 20–30% slower solving in the first narrated session. This shrinks with practice and never reaches zero. Budget for it rather than trying to eliminate it; the interview clock accounts for narration too.

Spaced queue

Both problems from today enter the queue at the status they earned. Status ladder unchanged:

• cold — solved clean, narrated throughout → 60 days
• warm — solved with a stumble or with narration collapsing → 21 days
• hint — needed the editorial → 7 days
• failed — no working solution → 2 days, then 7 days

Note the added condition on cold: a problem solved correctly but in silence does not qualify. This session grades both axes.

Also add a non-problem entry to your notes: the one habit you chose to fix. Check it explicitly on the L61 recording.