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

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

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.

Common failure modes

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.