L58 · Mock Set 2 — Narrated & Recorded

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

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.

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.