L57 · Mock Set 1 — Mixed Easy/Medium, 45 min

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

Watch first

These are not algorithm videos — there is no algorithm today. They are recordings of the thing you are about to simulate. Watch them the evening before the mock, not immediately before, so they inform your protocol without priming you on any specific problem.

Watch each one with a single question in mind: what is the candidate doing in the first two minutes, before any code exists? That two minutes is the entire subject of this session.

Why this session exists

Fifty-six sessions of pattern work have built something. This session finds out what.

Expect it to go badly. That is not encouragement-flavoured hedging, it is the honest prediction: the first timed mock after a long practice phase almost always feels like a collapse, because every prior session gave you the pattern name in the title. Today nothing does. The gap between "solve a sliding-window problem" and "recognise that this is a sliding-window problem in ninety seconds" is exactly the gap this session measures, and it is usually wider than people expect.

That gap is the point. A bad mock produces a list of specific, addressable failures. A comfortable practice session produces a feeling of progress and no information at all. You want the data.

The rule for today is that this is an experiment, not a performance. Experiments do not have good or bad outcomes, only informative ones. Your job is to run the protocol honestly and record what happened. L59 and L60 will use what you record here.

Blank-file warm-up

None. This session is cold by design.

Do not review templates beforehand. Do not "just quickly" re-read the sliding-window notes. If a template is not retrievable cold, that is precisely what today is designed to discover, and warming up first destroys the measurement.

Open the timer. Open four unseen problems. Begin.

Pattern anatomy

The pattern being trained today is not an algorithm. It is the triage loop — the thing you run in the first two minutes of every problem, before writing any code.

The invariant to maintain: at every moment you know which of the four triage phases you are in, and how long you have been there. Time blindness is what kills mocks. People spend twenty minutes in phase 2 without noticing.

# The 45-minute mock protocol. Per problem: ~11 minutes.
#
# PHASE 1 — CLASSIFY (target 90 seconds)
#   Read the statement twice. Read the constraints. Say a pattern name out loud.
#   Constraints are hints: n <= 20 means exponential is fine (bitmask/backtracking).
#   n up to 10**5 means n log n at worst. Sorted input means binary search or two pointers.
#   If no pattern name arrives in 90 seconds, write down the brute force and move to phase 2
#   anyway. A named brute force beats silent thrashing.
#
# PHASE 2 — DESIGN (target 3 minutes)
#   State the approach in one sentence, plus its complexity, BEFORE typing.
#   Check the complexity against the constraints. If it does not fit, do not start coding.
#
# PHASE 3 — IMPLEMENT (target 5 minutes)
#   Write it. No debugging by submission. No editorial. No search.
#
# PHASE 4 — VERIFY (target 90 seconds)
#   Trace one small case by hand. Check the empty input, the single-element input,
#   and whichever boundary the problem hints at. Only then submit.
#
# HARD STOP: at 11 minutes on a problem, record the state and move on.
# Four attempted problems with three solved beats one perfect problem and three untouched.

Write those four phase names on paper next to your keyboard. During the mock, every time you finish a phase, note the clock. That log is the deliverable.

The cue

Recognising the shape of the session matters as much as recognising problem patterns. You are in a mock-simulation situation — as opposed to practice — whenever these hold:

1. The problems are genuinely unseen. Not "seen six months ago". If you recognise the title, pick a different one; recognition contaminates the measurement.
2. A timer is running and visible. Not a vague sense of hurry. An actual clock you can see, because the skill being trained is time awareness.
3. All assistance is closed — no editorial tab, no notes file, no autocomplete beyond what an interview environment would give you. Turn off AI assistance in your editor completely.
4. You have committed to a hard per-problem stop. Without it, one hard problem eats the whole session and you learn nothing about the other three.
5. You have somewhere to write the log. A mock without a log is just anxious practice.

If any of those five is missing, you are practising, not simulating, and you should not count the result as data.

Guided solve

There is no guided solve today — the whole session is solo by construction. What follows instead is the protocol, written out so you can run it without decisions.

Selection (5 minutes, before the clock starts). Pick two Easy and two Medium you have never opened. The cleanest source is LeetCode's problem list filtered by difficulty, sorted by acceptance rate, skipping anything whose title you recognise. Do not read the statements while selecting — read only titles, and if a title tells you the pattern, skip it. Open all four in tabs, then close the problem list.

The mock (45 minutes). Start the timer. Work the four problems in order: Easy, Easy, Medium, Medium. Roughly eight minutes each for the Easies and fourteen for the Mediums, but the hard stop is what matters, not the allocation.

For each problem, log these five fields as you go. Not afterwards — as you go, because reconstructed timings are always flattering.

• Time to pattern name. From opening the statement to saying a pattern out loud. If you never got there, write "never".
• Pattern named, and whether it was right. Both matter. A wrong confident classification is a different failure from no classification.
• Time to first line of real code.
• Outcome: solved clean / solved with debugging / partial / no submission.
• The single sentence that would have unstuck you. Write this even for the ones you solved. It is the most useful field in the log.

The autopsy (25 minutes, timer off). This is where the value is, and it is the part everyone skips.

For each problem, classify the failure into exactly one bucket:

• Classification failure — you did not identify the pattern, or identified the wrong one. This is the most common and the most fixable. It points at L60.
• Template failure — you knew the pattern and could not produce the skeleton. Points at blank-file drills for that specific template.
• Implementation failure — right pattern, right skeleton, wrong indices or a missed edge case. Points at the verify phase, not at more pattern study.
• Time failure — you would have solved it with more minutes. Points at the triage loop, specifically at the phase-2 discipline of stating complexity before coding.

Then, and only then, read the editorials. Close them. Re-solve each problem you did not solve clean, from scratch, tomorrow. That is the two-attempt rule and it applies especially here.

Solo timed

The mock itself is the solo timed block. Two unseen Easy, two unseen Medium, 45 minutes total, hard stop at 11 minutes per problem.

Hints, deliberately generic since the problems are yours to pick:

• Easy 1 — read the constraints before the statement's second paragraph. Easies usually have exactly one intended trick and the constraints point at it.
• Easy 2 — if you find yourself writing nested loops on an Easy, ask what a hash map would buy you.
• Medium 1 — name the pattern before you name the data structure. The data structure follows from the pattern, never the reverse.
• Medium 2 — if nothing arrives in ninety seconds, write the brute force, state its complexity out loud, then ask which step of it is doing redundant work. That question is where most optimisations come from.

Timing rubric

The 75 minutes are not negotiable and not evenly distributed. Written out so you make zero decisions on the day:

• 0–5 min · Selection. Titles only. Four unseen problems, two Easy, two Medium. Close the problem list. Clock is not running yet.
• 5–50 min · The mock. 45 minutes, four problems, hard stop at 11 minutes each. Audible per-problem alarm, not just a session timer.
• 50–52 min · Cool-down. Two minutes away from the screen before the autopsy. Do not skip this; autopsy written in the immediate aftermath of a bad mock is contaminated by frustration and tends to over-attribute everything to "I'm bad at this".
• 52–75 min · Autopsy. Timer off. Bucket each failure, then and only then read editorials.

Within each 11-minute problem block:

If a phase overruns, do not borrow from verify. Borrow from implement by shipping something simpler. The verify phase is 90 seconds and catches the bugs that otherwise cost five minutes.

Self-scoring checklist

Score the session, not the problems — today the protocol is what is being graded. Two points each.

1. Selection was genuinely cold? (2 = no title recognised; 1 = one borderline; 0 = you picked something familiar because you were nervous.)
2. Log written during, not after? (2 = all five fields, live; 1 = partial; 0 = reconstructed.)
3. Hard stop respected on every problem? (2 = all four; 1 = one overrun; 0 = more.)
4. Verify phase run on every attempted problem? (2 = all; 0 = you cut it under time pressure.)
5. Autopsy completed the same day, with every failure bucketed? (2 = yes; 0 = "tomorrow".)

8–10 → the protocol held; the solve count is now meaningful data. 5–7 → usable data with caveats; note which discipline slipped. 0–4 → the mock did not measure what you think it measured. Re-run it within three days rather than acting on the numbers.

Note what is not on this list: how many you solved. That number is an output, not a target. A two-of-four with a clean protocol is worth more than a four-of-four where you quietly peeked at a hint.

Performance criteria

What "good" looks like at this point in the track — use these as calibration, not as a pass mark.

Time to pattern name. Under 90 seconds on Easy, under 3 minutes on Medium. This is the headline metric of the whole phase and the one that should visibly improve between this mock and your next.

Classification accuracy. At least 3 of 4 correctly classified, even if not all are solved. Classification is upstream of everything; getting it right and running out of time is a much better position than solving two and misclassifying two.

Communication quality — relevant even solo, because you should be narrating aloud:

• You said the pattern name out loud before touching the keyboard.
• You stated the complexity of your approach and checked it against the constraints, aloud, before coding.
• You named at least two edge cases before submitting, not after failing on them.
• When stuck, you narrated what you were trying rather than going silent.

Edge-case coverage. For every problem, you explicitly considered: empty input, single element, all-identical elements, and the largest constraint value. Four checks, roughly forty seconds. Missing these is the most common avoidable failure and it is pure discipline, not knowledge.

Submission discipline. At most two submissions per problem. Three or more means you were debugging by submission, which the interview environment does not permit.

Recovery scripts

Blanking is a when, not an if. Practise these out loud during the mock even though nobody is listening — the point is to make the words automatic before there is an audience.

Nothing arrives in the first 90 seconds:

"I don't have a pattern yet, so let me start from brute force. The most obvious correct thing is to check every pair, which is O(n²). Given n is up to 10^5 that's too slow, so I need to eliminate the inner loop — let me look at what the inner loop is recomputing."

This is the highest-value script in the session. It converts a blank into visible structured work, gives the interviewer something to hint against, and — genuinely — finds the answer maybe half the time, because "what is the inner loop recomputing?" is where hashing, prefix sums, and two pointers all come from.

You classified confidently and it is not working:

"I assumed this was a sliding-window problem, and the window isn't monotone the way I expected. Let me re-read the constraints — I may have the wrong pattern."

Abandoning a wrong classification out loud is a strength signal. Silently forcing it is the single most expensive mistake available to you.

You are at the hard stop with partial code:

"I'm out of time on this one. Where I got to: the approach is X, complexity Y, and what remains is Z. Moving on."

Say it, write it in the log, move. Do not negotiate with yourself for "just two more minutes" — that negotiation is how one problem eats the session.

Your mind goes fully blank on syntax:

Write pseudocode. Nobody has ever failed an interview for writing # sort intervals by end time instead of the exact lambda. Get the structure down, fill in the syntax after. Blanking on syntax while the structure is in your head is a working-memory overflow, and dumping the structure to the page is the fix.

You realise mid-implementation that the approach is wrong:

"This won't work because [reason]. Rather than patch it, let me go back thirty seconds and reconsider — the fix is probably at the design level."

Patching a structurally wrong approach is where the remaining minutes go to die.

Common failure modes in the room

Coding before classifying. The single largest source of lost time. You start typing a plausible loop, three minutes later the approach does not generalise, and you have neither code nor a plan. The phase-2 rule — one sentence of approach plus a complexity, spoken before any typing — costs thirty seconds and prevents this entirely.

Ignoring the hard stop. One problem consumes twenty-five minutes, two problems go untouched, and the session yields one data point instead of four. Set an audible per-problem alarm, not just a session timer.

Debugging by submission. Submitting to see which test fails is a habit the practice environment rewards and the interview environment does not have. Trace by hand instead. If you submit more than twice on one problem today, log it as an implementation failure regardless of the eventual outcome.

Skipping the verify phase because time is short. This inverts the actual economics: the verify phase costs ninety seconds and catches the empty-input and single-element bugs that otherwise cost five minutes of confused debugging.

Reconstructing the log afterwards. Memory systematically compresses the stuck periods. A log written after the fact will show you spending three minutes on something that took nine.

Complexity

Not an algorithm today, so the complexity that matters is the session's time budget — and it is worth being explicit because time is the scarce resource being trained.

Per problem: classify 90s, design 3min, implement 5min, verify 90s. About eleven minutes, hard stop.

Per session: 5 minutes selecting, 45 minutes mocking, 25 minutes on the autopsy. The autopsy is over a third of the session and that ratio is deliberate.

Cost of skipping the classify phase: empirically, on your own log — this is the number to watch across mocks. Compare your time-to-first-code on problems you classified correctly versus incorrectly. The gap is your personal cost of guessing.

Spaced queue

Every problem from today's mock enters the queue immediately, at the status its outcome earned:

• cold — solved clean within the time box, no debugging → 60 days
• warm — solved but slowly or with debugging → 21 days
• hint — needed the editorial to get started → 7 days
• failed — no working solution → 2 days, then 7 days

Anything below cold also gets a re-solve from scratch tomorrow, before its queue interval starts. That re-solve is the two-attempt rule and it is what converts today's discomfort into retained skill.