Guide · Career
Most people preparing for technical interviews have a list of problems and no system for retaining them. Three months later the early problems are gone, the count looks impressive, and the interview goes badly for reasons that feel mysterious and are not.
The interview patterns guide covers what to study: the ten recurring problem shapes, the recognition cues, and why tagging failures by pattern beats counting solves. This guide covers how to study, which is a separate problem with separate failure modes. If you have never seen the pattern taxonomy, start there and come back.
The default plan is a list and a streak: solve a problem a day, keep going, feel prepared. It fails for a reason that has nothing to do with effort. Memory for a solved problem decays on a curve, and the curve is steeper than anyone expects. A problem you solved cleanly in March, with no intervening contact, is frequently a blank page in June. Not "a bit rusty." Blank.
So the person who solved 300 problems over four months and never revisited one has not banked 300 problems. They have banked whatever survives from the last few weeks, plus a general sense of familiarity that evaporates the moment a whiteboard is involved. The count is real and the retention is not.
The second failure is subtler and worse, because it feels like studying. Reading a solution and thinking "yes, that makes sense" produces a strong feeling of understanding and almost no retrievable memory. This is the fluency illusion: comprehension while reading is not the same operation as generation from a blank page, and only the second one is what an interview tests. If you did not produce it yourself, you did not learn it, no matter how clearly you followed it.
Both failures have the same fix, which is uncomfortable and cheap: spend a substantial fraction of your study time re-solving things you have already solved, from memory, on a schedule.
Leitner is the simplest workable implementation of spaced repetition. Items live in numbered boxes; each box has a review interval; a clean recall promotes an item one box, a failure sends it back to box one. That is the whole algorithm and it needs no software.
| Box | Review interval | Meaning | On success / on failure |
|---|---|---|---|
| 1 | 1 day | Failed recently, or never solved unaided | → box 2 / stays in box 1 |
| 2 | 3 days | Solved with a hint | → box 3 / back to box 1 |
| 3 | 1 week | Solved unaided but slowly | → box 4 / back to box 1 |
| 4 | 3 weeks | Solved unaided and fluently | → box 5 / back to box 2 |
| 5 | 8 weeks | Retired to maintenance | stays in box 5 / back to box 2 |
Two details do most of the work and both get skipped.
A failure demotes hard, not gently. From boxes 1 through 3, a failure goes all the way back to box one. That is the mechanism that concentrates your time on exactly the material you cannot do, which is the only material worth studying. A system that demotes by one box lets weak items drift forever.
Box one has a size limit. If box one holds forty items, you are not studying, you are drowning, and you will start skipping reviews, which breaks the whole system. Cap it at around ten. When it is full, you do not add new problems that day. New material waits until the backlog clears. This rule feels like it slows you down and it is the single highest-leverage constraint in the system.
This is where most people implement it wrong. The card is not the problem statement, because re-solving a full problem takes 30 minutes and you cannot review 15 of those in a session. The card is the retrievable unit.
Front: the recognition cue "Contiguous subarray, longest satisfying a condition" Back: 1. pattern name sliding window 2. the template, written from memory, not pasted 3. the complexity target O(n) 4. the pitfall that got you "shrink condition ran before the update, off-by-one on the answer" Review = write 2 from a blank page in under 5 minutes, then diff.With cards shaped like that, a review is five minutes and a session can clear ten to fifteen of them. You periodically re-solve a full problem end to end, but that is a different activity with a different budget, not your review mechanism.
"Review" usually means re-reading an old solution, nodding, and closing the tab. That produces the fluency illusion described above and close to zero retention. Here is a protocol that takes ten minutes and actually works.
The diff step is the one to protect when time is short. A template you can nearly write is worth much less than one you can write exactly, and "nearly" is invisible until you compare the two side by side. Most people who feel prepared and then blank in an interview were living in the gap between nearly and exactly.
Unbounded struggle is the most common way study time gets wasted. Ninety minutes on one problem feels like commitment and mostly produces frustration plus one data point. A timebox converts the same ninety minutes into three problems and three diagnoses.
| Phase | Budget | What must exist when the timer ends |
|---|---|---|
| Understand | 0–5 min | The input shape, the output, and two examples worked by hand |
| Approach | 5–15 min | A named pattern and a complexity target, said out loud |
| Implement | 15–35 min | Working code, or a specific known blocker |
| Verify | 35–45 min | Edge cases walked manually, complexity stated |
| Hard stop | 45 min | Escalate to the hint ladder — do not extend the timer |
The approach phase is the one to enforce ruthlessly. Fifteen minutes with no named pattern means the problem is currently above your level, and the useful move is to get a hint and turn it into a study item, not to spend another forty minutes rediscovering the pattern by brute force. An interview gives you about 35 minutes. Practising in unbounded time trains a skill you will not be allowed to use.
When the timer expires, escalate in the smallest possible steps. The goal is to take the least amount of help that unblocks you, because every rung you climb without help is a rung you can climb alone next time.
Ninety minutes, in this order, every time. The order matters more than the durations.
If you only have thirty minutes, do the first block and stop. Twenty minutes of reviews with no new problem beats a new problem with no reviews, every single time, and the fact that it feels like less progress is exactly why people get this backwards.
| Phase | Weeks | Focus | The honest signal you are ready to move on |
|---|---|---|---|
| Foundations | 1–2 | Complexity analysis, the language's data structures cold, two or three patterns | You can state the complexity of any built-in operation you use without checking |
| Pattern acquisition | 3–6 | One new pattern per week; template written from memory; deck fills up | Box one clears most days without a backlog |
| Mixed practice | 7–9 | Random problems across all patterns, no advance warning of the pattern | Unaided first-attempt rate above roughly two thirds on mixed sets |
| Interview simulation | 10–12 | Timed, verbal, with another person, plus behavioural answers | You can talk continuously through a solve without losing the thread |
The transition from phase two to phase three is where most preparation quietly breaks. Studying one pattern per week means every problem that week arrives pre-labelled, and pattern recognition is never tested. Mixed practice removes the label, performance drops sharply, and that drop is the honest measurement. It is supposed to be uncomfortable. It is also the closest thing to the real conditions you will get before the real conditions.
Interviews are verbal, and silence reads as being stuck even when it is not. This is a separate skill from solving and it degrades solving performance the first several times you attempt both at once, which is precisely why it needs its own practice.
Total problems solved is the metric that feels like progress and measures almost nothing. Three alternatives that actually track readiness:
The system is not clever. Review before new material, cap the backlog, write templates from a blank page instead of reading them, timebox everything, escalate in the smallest steps when stuck, and measure per-pattern rather than in total. None of that is a secret and almost nobody does it, because every part of it feels slower than grinding through a fresh problem list.
It is slower per week and much faster per month. That trade is the entire point, and it is the same trade in every skill worth having. Getting to the interview in the first place is a separate pipeline problem, handled in the resume guide and tracked in Apply OS; the international-student timing and sponsorship layer is in the internship guide.
FAQ
Because memory for a solved problem decays steeply without review, so a large solved count mostly measures what you did in the last few weeks. The second reason is the fluency illusion: reading a solution and understanding it feels like learning but produces almost no retrievable memory, since comprehension while reading is a different operation from generating a solution from a blank page.
Items live in numbered boxes with review intervals of roughly 1 day, 3 days, 1 week, 3 weeks, and 8 weeks. A clean recall promotes an item one box and a failure sends it back to box one. For coding, the card is not the whole problem but the recognition cue on the front and the pattern name, template, complexity target, and your specific pitfall on the back.
Read only the cue and name the pattern and complexity from memory, write the template from a blank page with autocomplete off, then diff it against your previous solution and investigate every difference. Then state the loop invariant out loud, name one edge case that would break it, and log where the attempt broke. About ten minutes per problem.
Around 45 minutes total, split as five minutes to understand, ten to name an approach, twenty to implement, and ten to verify. If fifteen minutes pass with no named pattern, the problem is above your current level and the useful move is to take a hint and turn it into a study item rather than rediscovering the pattern by brute force.
Escalate in the smallest steps: re-read the constraints, say the brute force out loud and ask what it repeats, work a five-element case by hand, ask what invariant must hold, then look at the tags only, then read one sentence of the editorial and close it. Never copy code, and always turn the problem into a card afterwards.
Review first, always, taking roughly the first 20 minutes of a 90-minute session, followed by recognition drills and one or two timed solves. If you only have 30 minutes, do the reviews and skip the new problem. Reviews scheduled last do not happen, which is the most common way a spaced repetition system quietly dies.
A workable structure is 10 to 12 weeks: two weeks on complexity and data structures, four on acquiring patterns one per week, three on mixed practice with no advance label, and two to three on timed verbal mocks. The phase-two to phase-three transition is where performance visibly drops, and that drop is the honest measurement of pattern recognition.
Due-card clear rate, which should stay above roughly 80 percent or the schedule is too aggressive; unaided first-attempt rate computed per pattern rather than overall; and median time to a correct named approach, where under five minutes is a strong signal. That last number predicts interview performance better than any total does.