L64 · Contest Simulation

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

Why this session exists

Nothing you can arrange for yourself replicates interview adrenaline like a live contest clock. Self-imposed timers are negotiable — you can pause, you can peek, you can decide the mock does not count. A contest with a real deadline, a public ranking and no undo is not negotiable, and that non-negotiability is the point.

The physiological effect is real and it is what you are here to train against. Under adrenaline, working memory narrows, careless mistakes multiply, and the specific failure most people discover is that they cannot read carefully any more. Misreading a constraint under pressure is not a knowledge failure. It is a state failure, and the only way to get better at it is to practise in that state.

The second thing a contest teaches, which mocks teach poorly, is problem selection under time pressure. Four problems, ninety minutes, increasing difficulty. Correctly deciding to abandon problem three and take a serious run at problem four — or the opposite — is a skill, and it maps directly onto the interview decision of when to abandon an approach.

If you can join a live weekly contest, do that. If the timing does not work, LeetCode's virtual contest mode runs a past contest with the same clock and no leaderboard pressure, which is most of the value. Take the live one when you can; the leaderboard adds something that the virtual mode does not.

Blank-file warm-up

None during the contest itself, obviously.

Do a fifteen-minute warm-up before the contest starts — two Easy problems you have solved before, purely to get your hands and your editor moving. This is not cheating and it is not preparation in the study sense; it is the same reason athletes warm up. The first problem of a cold contest is disproportionately likely to contain a careless bug, and a warm-up moves that bug into a throwaway problem instead of a scored one.

Have your environment ready before the clock starts. Editor open, language selected, your usual imports pasted in. Fumbling with setup during the first two minutes of a ninety-minute contest is a self-inflicted wound.

Pattern anatomy

The pattern is contest triage — allocating fixed time across four problems of unknown individual difficulty.

The invariant: at every moment you are working on the problem with the best remaining ratio of expected points to expected minutes. That means the decision to switch problems is a live one throughout, not something you decide once at the start.

# CONTEST PROTOCOL — 90 minutes, 4 problems, increasing difficulty.
#
# MINUTE 0-3 — READ ALL FOUR
#   Do not start solving. Read every problem and assign each a rough difficulty
#   and a pattern guess. This is the single highest-return three minutes available:
#   contests are not always monotonically ordered, and Q3 is sometimes easier than Q2
#   for someone with your particular pattern coverage.
#
# MINUTE 3-15 — SOLVE Q1
#   It is meant to be easy. Read the constraints properly anyway. The most common
#   contest failure is a careless bug in Q1 costing a 5-minute penalty and, worse,
#   the composure needed for Q2.
#
# MINUTE 15-40 — SOLVE Q2
#   Usually a standard Medium. This is where most of your rank is decided, because
#   almost everyone solves Q1 and few solve Q4.
#
# MINUTE 40-75 — ATTEMPT Q3
#   Harder Medium or easy Hard. Set an internal checkpoint at minute 60:
#   if you have no approach by then, switch to Q4 or go back and harden Q1/Q2.
#
# MINUTE 75-90 — TRIAGE
#   Whichever of Q3/Q4 looked more tractable during the minute-0 read.
#   Partial credit does not exist, so an unsubmitted near-solution scores zero —
#   prefer finishing something over improving something.
#
# PENALTY AWARENESS
#   Wrong submissions cost time penalties. Test locally against the given examples
#   AND one edge case before submitting. The reflex to submit-and-see is expensive here
#   in a way it is not during practice, which is exactly why contests train it out of you.

The minute-0 read is the part most people skip and it is the highest-leverage rule in the protocol.

The cue

Contest practice is the right training stimulus when:

1. Your solve quality is fine but your speed under pressure is not. If mocks show correct approaches arriving too slowly, contests train the rate directly.
2. You have noticed yourself making careless errors specifically when timed. Misread constraints, off-by-one under pressure, submitting without testing. These are state failures and need training in the state.
3. You need practice abandoning things. Contests force the decision every time; interviews require it occasionally and punish getting it wrong.
4. Self-imposed timers have stopped working on you. If you have started pausing your own mocks or letting them run over, you need an external clock.
5. You are within a few weeks of real interviews and want the physiological rehearsal, not just the technical one.

The case where contests are the wrong tool: if your L59 audit shows many weak patterns, a contest mostly produces frustration and a low rank. Contests train performance, not acquisition. Fix acquisition first.

Guided solve

No worked problem, since the contest is live. Here is how to run it and, more importantly, how to read the result.

Before (20 minutes). Warm up on two known Easies. Set up the environment. Read the protocol above once. Decide in advance what your minute-60 checkpoint action will be, because deciding it under pressure at minute 60 is exactly when your judgement is worst.

During (90 minutes). Run the protocol. One additional rule specific to contests: when you submit and it fails, read the failing test case before changing anything. The reflex under time pressure is to change something plausible and resubmit, which typically costs two more penalties. Ten seconds of reading beats two minutes of guessing.

After (30 minutes, and this is the session). The contest itself is the stimulus; the review is where it becomes skill.

Read the editorial for every problem, including the ones you solved. Contests are one of the few places where reading solutions immediately is correct, because the problems are new to everyone and the editorial often shows a much cleaner approach than the one you forced through under time pressure.

Then answer four questions in writing:

• Which problem cost me the most time relative to its difficulty, and why? Usually one problem absorbs a disproportionate share, and the reason is almost always a misread constraint or an approach committed to too early.
• How many wrong submissions, and what caused each? Categorise: careless bug, wrong approach, missed edge case. The distribution tells you what pressure does to you specifically.
• Did I follow the protocol? Specifically: did I read all four at minute zero, and did I honour the minute-60 checkpoint? Almost nobody does both on their first contest.
• What did adrenaline break that is normally fine? This is the important one. Reading comprehension, arithmetic, willingness to abandon an approach, the L58 narration habit — whatever degraded is a specific thing to watch for in a real interview, because it will degrade there too.

Solo timed

The contest is the timed block. Ninety minutes, four problems, no external help of any kind.

Hints for the pressure points contests reliably expose:

• Q1 — read the constraints even though it looks trivial. The careless Q1 bug is the most common contest mistake and it costs both a penalty and your composure.
• Q2 — this is where the outcome is decided. If a pattern arrives in the first two minutes, commit hard and implement fast. If it does not, re-read the constraints; they usually contain the tell.
• Q3 — set the abandon checkpoint before you start, not while you are stuck in it.
• Q4 — often more approachable than its position suggests if it happens to be a pattern you own. This is why the minute-0 read matters.

Common failure modes

Starting Q1 immediately without reading all four. Contests are not reliably ordered by your difficulty, only by the setters' estimate. Three minutes of reading can redirect forty minutes of effort.

Submit-and-see debugging. Practice rewards it; contests punish it with time penalties; interviews do not offer it at all. This is one of the specific habits a contest exists to train out of you.

Ignoring your own checkpoint. Deciding at minute 40 that you will abandon Q3 at minute 60, and then at minute 60 deciding you are nearly there. You are not. You said 60 for a reason and the you-at-40 had better judgement than the you-at-60-and-stuck.

Polishing instead of submitting. There is no partial credit. An elegant unsubmitted solution scores identically to a blank editor. Submit the ugly working version, then improve it if time remains.

Treating a bad rank as a verdict. The rank compares you against a population with different training. Your own trend across contests is the signal.

Skipping the editorial review. The contest is ninety minutes of stimulus; the thirty-minute review is where it converts. Skipping it means you paid the full cost and collected part of the benefit.

Complexity

Contest structure: 90 minutes, four problems, increasing difficulty. Points typically increase with difficulty and wrong submissions add time penalties, so the ranking rewards both correctness and speed.

Suggested allocation: 3 min reading all four, 12 min Q1, 25 min Q2, 35 min Q3, 15 min triage. Adjust after the minute-0 read if the ordering does not match your own difficulty.

Session total: 20 min warm-up and setup, 90 min contest, 30 min review. That exceeds seventy-five minutes, which is expected — this session runs long by design and the review is the part you must not compress.

Realistic expectations: two solved is a solid outcome for someone at this stage. Three is strong. Four puts you well into competitive-programming territory and is not the goal of this track. Judge the session on the review, not the count.

Spaced queue

Every contest problem enters the queue, including the ones you solved:

• cold — solved quickly and clean, no wrong submissions → 60 days
• warm — solved with penalties or slowly → 21 days
• hint — solved only after reading the editorial → 7 days
• failed — not solved → 2 days, then 7 days

Contest problems are unusually valuable queue entries because they are genuinely unseen and the recency of the pressure makes the memory of how you failed unusually detailed. Add a note to each row describing what pressure specifically broke.

Re-solve Q3 and Q4 from scratch tomorrow, after having read the editorials today. That is the standard two-attempt rule, and it is where contest problems actually consolidate.