Mock Set 1 — Mixed Easy/Medium, 45 min

Review boundary and corrected contracts

Learning objective: Run a cold mock of four unseen problems in 45 minutes, with no hints, and use a phase log to distinguish classification, template, implementation and time-management failures.

This is a deliberately compressed practice protocol, not a claim about the format of a particular employer's interview. The time boxes, scores and review intervals below are author-chosen conventions. Four attempts cannot estimate hiring readiness or isolate the cause of a performance change.

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

Watch first

Optional preparation, on a separate day: watch a recorded coding mock and note what happens before the first line of code. Look for a restatement, questions that affect the input contract, a small example and a complexity argument. Do not select that recording's problems for your cold set.

The original lesson's suggestions were Life at Google, Clement Mihailescu, CS Dojo and optional TechLead commentary. These are optional historical resources, not evidence for company scoring or verified durations. The protocol below is usable without them. Record any recent exposure; waiting overnight does not make a previously seen problem unseen.

Why this session exists

A pattern-labelled exercise supplies information that an unlabelled problem does not. A timed mixed set tests whether you can choose an approach as well as implement it. It may feel harder, but a poor first result is neither inevitable nor a diagnosis by itself.

Use the mock as a small observation exercise. A failure after naming the right family may still be a wrong invariant, a missing template, a coding error or an unrealistic time box. A comfortable solve also provides data: record the explanation, tests and elapsed time rather than dismissing it as uninformative. L59 uses the log to propose gaps; L60 tests targeted repairs.

Blank-file warm-up

None: this session measures retrieval without an immediate template refresher. Do ordinary equipment checks, but close editorials, notes and AI assistance before selecting the set. Record any accidental exposure instead of pretending the attempt was cold. A warmed attempt is still useful practice, just a different condition.

Pattern anatomy

The triage loop is classify → design → implement → verify. Maintain a process invariant: you can identify your current phase and its elapsed time. A pattern name is only a hypothesis; its invariant and preconditions decide whether it fits.

45-minute mock: four 11-minute slots + one minute for transitions.
Within EACH slot, elapsed time from opening its statement:
0:00–1:30  CLASSIFY: read the contract and constraints; propose an approach.
1:30–4:30  DESIGN: state the invariant, complexity and a small example.
4:30–9:30  IMPLEMENT: write the agreed approach; use local tests, not hints.
9:30–11:00 VERIFY: trace a normal case and relevant boundaries; record outcome.
At 11:00, stop this problem even if code is partial.
If classification stalls, write a brute-force baseline and its cost.
If the baseline is too slow, label it partial; do not call it constraint-valid.

Constraints narrow the search; they do not select an algorithm automatically. At n = 20, 2**n is about a million subsets but n! is vastly larger. At n = 10**5, quadratic pair enumeration is usually implausible under ordinary contest limits, yet the time limit, operation cost and other dimensions still matter. Sorted input enables some binary searches and two-pointer rules; you must prove the rule used.

The cue

Use this protocol when you want a cold, time-boxed sample rather than guided practice:

1. Select problems whose solutions you have not seen; replace a recognised problem and log the replacement.
2. Keep the timer visible and set a per-problem alarm.
3. Close assistance and record the permitted editor/testing tools in advance.
4. Commit to the hard stop instead of reallocating the whole session to one problem.
5. Prepare a live log before starting.

If one condition changes, label the deviation. Do not throw away the attempt or mix it silently with clean cold attempts.

Guided solve

Selection — 5 minutes outside the mock. Choose two Easy and two Medium problems by title, without opening solutions or topic tags. Titles can reveal patterns; skip an overtly familiar one. Difficulty and acceptance-rate filters are selection aids, not guarantees of equal effort. Work Easy, Easy, Medium, Medium, with the same 11-minute cap for each; this intentionally gives a broad sample, not generous solve time for every Medium.

Live log — five fields per problem:

• Time to a proposed pattern; write none if no approach arrived.
• Pattern and justification stated; add validated / invalid / unresolved during the later autopsy.
• Time to first substantive code, with phase-boundary timestamps alongside it.
• Outcome: clean solve, solve after debugging, partial or no submission; record test failures.
• The missing observation or question that would have helped. Draft it live; label later additions as retrospective.

Autopsy — 23 minutes after a 2-minute break. First inspect your own traces. Then consult an editorial or another correct solution to check the approach, not merely its tag. Several families may yield valid solutions. Assign a primary bucket, plus secondary causes when needed:

• Classification: the chosen approach or its preconditions did not fit. Repair with contrasting problems and explicit invariants.
• Template: the approach was justified but you could not reconstruct its state/update skeleton. Repair with a blank-file derivation.
• Implementation: the plan was sound but the code violated it. Repair with a minimal counterexample and regression test.
• Time: the justified approach and implementation were on track but unfinished at this time box. Inspect phase timing before prescribing faster typing.

For example, “sliding window” followed by a non-monotone signed-sum rule is still a design/classification problem, not automatically a speed problem. “Correct window invariant, but failed to delete a zero count” is an implementation problem. Keep both the observed evidence and your tentative diagnosis.

Close the editorial and re-solve non-clean attempts from scratch the next day. That second attempt is practice on a known problem, not another unseen measurement.

Solo timed

Run the four slots with no problem-specific hints. Before each implementation, say: “My approach is …; the state means …; it is valid because …; its cost is ….” If stuck, give the brute force and identify repeated work instead of guessing a fashionable data structure.

Do not infer that an Easy has one trick or that nested loops are always wrong. A small bounded input may permit them. Do not force a named pattern when a direct solution already meets the contract.

Timing rubric

The complete suggested session is 75 minutes:

Within each attempt the phase budgets sum to eleven minutes: 1.5 + 3 + 5 + 1.5. If design overruns, take the time from implementation rather than silently deleting verification. You may demonstrate a correct slow baseline, but label its constraint failure. If the autopsy needs longer, schedule that continuation explicitly; do not claim it fitted this budget.

Self-scoring checklist

Give 0–2 points for each process item: cold selection, live logging, four respected hard stops, verification on each attempt, and an evidence-backed autopsy. Use 2 for complete, 1 for partial and 0 for absent; note the specific deviation.

As an author-chosen triage rule, 8–10 means the protocol was mostly followed; 5–7 suggests comparing only compatible parts of the log; 0–4 suggests fixing the setup before repeating. These scores do not validate the sample or predict an interview result. Keep solve count as a separate outcome. A high process score and zero solves calls for diagnosis, not congratulations or a readiness verdict.

Performance criteria

Choose process targets before starting: for example, an initial hypothesis within 90 seconds, a stated complexity before code, and a reserved 90-second verification phase. Record actual times rather than turning targets into claims about what a learner “should” achieve.

For classification, count only approaches later shown to satisfy the contract; also retain unresolved rows. Report 3 of 4 validated rather than treating that small count as a stable accuracy estimate. For communication, check whether a listener could follow the plan, invariant and revisions.

Consider empty input if allowed, singleton input, duplicates/all-equal values and relevant extremes. For forbidden empty input, state the precondition rather than inventing an output. A largest-size case may need complexity reasoning instead of a hand trace. Use a normal case too.

Set a submission rule for this exercise, such as at most two platform submissions after local checks. More submissions are a review signal, not proof of a particular failure or a universal interview prohibition.

Recovery scripts

No approach: “The pairwise baseline takes O(n²). Which repeated lookup could I reuse? I still need to check whether the replacement is valid for these inputs.”

Wrong classification: “I assumed validity was monotone as the window expands. This signed-value example breaks that assumption, so I need another approach.”

Syntax blank: “I will write pseudocode for the state transitions first, then fill in the language details.” Pseudocode helps expose the plan; it does not necessarily satisfy an interview's implementation requirement.

Hard stop: “My approach is X, cost Y, and the unfinished work is Z.” Record that state and move on.

Structural bug: “This fails on this concrete input because … . I will revise the invariant rather than add a special case.” Narrate uncertainty about the claim, not a judgement about yourself.

Common failure modes in the room

Coding before checking the contract can commit you to an invalid plan. Staying on one problem destroys the intended four-attempt allocation. Using submissions as the only debugger hides whether you can design tests. Dropping verification removes a chance to catch faults, although no short trace guarantees correctness. Reconstructing timing afterwards introduces recall uncertainty; preserve timestamps where possible and mark estimates.

Misconception: “A bad mock means I should avoid mocks until I am ready.” A bad mock identifies questions to investigate, not a single cause. Compare the phase log with an untimed derivation or implementation to locate the gap. Likewise, anxiety is not proof that the measurement is valid.

Think of a simulator: its value is in examining specific actions, not assuming that a crash predicts every future flight. Alternating guided practice and occasional cold mocks exposes different skills. Pattern practice gives scaffolding; mixed mocks remove that cue but sample few problems. Neither replaces the other. After a repair, compare another mixed set cautiously: different problem difficulty prevents a causal claim that the repair alone changed your score.

Complexity

This lesson's main cost is time: 5 minutes setup, 45 mock, 2 break and 23 autopsy. Compare phase times across attempts descriptively; a difference between correctly and incorrectly classified problems is not a controlled estimate of the cost of guessing.

Self-check (answer follows each question).

Q: What are the four phases and their targets?

A: Classify 90 seconds, design 3 minutes, implement 5 minutes, verify 90 seconds: exactly 11 minutes per slot. Four slots use 44 minutes; transitions use the remaining minute.

Q: Why omit a template warm-up?

A: The intended condition is retrieval without immediate prompting. Warming up changes that condition; it does not make the practice worthless.

Q: What are the four failure buckets?

A: Classification/design, template reconstruction, implementation and time management. Choose a primary bucket from evidence and retain secondary causes.

Q: Why write the log during the mock?

A: Timestamps and contemporaneous notes reduce dependence on later recall. Label any reconstructed times as estimates.

Q: Why use a per-problem stop as well as a total timer?

A: It reserves an attempt for every selected problem. This buys breadth at the cost of depth; it is the purpose of this exercise, not a universal optimal allocation.

Q: You named the right pattern on all four but solved only two. What should you repair?

A: The names alone do not identify the failure. Inspect invariants, code and phase logs: a missing skeleton calls for a template drill, a wrong index for a regression test, and an otherwise sound unfinished attempt for time-box practice. Do not automatically label both misses “time failure.”

You can now… run and log the triage loop; justify a pattern or state a baseline; check complexity and permitted edge cases; respect the stop; diagnose the attempt using evidence; and use a recovery script rather than treating a weak result as a verdict.

Spaced queue

Record each problem's observed outcome. A suggested starting schedule is cold (clean, unassisted) +60 days; warm (slow or debugged) +21; hint +7; failed +2 and then +7 after a successful check. These are scheduling conventions, not experimentally established intervals for coding interviews. Shorten them when delayed performance calls for it.

For a non-clean attempt, also schedule tomorrow's scratch re-solve and record the date from which the later interval is counted. Preserve both attempts. The deliverables are four phase logs, checked approaches, concrete failure evidence and a repair queue—not a hiring score.

Corrective source notes

The APS summary of Dunlosky and colleagues' learning-techniques review rates practice testing and distributed practice highly across the educational settings reviewed. Its saved 2026-10-07 source was re-read for this review. It does not establish this mock's time boxes, score bands, company frequencies or hiring outcomes. The timing arithmetic above is derived directly; the practice protocol is an explicit design choice.