Search Tech Journey

Find topics, journeys and posts

back to blog
algorithmsadvanced 75m read

L59 · Blind 75 Sweep — Gap Audit

Attempt-classify all 75 problems in one structured sweep, mark each cold, warm, hint or failed, and produce the personalised weak list that drives the rest of the track.

🧩DSAPhase 4 · Interview simulation· Session 059 of 130 75 min

🎯 Sweep all 75 problems at 60 seconds each, classifying rather than solving, and produce a ranked weak list that makes the next five sessions targeted instead of generic.

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

Watch first

Today's pre-reads are deliberately pattern-taxonomy material rather than single-problem walkthroughs. The sweep is a classification exercise, so what you need refreshed is the map, not any individual route.

Watch these the night before, at 1.5×, and — importantly — do not take notes on solutions. Take notes only on cues: the phrase in a problem statement that should trigger each pattern.

Why this session exists

You cannot repair what you have not measured, and up to now your sense of which patterns are weak has been a feeling rather than a record. Feelings about this are systematically wrong in one direction: the patterns that feel shaky are usually the ones you recently struggled with and therefore recently reinforced, while the genuinely weak ones are the ones you have quietly avoided and therefore never generated a feeling about.

This session replaces the feeling with a table.

The critical design choice is that you are not solving today. You are spending sixty seconds per problem answering one question: can I state the approach? Not implement it — state it. Pattern name, one-sentence approach, complexity. If those three arrive in sixty seconds, the problem is retrievable and gets marked accordingly. If they do not, it is a gap, and you move on immediately without looking at the solution.

Seventy-five problems at a minute each is seventy-five minutes, which is the session. The audit matters more than the solving, because it is what converts the next five sessions from "grind more problems" into "repair these four specific patterns". Targeted repair beats uniform grinding by a wide margin, and the audit is what makes targeting possible.

Blank-file warm-up

None today — but there is a setup step that takes three minutes and determines whether the session produces anything usable.

Create the audit table before you start. A spreadsheet, a markdown table, anything sortable. Columns:

# · problem · pattern I named · pattern it actually is · status · note

Seventy-five rows. Pre-fill the problem names from whichever Blind 75 list you use, so that during the sweep you are only filling in judgements and never navigating.

If you skip this and try to keep it in your head or in loose notes, you will finish the sweep with an impression instead of a dataset, and the entire point of the session is lost.

Pattern anatomy

The shape being trained is a classification sweep — high volume, shallow depth, strict time box, structured output.

The invariant: exactly sixty seconds per problem, and every problem gets a status. No exceptions for interesting problems. The moment you allow yourself to actually solve one, the sweep collapses — you spend twenty minutes on problem eleven and never reach the graph section, which is probably where your real gaps are.

# THE SWEEP PROTOCOL — 60 seconds per problem, no exceptions.
#
# For each problem:
#   0-15s   Read the title and statement. Do not read examples unless needed.
#   15-45s  Answer three questions, out loud:
#             1. What pattern is this?
#             2. What is the approach, in one sentence?
#             3. What is the time and space complexity?
#   45-60s  Assign a status and write ONE note. Move on.
#
# STATUS LADDER (this is the whole output of the session):
#   cold    -> all three answers arrived immediately and confidently.  Review in 60 days.
#   warm    -> answers arrived, but slowly or with visible hesitation.  Review in 21 days.
#   hint    -> you needed to look at the tags or examples to get started. Review in 7 days.
#   failed  -> no approach arrived in 60 seconds.                       Review in 2 days,
#              then 7 days.
#
# HARD RULES
#   - Do NOT open the editorial. Not once. Looking at a solution converts a data point
#     into a feeling of understanding and destroys the measurement.
#   - Do NOT write code. Stating the approach is the entire task.
#   - Do NOT skip problems that look easy. The false-confidence entries are the most
#     valuable rows in the table.
#   - If the 60 seconds expires mid-thought, that is a `warm` at best. Time is the metric.

Set a repeating sixty-second timer with an audible chime. Manual timing does not survive contact with an interesting problem.

The cue

You should run an audit sweep rather than a practice session whenever:

  1. You have finished a broad phase of study and do not know what to do next. That uncertainty is itself the signal — it means you lack a weak list.
  2. Your practice choices have started to feel arbitrary. Picking problems by whim reliably reproduces your existing distribution of strengths, because you gravitate toward what already works.
  3. A mock went badly and you cannot name why. L57 gave you four data points; seventy-five is enough to see the shape.
  4. You are within a few weeks of real interviews. Time is now scarce enough that targeting matters more than volume.
  5. It has been more than a month since the last audit. Retrieval decays, and it decays unevenly — the shape of your weak list changes even when your solve count only goes up.

Guided solve

There is no single problem today. The guided part is running the sweep and, more importantly, reading the output correctly.

The sweep (75 minutes if strict, and it will not be — budget the overflow into tomorrow rather than letting it eat the time box).

Work the list in its published order rather than by topic. Grouping by topic warms you up within each group and inflates the later entries in every section — you want each problem to arrive cold.

Reading the table. When the sweep is done, three passes over the data, each answering a different question.

Pass one — count by pattern, not by problem. Aggregate statuses per pattern. A pattern with four failed entries out of five is a genuine hole. A pattern with one failed out of eight is a bad day on one problem. The unit of repair is the pattern, never the individual problem, because fixing one problem transfers to nothing.

Pass two — find the misclassifications. Every row where "pattern I named" differs from "pattern it actually is" is a classifier error, and these are more dangerous than the failed rows. A failed means you knew you were stuck. A misclassification means you were confidently walking down the wrong road, and in a real interview you would have spent fifteen minutes there before noticing. Weight these double.

Pass three — find the false confidence. Rows marked cold where the note reveals you stated an approach that was actually wrong or incomplete. These only surface if you were honest in the note field. They are rare and they are the highest-value rows in the table.

The output. One ranked list, at most five entries, of patterns to repair. Ranking is by failed count plus double the misclassification count, and ties broken by how commonly the pattern appears in interviews.

That list is the input to L60. Write it somewhere durable — it should still be findable at L65 when you re-audit and compare.

Solo timed

The sweep is the solo block. Seventy-five problems, sixty seconds each, audible timer.

Hints for the sections where sweeps typically go wrong:

  • Arrays and hashing (first ~10) — you will feel fast and confident here. Watch for cold entries where your one-sentence approach was actually the brute force. Note the complexity honestly.
  • Binary search and two pointers — the classic false-confidence zone. "Two pointers" is not an approach; "two pointers from opposite ends, moving the smaller one inward, because the array is sorted" is. If you cannot say the second version, it is warm.
  • Trees and graphs — the largest section and usually where the real gaps live. Do not let sweep fatigue turn these into careless warm marks. If you are flagging, take a two-minute break before this section rather than degrading the data.
  • Dynamic programming — expect the most failed marks here and do not let that discourage the sweep. DP failing at a rate of fifty percent is normal at this stage and is exactly the finding L60 needs.
  • The last ten — fatigue is real. If your attention has gone, stop and finish tomorrow. Half a sweep of honest data beats a full sweep of guesses.

Timing rubric

75 problems, 75 minutes, plus setup and analysis. The discipline here is unusually mechanical, which is the point — there are no judgement calls to make once the clock starts.

  • −3 min · Setup. Audit table pre-filled with 75 problem names. Timer app that beeps every 60 seconds on a loop, not a stopwatch you have to restart.
  • 0–75 min · The sweep. 60 seconds per problem, no exceptions, no solving, no looking up solutions.
  • 75–95 min · Analysis. Timer off. Group by pattern, count gaps, rank.

Within each 60-second slot:

WindowWhat you doFailure signal
0–15sRead title and statementReading examples → you are drifting toward solving
15–45sName pattern, approach in one sentence, complexityNothing by 45s → it is a gap, mark and move
45–60sWrite the row: status plus a five-word noteWriting an essay → you will fall behind and start skipping rows

Pacing checkpoints. You should be at problem 25 by minute 25 and problem 50 by minute 50. If you are more than three problems behind at either checkpoint, you are solving rather than classifying — stop, reset, and enforce the beep.

A sweep that covers 75 problems shallowly is worth far more than one that covers 30 thoroughly, because the gaps cluster in the sections you never reached.

Self-scoring checklist

This session grades the audit, not your recall. A sweep that honestly records many gaps is a successful session. Two points each.

  1. All 75 rows filled, none blank? (2 = complete; 1 = up to five blanks; 0 = you ran out of time.)
  2. 60-second box respected throughout? (2 = no overruns; 1 = a handful; 0 = you solved at least one.)
  3. Zero solutions consulted during the sweep? (2 = none; 0 = any. One peek recalibrates you for the rest of the sweep.)
  4. Both "pattern I named" and "pattern it actually is" recorded? (2 = both columns; 1 = one; 0 = neither — and without both you cannot distinguish misclassification from non-retrieval.)
  5. Ranked weak list produced, with the top three patterns named? (2 = ranked and written down; 0 = "I think DP was bad".)

8–10 → you have a dataset; the next five sessions are now targeted. 5–7 → usable but re-sweep the sections you rushed. 0–4 → the output is an impression, not data; re-run within a week.

A deliberate note: your gap count is not scored at all. Someone who records 30 gaps honestly is in a far better position than someone who records 6 by being generous with themselves, because only the first has a repair plan.

Performance criteria

What the numbers should look like at this point in the track — calibration, not a pass mark.

Retrievability rate. Roughly 60–75% of problems should reach a stated pattern, approach, and complexity within 45 seconds. Below 50% means the audit is premature and you need another pass through the pattern phase. Above 90% almost always means you were scoring generously — re-check a random ten by actually writing the approach out.

Classification accuracy. Of the problems where you named a pattern, at least 85% should be the right one. A high named rate with low accuracy is the worst combination and the most dangerous, because confident misclassification in an interview costs more time than blanking does.

Gap clustering. Your gaps should cluster into three or four patterns, not scatter evenly. Even scatter means the weakness is retrieval speed generally, not specific patterns, and the repair is different: drill templates for speed rather than studying new material.

Note quality. Every gap row needs a note that names what was missing — "couldn't recall monotonic-stack skeleton" is actionable; "hard" is not. If more than a fifth of your notes are single vague words, the audit will not survive contact with next week's planning.

Time honesty. Compare a few of your 60-second judgements against reality by actually solving three of the problems you marked retrievable. If any of the three takes over fifteen minutes, your retrievability bar is set too low and every number above needs adjusting downward.

Recovery scripts

The sweep has its own failure modes, and the recoveries are mostly about not abandoning the protocol mid-session.

You are 15 problems in and desperate to actually solve one:

"That's a gap. Marked. Next."

Say it out loud and move. The urge to solve is strongest on problems you almost remember, and those are precisely the ones the audit most needs recorded as gaps rather than rescued in the moment.

You fell 10 problems behind:

Do not try to catch up by going faster on the remainder — that produces junk rows. Instead, drop to 40 seconds and accept slightly coarser judgements for the rest. Complete coverage at lower resolution beats partial coverage at high resolution, because unreached sections are invisible gaps.

Your gap count is demoralising you mid-sweep:

"The count is the deliverable, not the verdict. A high count means the audit is working."

This is worth saying aloud around problem 40, which is where people typically quit. The sweep is designed to find gaps; finding them is success.

You genuinely cannot tell whether you retrieved it or recognised it:

Default to marking it a gap. Recognition feels identical to retrieval from the inside and is worth nothing in an interview. When uncertain, the conservative mark produces a better repair plan.

Afterwards, when the weak list is long:

Rank, then take the top three only. Attempting to repair everything is the failure mode this session's Misconception addresses — a ranked list you act on beats a complete list you do not.

Common failure modes

Solving instead of classifying. Covered above and worth the repetition, because it is what actually happens to most people around problem twelve.

Marking generously. warm when the honest answer is hint; cold when the approach took forty seconds and came with a wince. Generous marking produces a clean-looking table and a useless weak list, and the only person it deceives is you. When genuinely unsure between two statuses, take the worse one.

Auditing by topic order. Working through all the sliding-window problems consecutively means the third one benefits from the first two. Sweep in list order so each classification is independent.

Recording only the status. The note field is where the diagnostic information lives. "Failed" tells you the problem was hard. "Failed — knew it was DP, could not identify the state" tells you exactly what to drill.

Ignoring misclassifications because you eventually got there. A row where you named "greedy" and it was actually DP is a classifier error even if you corrected yourself within the minute. Log both columns.

Treating the weak list as a problem list. Producing a list of thirty specific problems to re-solve misses the point entirely. The output is patterns — at most five — because patterns transfer and individual problems do not.

Common misconception
✗ What most people think
I should re-solve every problem I've forgotten. Anything less leaves gaps.
Why the myth is so sticky
This confuses coverage with capability. Seventy-five re-solves is roughly twenty hours and it distributes effort uniformly across patterns you already own and patterns you do not, which means the majority of that time reinforces things that were already retrievable. A one-hour audit followed by targeted work on the three or four genuinely weak patterns produces a better outcome in a quarter of the time — because interview performance is limited by your weakest common pattern, not by your average across all of them. Uniform effort optimises the average and leaves the binding constraint untouched.
From first principles
  1. 1
    Interview outcomes are determined by performance on whichever pattern happens to appear, not by average performance across all patterns.
  2. 2
    Because a single problem decides the outcome, your effective level is closer to your weakest common pattern than to your mean.
  3. 3
    Because the weakest pattern dominates, effort has the highest marginal return when directed at the bottom of the distribution rather than spread evenly.
  4. 4
    Because you cannot direct effort at the bottom without knowing where the bottom is, and because subjective impressions are biased toward recently-practised material, the distribution must be measured rather than felt.
  5. 5
    Because measurement only needs retrievability rather than a full solve, sixty seconds per problem is sufficient — and cheap enough to cover the whole list in one session.
  6. 6
    Therefore a shallow classification sweep beats a deep re-solve pass as the next action — and the testable prediction is that at least one pattern you would not have named as weak appears in your bottom three.
Mental model
A doctor ordering a full blood panel rather than treating whichever symptom you happened to mention. The panel is cheap, covers everything at once, and its output is a short list of the values actually out of range — not a treatment for every organ.
🔔 Fires when you see
Fires whenever you are about to choose your next practice problem by instinct rather than from a list.
The tradeoff
Shallow classification sweep — 60 seconds, 75 problems, one session
+ you gain Complete coverage in an hour; measures retrieval speed, which is what interviews test; produces a ranked, actionable weak list
− you pay Detects retrieval failure but not implementation failure — you may state an approach correctly and still be unable to code it
Deep re-solve pass — full implementation of each problem
+ you gain Catches implementation bugs and edge-case weakness that classification misses; genuinely reinforces the templates
− you pay Roughly twenty hours; spends most of that time on patterns you already own; you will abandon it partway and end up with biased partial coverage
What a senior engineer actually does
Sweep first, always. Then deep-solve only the patterns that the sweep put in the bottom three — which is what L60 is for. Escalate to a broader re-solve pass only if your sweep comes back with fewer than five non-cold entries, which would mean retrieval is not your constraint.

Complexity

Sweep cost: 75 problems × 60 seconds = 75 minutes, plus 3 minutes of setup. The whole session.

Analysis cost: roughly 15 minutes for the three passes, best done immediately after while the notes still mean something. If you must defer it, defer by hours, not days.

Comparison against the alternative: a full re-solve of 75 problems at 15 minutes each is about 19 hours. The sweep gives you the targeting information for 1.5% of that cost. It does not replace solving — it decides which solving is worth doing.

Repeat interval: re-audit every four to six weeks, or immediately after any mock that goes badly for reasons you cannot name. L65 runs the next one and compares against today's table, which is why the table needs to survive.

Quick recall · click to reveal
★ = stretch question
You can now…
  • Run a strict 60-second classification sweep without drifting into solving.
  • Distinguish recognising a problem from retrieving its approach, and mark honestly.
  • Record both the pattern you named and the pattern it actually was.
  • Hit pacing checkpoints at problems 25 and 50, and recover by lowering resolution rather than skipping rows.
  • Produce a ranked weak list of three or four patterns from 75 data points.
  • Tell scattered gaps (retrieval speed) apart from clustered gaps (specific patterns).
  • Write gap notes that name what was missing, not how the problem felt.
  • Treat a high gap count as a working audit rather than a verdict.
  • Convert the audit into a targeted plan for the remaining sessions.

Spaced queue

Today's session is a queue rebuild. Every one of the 75 rows gets scheduled from its status:

  • cold → next review in 60 days
  • warm → 21 days
  • hint → 7 days
  • failed → 2 days, then 7 days

That produces a review calendar that self-balances: the things you cannot do come back almost immediately, the things you own get out of the way for two months. Put the dates in whatever you actually check daily.

Keep the raw table. L65 re-runs this sweep and the comparison — how many rows moved up a level — is the only real measure of whether the last six sessions worked.

Key points