Mock Set 2 — Narrated & Recorded

Review boundary and corrected contracts

Learning objective: Record screen and audio while solving two unseen Medium problems, then inspect whether your explanations make the reasoning, uncertainty and verification understandable.

This is communication practice, not a validated hiring assessment. Silence thresholds and scores below are adjustable observation rules, not requirements imposed by every interviewer. Recording can make behaviour inspectable; this lesson does not establish that it is the fastest fix or predict a percentage improvement.

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

Watch first

Optional preparation: transcribe one minute of a recorded mock, then label each sentence as contract, plan, invariant, uncertainty, code purpose or verification. Notice sentence shape: “I will maintain … because …” explains more than a list of keystrokes. Pauses may be useful; do not treat continuous speech as the goal.

Historical suggestions from the original lesson are Clement Mihailescu with Ben Awad, TechLead commentary and Fireship. These optional links and their original labels are not primary evidence about hiring criteria; availability, video content and durations have not been freshly verified. You can perform the same annotation on your own recording.

Why this session exists

A correct program and a clear explanation are separate things to inspect. Code and tests do convey reasoning, but they may not reveal why you rejected an alternative or what an ambiguous input means. Saying those decisions aloud gives a partner an opportunity to question them before implementation.

Playback supplies timestamps and examples of what was actually said. It may reveal unexplained jumps, long unlabelled pauses or a claim made without justification. It can also show that a pause was followed by a clear explanation and needed no repair. Do not infer lost offers, a communication disability or a fixed improvement rate from speech counts. The output is one actionable observation, not a personality judgement.

Blank-file warm-up

No algorithm warm-up: keep the problem attempts cold. Do a five-second recording test, play it back, and confirm both editor visibility and microphone audio before starting. Use a recorder whose local capture/export you have checked; features depend on the tool and platform.

Record only your own practice. Hide notifications, credentials and unrelated windows; obtain consent before recording another person. Keep the file private unless you deliberately choose to share it. Choose a communication mode that works for you—spoken narration, typed reasoning or an agreed accommodation—and record that mode when comparing sessions.

Pattern anatomy

The narration protocol makes decisions visible in eight steps. The useful invariant is not “I am always speaking,” but “a listener can identify the current goal, assumptions and reason for the next action.” Check that on playback instead of inferring it from speech density.

25-minute problem slot:
0:00–4:00   RESTATE, CLARIFY, EXAMPLE, BRUTE FORCE
             State input/output; ask questions that affect the approach;
             trace one small case; give a baseline and its cost.
4:00–7:00   OPTIMISE
             Identify redundant work; justify the invariant and complexity.
7:00–22:00  CODE
             Announce blocks by purpose, then implement and test them.
22:00–25:00 TRACE, COMPLEXITY + EDGE CASES
             Walk the actual code; check permitted boundaries;
             distinguish correct small-case behaviour from constraint fitness.

For a baseline, a sentence may suffice when its correctness is clear. You do not have to implement a slow solution before an already-justified optimal one. If you cannot optimise, label the baseline's limitation; clear speech does not make an infeasible algorithm sufficient.

The cue

Use this exercise when someone must follow your reasoning while you work, when the contract needs clarification, or when an earlier mock left a reviewer unsure why you chose an approach. It is also useful when you become silent at a difficult decision and want to inspect that transition.

Ask real questions, not a ritual list: empty input, duplicate handling or whether order must be preserved can change the algorithm. If the statement already answers them, acknowledge the contract rather than asking again. A reviewer may choose not to give hints; narration creates an opportunity for feedback, not a guarantee.

Guided solve

Setup — 5 minutes. Select two unseen Mediums, verify recording and display the protocol. Set a 25-minute timer for each. Keep permitted tools and assistance consistent with L57 and record any changes.

Problem 1 — 25 minutes. Restate the task, show an example, explain your plan and implement it. If you need thinking time, say “I am checking whether this invariant survives duplicates,” then take the pause. When you notice a long silence, give a useful update rather than filler.

Problem 2 — 25 minutes. Repeat without reviewing recording 1 between attempts. This avoids one deliberate feedback intervention, but the samples still differ in difficulty and you may learn during the first attempt. They are not independent experiments.

Playback — budget at least 34 minutes at 1.5×, plus tally/rewind time. Fifty recorded minutes divided by 1.5 is 33⅓ minutes. Watch both if you want whole-session counts. If you have only 20 minutes, preselect a sample and label it partial; do not claim to have reviewed every pause.

Tally these with timestamps:

• Unannounced pauses longer than your chosen threshold, such as 15 seconds. Note whether a listener actually lost the thread.
• Filler words in a fixed one-minute sample. Report that sample's count; multiplying it does not establish the whole-session rate.
• Unsupported hedges or assertions. Replace “I am probably bad at this” with uncertainty about a concrete claim; do not suppress warranted uncertainty.
• Code blocks introduced without their purpose being explained.
• Missing protocol steps, especially the baseline, invariant and final trace.

Pick one observable change for the next mock. For example: “Before the shrink loop I will state what makes the window invalid.” More speech alone is not a useful target.

If playback is uncomfortable: start with audio only. It can assess verbal explanations, but checking unexplained typing and whether a trace matches the code requires the screen. Mark those checks unreviewed until you view it.

Solo timed

Solve the two problems with narration of decisions, not a running description of every character you type. For the first, make the baseline-to-improvement argument explicit. For the second, explain a rejected approach if one genuinely occurs; do not manufacture a wrong turn or choose an invalid method to satisfy a rubric.

After a quiet interval, say what you checked and what remains unresolved. A natural successful attempt with no prolonged difficulty is still useful communication data, not proof that the problem was too easy.

Timing rubric

Plan roughly 90–100 minutes for full playback and review. A 75-minute variant has only 20 review minutes and must use explicitly sampled playback or defer the rest. Fifty minutes of footage cannot fit into 20 minutes at 1.5×.

Inside each problem reserve 4 minutes for steps 1–4, 3 for optimisation, 15 for code and 3 for trace/complexity. These are practice budgets. If design takes longer, simplify the implementation target and disclose its limits rather than declaring that a narrated brute force always grades better than a silent optimal solution.

Self-scoring checklist

Score the reviewed footage, not recollection. Use 0–2 for each item: understandable updates around pauses; eight protocol steps; structure rather than syntax narration; claim-directed uncertainty; and explicit complexity/edge-case checks. Give 2 for consistent, 1 for partial and 0 for absent, with one timestamp as evidence.

As a planning convention, 8–10 means this checklist was mostly met in the footage reviewed; 5–7 suggests a concrete habit to target; 0–4 suggests another recording after one focused rehearsal. None establishes that communication is or is not your overall bottleneck. If playback was sampled, the score describes only that sample. Adapt the pause criterion to the agreed communication mode rather than penalising natural speech differences.

Performance criteria

Use legibility of reasoning, not a 60–80% speech quota. Can a listener state the input contract, chosen invariant, reason an alternative fails and meaning of the tests? If not, identify the missing explanation.

A 15-second pause marker is a prompt to inspect context, not evidence of incompetence. Announced thinking time still needs a useful follow-up. A clear baseline is helpful when it makes the optimisation understandable, not because it proves competence by itself. A rejection must name the violated precondition, not just say “that won't work.”

For spoken verification, include a normal case and relevant boundaries: empty if allowed, singleton, repeated values and constraint extremes. If testing the maximum is impractical, give the cost argument. Record recovery visibility when difficulty actually occurred; do not require a staged moment of confusion.

Recovery scripts

Need time: “Let me check whether removing the left item can restore validity. I will use this small example.” Then think and report the result.

Went quiet: “I was comparing two approaches. Sorting changes the order the output needs, so I am testing a map-based alternative.” Unsorted input alone does not rule out all two-pointer algorithms; name the precondition of the specific one you meant.

Fully blank: “I do not have a fast approach yet. I will work a small case and state the obvious baseline.”

Wrong claim: “Scratch that: I assumed these intervals were disjoint, but they can overlap. This counterexample invalidates my argument.”

Uncertain: “A heap gives repeated access to the minimum. I still need to justify the operation count and whether a simpler structure suffices.”

Time nearly gone: “I will finish and test this baseline. It is correct on the stated small cases but too slow at the largest bound; the optimisation remains unfinished.” These scripts expose decisions; they do not guarantee a favourable grade.

Common failure modes

Keystroke narration adds little beyond what is visible. Announcing a block's purpose and invariant is more informative. Explaining everything only after coding removes chances for early feedback. Skipping a trace leaves the code less checked. Unqualified confidence can conceal a weak proof just as excessive self-directed hedging can obscure a sound one.

Misconception: “I must solve everything silently, then present a perfect plan.” A brief private pause can help; a long unexplained implementation can make collaboration difficult. Alternate thinking with concise updates. Conversely, continuous speech can consume attention and obscure the explanation. The choice is not total silence versus an uninterrupted monologue.

Recording is one way to observe these behaviours; partner feedback and written reasoning are others. Treat the next recording as a chance to test the chosen change. Fewer tallies may reflect easier problems, shorter footage or a different sample, not necessarily a durable skill gain. One habit per session is a manageable practice design, not a claim that several changes cannot consolidate.

Complexity

The exercise uses 50 minutes of solving plus setup and review. Full 1.5× playback costs 33⅓ minutes before pauses; narration's effect on solving time must be observed, not assumed to be 20–30%. Keep separate solve, footage and review durations.

Self-check (answer follows each question).

Q: Why explain what you are considering when stuck?

A: It exposes the alternatives and failed assumptions so a listener can follow or offer feedback. It does not oblige them to supply a hint, and a short labelled pause is legitimate.

Q: What separates syntax narration from structure narration?

A: Syntax names visible keystrokes; structure names the block's purpose, state and invariant. “This loop removes items until the distinct-count bound holds” explains the model.

Q: Why mention a brute-force baseline when you see a faster solution?

A: It can make the improvement and its correctness easier to follow. State it briefly where useful; do not spend the session implementing an unnecessary baseline or claim that naming it proves understanding.

Q: Why target one habit after playback?

A: A narrow target is easier to practise and inspect on the next recording. It is a scope choice, not evidence that all other changes would fail.

Q: Which two steps deserve an explicit omission check?

A: Step 4, the baseline, and step 7, the trace. The lesson asks you to check them; it has no measured population data showing that they are the most commonly skipped steps.

Q: Both problems were solved correctly with almost no speech. Was the session useful?

A: Yes: it produced code and evidence of little narration, but it did not demonstrate the intended explanation skill. Review what reasoning was visible, then repeat with purposeful updates. Do not infer a real hiring outcome from silence alone.

You can now… run the eight-step protocol, explain code by purpose, ask contract-changing questions, justify alternatives and uncertainty, trace the code aloud, inspect pauses in context and select one evidence-backed improvement. A 15-second marker is a practice aid, not a speech norm.

Spaced queue

Track algorithm outcome and explanation outcome separately. A clean solution with unclear narration need not lose its algorithm-retrieval status, but still gets a communication follow-up. For this combined exercise, reserve the label cold for an unassisted correct attempt with an understandable explanation.

The suggested ladder remains cold +60 days, warm +21, hint +7, failed +2 then +7 after success. Adjust these author-chosen intervals to delayed results. Keep the chosen habit and its timestamps beside the problem records and check it on the next recorded mock, including L61 if following the sequence.

Corrective source notes

The saved 2026-10-07 APS learning-techniques review summary was re-read. Its support for practice testing and distributed practice does not validate recording as the fastest intervention, speech-percentage thresholds, hiring grades or this schedule. Playback duration is arithmetic; the narration rubric is a practice design.