L64 · Contest Simulation

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

Watch first

Watch the night before, not in the ten minutes before the clock starts — you want your pre-contest window spent on the warm-up, not on video.

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.

Timing rubric

Set phone alarms at the checkpoint minutes before the contest starts. Under adrenaline you will not track elapsed time accurately, and the whole protocol depends on honouring boundaries you can no longer feel.

The minute-60 row is the one that decides most contests. Everything else is execution; that row is judgement, and it is the row you will want to break.

Self-scoring — process over rank

Score the process, because the rank measures a population you are not competing with. Six items, 0–2 each, out of 12. Log the total after every contest and watch the trend.

• Read-all-four. 2 = all four read and guessed before touching code. 1 = skimmed two. 0 = started Q1 immediately.
• Q1 clean. 2 = accepted first submission. 1 = one penalty. 0 = two or more.
• Test-before-submit. 2 = ran given examples plus one self-invented edge case every time. 0 = submitted to see.
• Checkpoint honoured. 2 = abandoned at the minute you pre-committed to. 0 = talked yourself out of it.
• Nothing left unsubmitted. 2 = every piece of working code was submitted before the buzzer. 0 = you were polishing at minute 89.
• Review completed. 2 = all four editorials read and the four written questions answered. 0 = closed the tab.

10–12 — your process is sound; remaining gains are pure pattern coverage. 6–9 — typical for a second or third contest; pick the single lowest item and make it the only thing you focus on next contest. Below 6 — you ran the contest, you did not run the protocol. Do the next one with the protocol printed next to you.

Note that solve count is not on this list. Solve count depends heavily on which patterns happened to appear. Process does not, which is why it is the trainable thing.

Building your own contest set (virtual mode)

If live timing does not work, virtual mode on a past contest gives you the clock and the structure. To make it bite, remove your escape routes before starting: close every tab except the contest, put the phone in another room, and tell someone the ninety-minute window so stopping has a social cost.

For pace calibration outside contest mode, these are representative of the four slots and can be run as a synthetic ninety-minute set. Company tags reflect these problems' long-standing reputation as commonly-asked questions, not any claim about a specific loop.

• Q1 slot · Easy, 10 min — Two Sum (1), Valid Parentheses (20), Best Time to Buy and Sell Stock (121). Amazon and Microsoft warm-ups.
• Q2 slot · standard Medium, 20 min — Product of Array Except Self (238), Group Anagrams (49), Number of Islands (200), Merge Intervals (56). Meta and Amazon staples — and the slot where your rank is actually decided.
• 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 one from each slot without reading statements, and run the full protocol including the minute-0 read. It is a weaker stimulus than a live contest and a much better one than untimed practice.

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.

Recovery scripts

Contests have no interviewer, so these are scripts you say to yourself. Say them out loud anyway — externalising is what breaks the loop.

Q1 fails and you feel the panic spike. Name it and downgrade it: "One penalty. That is a few minutes of rank, not the contest." Then read the failing case before touching anything. The panic spike after an early failure is what causes the second and third penalties, and those are the expensive ones.

Twenty minutes into Q2 with nothing. Stop solving and re-read the constraints in isolation, out loud, ignoring the story. Constraints carry the tell: n ≤ 20 means exponential is intended, values ≤ 100 means counting, sorted means two pointers or binary search, k ≤ 10 means the k is a dimension. When the story has defeated you, the constraints usually have not.

Stuck on Q3 at your checkpoint and convinced you are close. Use the pre-committed rule as an external authority: "I said 60. Past-me was not stuck and had better judgement. Leaving it." Then physically switch files so the code is off your screen. Feeling close while stuck is the standard sunk-cost signal and it is almost never accurate.

Your solution TLEs and you do not know why. Do not micro-optimise. Recount the asymptotics against the stated bound: if n is 10⁵ and you wrote something quadratic, no constant-factor fix will save it and you need a different approach or nothing. Deciding "this is unfixable in the time available" quickly is worth more than fifteen minutes of shaving constants.

Ten minutes left and two half-solutions. Pick the one closer to compiling and finish it. Never split the last ten minutes across two problems — with no partial credit, two 80% solutions score exactly the same as zero.

You finish and feel awful about the result. Write the four review questions before you look at the leaderboard. Reading your rank first colours the entire review, and the review is the part with the value.

Checkpoint

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.