Contest Simulation

Review boundary and corrected contracts

These are practice protocols, not hiring rubrics. Times, score bands and review intervals are adjustable conventions; neither a difficulty label nor a score predicts an interview outcome. Record the input contract, evidence of correctness and what remains uncertain.

Learning objective: Run a timed contest or equivalent four-problem simulation, make explicit switching decisions, and diagnose errors without assuming their cause.

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

Watch first

Optional pre-reading, outside the timed session. These original links are retained as navigation; they were not watched or externally revalidated in this review. Use them to collect observations, not as governing evidence for company frequency, stress effects or hiring outcomes.

• How I Got Good at Coding Interviews — Compare the suggested training routine with your own constraints.
• Medium Coding Interview With Ben Awad — Observe changes of approach and the handling of a stalled attempt.
• 10 Common Coding Interview Problems — Solved! — Optionally revisit two familiar problems for editor warm-up, not a new-topic cram.

Why this session exists

A live contest supplies an external deadline and another setting in which to observe your work. A virtual contest or supervised mock can serve the same training purpose when live timing or public ranking is unhelpful. People respond differently to pressure; this lesson does not infer adrenaline, working-memory changes or interview transfer from a timed result.

The distinct skill is selection under a fixed budget: compare the remaining work on several problems, test before submitting and decide when to switch. Both knowledge and execution matter. An error under time pressure is evidence to investigate, not automatically a “state failure.”

Use the four-problem, ninety-minute format below as a controlled simulation. For an actual event, read its current rules first: duration, assistance restrictions, scoring, wrong-submission penalties and test-case visibility may differ. This protocol is not a statement of the current rules of every LeetCode event.

Blank-file warm-up

Use fifteen minutes before the clock for two familiar Easy problems if that helps you settle into the editor, then five minutes for setup and rules. This is a proposed routine, not proof that a warm-up prevents a first-problem bug. Record whether you warmed up so later comparisons use similar conditions.

Choose the language and allowed imports, test input/output once and disable prohibited assistance. Do not open the selected problem statements until the clock starts. Use the same setup for comparable virtual runs.

Pattern anatomy

The protocol is contest triage: estimate remaining effort and update that estimate when evidence changes. “Expected points per minute” is a decision heuristic, not a quantity you know exactly or a provably optimal online policy.

# FOUR-PROBLEM SIMULATION — 90 minutes
# 0–3: skim all statements; note constraints, rough effort and candidate patterns.
# 3–15: attempt the best initial candidate (Q1 by default).
# 15–40: next promising candidate (Q2 by default).
# 40–75: attempt Q3 or Q4; reassess at minute 60.
# 75–90: finish and verify the most plausible remaining submission.
# At minute 60: switch if there is no justified approach or concrete near-term fix.
# Extend only for a named testable fix with a small explicit time cap.
# Before submission: examples, an independently worked edge case, constraints.
# Simulation score: accepted problems only; no score for partial implementations.
# Keep wrong-attempt count separate; any event time penalty follows its own rules.

Read all four for triage, not full comprehension in three minutes. Q labels are positions, not universal difficulty promises; choose another order if your evidence supports it. Do not revisit already accepted code merely to make it prettier while another submission is feasible.

The cue

Use this exercise when you want to compare timed and untimed error patterns, practise switching, or make a self-imposed stop more credible. If broad prerequisite gaps dominate L59, first repair some of them; the contest can still reveal gaps but is not an efficient substitute for all concept study.

A time-pressure gap can come from unfamiliar problems, implementation fluency, fatigue, narration demands or anxiety. Log conditions and compare several attempts before selecting an explanation. A real interview deadline is a reason to rehearse, not evidence that contest stress is identical to interview stress.

Guided solve

Before: 20 minutes. Warm up for fifteen, set up for five, read the event rules, and choose a checkpoint policy. Write down what would justify extending a problem at minute 60: for example, a proven algorithm with one localized off-by-one failure and a three-minute test plan.

During: 90 minutes. Run the protocol. When a submission fails, read the displayed case if available. Some events hide tests; then reproduce a small counterexample locally and inspect the contract before changing code. Distinguish an incorrect approach from a transcription bug or complexity problem. Record submission time, result and reason for the next change.

After: at least 30 minutes. After the event permits solution access, compare editorials for all four problems, including solved ones. Reproduce the decisive invariant rather than copying code. Thirty minutes is a starting budget; schedule unfinished reviews explicitly rather than claiming every editorial can be understood within it.

Answer four questions in writing:

1. Which problem used the most time relative to my initial estimate, and which assumption was wrong?
2. How many wrong submissions occurred, and which were approach, implementation or missed-boundary errors? A single failure can have several causes.
3. Did I read all four, test before submitting and follow the checkpoint rule? If I extended, what new evidence justified it?
4. What changed compared with similar untimed work, and which explanations remain possible? Separate observations (“missed n=0”) from causes (“pressure made me rush”).

Rank is context, not a diagnosis. It depends on the participant pool, task mix and event rules. Save it if useful, but track accepted count, wrong attempts, time to a correct submission, review completion and the actual failures. A changing rank alone cannot establish learning or hiring readiness.

Solo timed

Run the ninety-minute block unaided, subject to the event's rules. Q1 still needs a contract and boundary check; Q2 deserves a justified approach rather than immediate commitment to the first pattern name; Q3 needs a checkpoint; Q4 deserves inspection rather than automatic dismissal.

Use a hard stop for comparability, but attend to real health/accessibility needs. If a virtual session is interrupted, record elapsed time and the interruption; it becomes a modified practice observation, not worthless data or evidence of poor discipline.

Timing rubric

The allocation is 3 + 12 + 25 + 35 + 15 = 90 minutes; minute 60 is an internal checkpoint in the 35-minute block, not extra time. Alarms are optional aids. A checkpoint is valuable because it demands evidence, not because your earlier self is always more rational.

Self-scoring — process over rank

Six items contribute 0–2 each, total 12. Keep them separate as well as summed:

• Read all four: 2 = all skimmed with estimates; 1 = incomplete inventory; 0 = started without triage.
• First candidate clean: 2 = accepted on first attempt; 1 = one wrong attempt; 0 = more or not accepted. This mixes correctness with process; record difficulty too.
• Test before submit: 2 = examples plus an independent edge case for every submission; 1 = inconsistent; 0 = no deliberate checks.
• Checkpoint used: 2 = evidence-based switch or capped extension; 1 = late reassessment; 0 = no reassessment.
• Working code submitted: 2 = all verified candidates submitted; 1 = one delayed; 0 = left working code unsubmitted. If none was working, mark this not applicable and report the adjusted denominator.
• Review completed: 2 = four editorials and written diagnosis; 1 = scheduled partial review; 0 = no review.

For all six applicable items, 10–12 means few omissions, 6–9 suggests selecting one recurring omission, and below 6 suggests simplifying the next run. These bands are authored labels, not typical-score statistics. Even a perfect process score does not prove that only pattern coverage remains to improve.

Building your own contest set (virtual mode)

Use a past set you have not seen. Close disallowed assistance and reserve a ninety-minute window. Do not impose social penalties for stopping; external accountability should be voluntary and useful.

For a synthetic set, choose one from each slot below. These are mechanism/difficulty examples, not company-frequency claims. The 10/20/30/remainder slot labels are rough solving targets, not an additional schedule: after the three-minute scan, retain time for checking and use the timing rubric's checkpoints.

• Q1 slot · Easy, 10 min — Two Sum (1), Valid Parentheses (20), Best Time to Buy and Sell Stock (121).
• Q2 slot · standard Medium, 20 min — Product of Array Except Self (238), Group Anagrams (49), Number of Islands (200), Merge Intervals (56).
• Q3 slot · harder Medium, 30 min — Longest Increasing Subsequence (300), Word Search (79), Course Schedule II (210), Find Median from Data Stream (295).
• Q4 slot · Hard, remainder — Sliding Window Maximum (239), Largest Rectangle in Histogram (84), Median of Two Sorted Arrays (4).

Draw without reading statements, record recognition if it occurs, and run the same review. Virtual or self-assembled sessions may feel different from live events; record the difference instead of assuming one is always a weaker stimulus.

Common failure modes

Starting before triage: you may miss a better-fit problem. A scan is an investment, not a guaranteed highest-return action.

Submit-and-see debugging: guessing instead of testing wastes time and may incur the event's penalty. Development and interviews can permit running tests; deliberate local debugging is not the same as blind judge submissions.

Ignoring the checkpoint: “I feel close” is insufficient. Write the remaining step and test; without concrete evidence, switch. A proven solution with a tiny known correction can justify one capped extension.

Polishing rather than submitting: in this simulation there is no partial-implementation credit. Verify correctness before submitting, but do not withhold correct code for cosmetic improvement.

Reading rank as a verdict: participant mix and task difficulty confound comparisons. Use it alongside artifacts, not as a personal or professional grade.

Skipping feedback: save a review slot and delayed re-solve. Do not assume the time spent competing alone produced understanding.

Contests can exercise careful reading, time allocation and testing, but they also teach problem-solving. They are not the only setting for performance practice and do not reliably induce a particular physiological state. A dress-rehearsal analogy describes the intention, not a scientific equivalence. Compare timed and untimed logs, identify a specific change, test a repair, and look for repetition on later attempts.

Live events offer an external schedule and common task set, with less flexibility and possibly unwanted ranking pressure. Virtual events offer scheduling control but require you to record assistance/interruptions honestly. Choose the setting you can use constructively; neither guarantees unseen mechanisms or interview transfer.

Complexity

Budget: 20 minutes setup/warm-up + 90 minutes contest + at least 30 minutes review = at least 140 minutes, excluding optional pre-reading and delayed re-solves. All four tasks and the accepted-only score are this simulation's contract; check actual event rules separately.

Allocation: 3 + 12 + 25 + 35 + 15 = 90. Two solved versus four solved is not a universal competence scale. Compare the errors and task demands before interpreting a count.

Self-check (answer follows each question).

Q: Why read all four before starting?

A: Their order may not match your familiarity or estimated effort. A scan lets you choose deliberately and revise that choice as evidence arrives.

Q: What can a live contest add to self-timed mocks?

A: An external deadline, shared tasks and possibly ranking pressure. Self-timed or supervised mocks can also be demanding; a contest does not uniquely guarantee adrenaline or learning transfer.

Q: Why is blind submit-and-see debugging costly?

A: It spends time without a causal hypothesis and may add penalties under the event's rules. Use examples and independently worked edge cases first; hidden tests may not reveal a failing input.

Q: At minute 60 you feel close to solving Q3. What should you do?

A: Apply the precommitted evidence rule. If you cannot name a justified remaining step, switch. If a concrete local fix and test fit a short cap, record the extension and stop when that cap ends.

Q: Why is rank insufficient as the metric for this session?

A: Participant pool, task mix and scoring vary. Track correctness, wrong attempts, timings and diagnosed failures alongside it; neither rank nor solve count alone identifies the cause.

Q: You solve Q1 and Q2 but repeatedly freeze on Q3. What does that establish?

A: A repeated difficulty boundary, not a unique diagnosis. Inspect whether the missing piece is a prerequisite, decomposition, implementation, time or pressure. Try L61's probes if composition is the gap; learn a missing concept if you cannot explain the editorial's invariant.

Recovery scripts

Early failure: “This is one attempt. I will inspect the feedback or construct a small failing case before changing code.” The penalty, if any, is whatever the event rules specify.

No approach after twenty minutes: isolate constraints. n <= 20 may permit a subset search, but factorial work can still be too large; small values permit buckets without requiring them; sorted input suggests testing monotonicity, not automatically two pointers.

Checkpoint feels painful: “What specifically remains, and can I test it inside the extension cap?” If the answer is vague, save the state and switch files.

Time-limit exceeded: count actual operations before micro-optimizing. With n=100,000, a full all-pairs scan has about 10^10 ordered pairs; a new algorithm is likely needed under ordinary contest limits. Time limits and operation costs still matter.

Ten minutes and two partial solutions: compare the remaining correctness work and finish the more plausible one. In this accepted-only simulation, two incomplete submissions earn no solved-problem credit.

Unhappy after finishing: write the four review answers before interpreting rank. A disappointing observation can inform the next experiment without defining your capability.

Checkpoint

You have the artifacts when you can:

• Inventory all four tasks and explain the chosen order.
• Prepare the editor and record warm-up conditions.
• Apply a precommitted switch/extension policy using evidence.
• Read available failure feedback or construct a counterexample before resubmitting.
• Submit verified code rather than polishing past the deadline.
• Score the six process items with the applicable denominator, while retaining solve count and rank as context.
• Use constraints to generate and validate candidate methods.
• Review all four editorials and answer the four diagnostic questions, extending the review budget if necessary.
• Name observed timed/untimed differences without declaring an unmeasured stress mechanism.

Spaced queue

Enter all four tasks, including solved ones, with assistance and error notes. Suggested intervals: cold 60d (independent and correct), warm 21d (correct but slow/debugged), hint 7d (assisted, including editorial completion), failed 2d then 7d (not yet implemented correctly). Adjust intervals to later recall; the numbers are not experimentally calibrated for this curriculum.

After permitted editorial review, reimplement unsolved mechanisms tomorrow, especially Q3/Q4. Later, use an unseen variant to distinguish recall of this exact answer from transfer. A live event can contain familiar mechanisms, so mark prior exposure rather than calling all contest data uncontaminated.

Carry forward the initial scan, evidence-based checkpoint, accepted-only simulation rule, test-before-submit habit and diagnostic log. Contests exercise both knowledge and execution; rank is context, not a verdict.

Corrective source notes

• Dunlosky and colleagues: Improving Students’ Learning With Effective Learning Techniques — publisher-hosted 2013 review summary, saved 2026-10-07 and re-read 2026-10-09. Supports the limited rationale for practice testing and distributed practice; not exact intervals, decay rates, coding-specific causal effects or hiring scores.

Algorithmic arguments and arithmetic above are derived for the stated contracts. Finite executable checks, saved source passages and their limits are recorded in the review artifacts; they do not certify unexecuted service behavior or interview outcomes.