How to actually get fluent

The 20-minute rule

Spend at most 20 minutes stuck on a new problem before peeking at hints. Past 20 you're rehearsing confusion: every minute you flail without traction is a minute training your brain to flail. Pattern recognition is built only by the right kind of struggle, not by quantity of struggle.

The 20-minute rule produces three things at once: it forces you to commit to a guess, it limits sunk-cost paralysis, and — because the second attempt is timed afresh — it lets the new pattern hint actually do its job. Candidates who skip this rule grind hundreds of problems with low retention. Candidates who keep it grind fewer problems and retain more.

If you're earlier in the journey than interview prep, the apprenticeship's rules of practice covers the same ground from the other end — the time box, the failure-triggered revisit schedule, and a definition of done — written for someone on problem one.

Spaced repetition for problems

Problems decay from your memory like vocabulary words. Without scheduled review, you'll re-solve the same medium twice from scratch and not realise you've seen it before. The fix is the same as Anki: re-touch each problem at growing intervals.

Use any tracker — Anki cards (one card per problem with the LC link on the front), a spreadsheet, or a Notion database. The tooling is irrelevant; the schedule is the lever. Wrong on a review? Restart at interval 1. The point isn't to "complete" the schedule; it's to calibrate against forgetting.

"Explain it back" — the verbal layer

After solving (or after reading a solution), narrate the entire problem and approach out loud, as if to an interviewer. Use a phone recorder if alone. The goal isn't pretty English; it's verbal reps. The interview isn't a typing test — it's a thinking-out-loud test, and that skill is disjoint from "I can write the code".

A good narration covers, in order: (1) restate the problem; (2) state edge cases unprompted; (3) brute force as the baseline; (4) the observation that unlocks the pattern; (5) name the pattern with a reason; (6) walk a tiny example; (7) state complexity, both; (8) write the code while talking. If you stumble at any of these, the underlying fluency isn't there yet — re-solve.

Always practise on a timer

A medium you can solve in 60 minutes is a medium you can't solve in the 25-minute interview window. The interview's signal is partly time-pressure tolerance; if you've never trained against a timer, you've never practised the actual skill.

A practical setup: a stopwatch app on the desk, started before reading the problem. Stopped at submit. Logged in your tracker next to "did I get the optimal in time?". Patterns emerge — "I'm slow on hash-map mediums" or "DP on intervals takes me 35 minutes, not 25" — and that's the diagnostic signal. Address those specific gaps; don't grind generic volume.

Mocks — start at week 4

Solo practice is the unit test; a mock interview is the load test. The worst time to discover that you freeze when an interviewer is silent, or that your code-on-a-whiteboard handwriting is unreadable, or that you can't talk and code at the same time, is during the actual interview. Solo practice will never surface these.

A typical cadence: weeks 1–3 solo practice, building pattern fluency. Week 4 onwards, one mock per week. The week before onsites, two mocks per week. Mock interviewers don't have to be fancy — a peer also doing LC is fine. Free options: Pramp (peer-to-peer), interviewing.io (anonymous, FAANG-level interviewers, free tier exists), Hello Interview (structured walk-throughs).

Pattern fluency, not problem count

"How many problems should I do?" is the most common question and the wrong one. Problem count is vanity metric. The metric that actually predicts interview performance is pattern fluency: given a cold medium you've never seen, can you name the right pattern in under two minutes? If yes, the rest is muscle memory. If no, no amount of grinding will help.

A practical fluency target: ten problems per pattern, all graduated (per the spaced repetition graduation metric above). Twenty patterns × ten problems = 200 problems, all reviewed at least three times. That's roughly the right 200 problems — not a random 200 from the LC top 100.

A 12-week prep plan

A concrete schedule. Adjust by experience: experienced candidates collapse weeks 1–2; rusty candidates extend weeks 3–6.

Total: ~165 problems solved + ~70 reviews + 12 mocks. Not a magic number — adjust upward for FAANG-tier prep, downward for less-aggressive loops.

When to peek vs when to push

A common failure mode is treating "stuck" as binary. It isn't. There are three states, and the right response differs.

• Productive struggle. You can articulate what you've tried, why it didn't work, and the shape of where you are. Keep pushing. The 20-minute timer hasn't run out.
• Stuck but moving. You're trying ideas. Some break against the constraints, but the breaking is teaching you. Keep going if under 20 min; peek at the pattern hint past 20.
• Spinning. Re-reading the problem for the fifth time. No new ideas. Time is dilated. Stop immediately. Peek at the pattern, breathe, restart the clock.

Knowing which state you're in is itself a learnable skill. Track it: every problem, log "productive / moving / spinning" in your tracker. Patterns emerge — "DP problems take me 30 min before I'm productive" or "I spin on graph problems" — and that's the actionable feedback.

The day-of-interview protocol

• The 24 hours before. No new problems. Review only patterns you've already graduated. The point is calibration, not learning. Sleep is more valuable than another problem.
• The hour before. Walk through the seven-thing checklist verbally — restate, edge cases, brute force, observation, pattern, complexity, dry-run. Get the script in your mouth.
• The first 30 seconds. Read the problem twice. Don't speak. Most candidates start talking immediately and miss a constraint. Two reads.
• The first 2 minutes. Restate. Ask 1–2 clarifying questions. Bring up 1–2 edge cases unprompted. Do not jump to code.
• The next 5 minutes. Brute force. Articulate it. Then state the observation that unlocks the pattern. Name the pattern with a reason.
• The next 12 minutes. Code. Talk while you code — narrate every choice. Don't fix bugs silently; explain why you're fixing them.
• The last 5 minutes. Trace through an example. State complexity. Mention what you'd test. Mention any caveat you couldn't address (interviewer scores honesty).

Common methodology mistakes

• "I'll review later." Reviews compound; you'll never review later. Schedule them in the calendar like meetings.
• Ignoring slow patterns. If you're 35 minutes on a medium DP problem, that's the diagnostic, not the noise. Spend a week purely on DP.
• Solo for 12 weeks. The single biggest mistake. Mocks reveal a class of failure modes solo can't surface.
• Re-solving from memory. If a review feels easy because you remember the trick, you didn't re-solve. Restart, type it out, complete it.
• Optimising for problem count. "I did 300 problems" is not impressive if half were random and unreviewed. 150 well-reviewed across 20 patterns crushes 300 random.
• No language fluency. Knowing your interview language's standard library — Python's heapq, defaultdict, bisect, Counter; C++'s std::sort, priority_queue; Java's TreeMap — is half the speed.
• Burnout. 12 weeks of grinding without rest produces worse outcomes than 14 weeks with two off. Sustainable cadence wins.
• Skipping the methodology. If you've read this page and aren't going to apply it, you've spent 10 minutes for zero gain. The protocol is the lever.

The four-stage problem-solving framework

The signal of a senior candidate isn't speed — it's the visible structure of how they attack a problem they've never seen. Interviewers watch for a deliberate four-stage rhythm: Understand → Plan → Code → Verify. Each stage produces a small artefact the interviewer can rate. Skip a stage and you're showing the silhouette of a more junior thinker.

How to solve a problem you've never seen — the meta-process

You will be handed an unfamiliar problem in every senior interview. The skill being tested isn't memorisation; it's how you triangulate from "I have not seen this" to "I know what shape this is" in 90 seconds. The triangulation is mechanical and learnable.

1. Read the constraints first. The constraints are the largest hint in the problem. N ≤ 10⁵ ⇒ O(n log n) at worst. N ≤ 10⁹ ⇒ math, binary search on the answer, or closed form. N ≤ 20 ⇒ exponential bitmask DP is fine. N ≤ 500 ⇒ O(N³) lives. The constraint narrows the algorithm class before you've written a line.
2. Match the surface to a pattern. "Sorted input" + "pair sum" ⇒ two pointers. "Substring" + "with constraint" ⇒ sliding window. "Graph with weights" + "shortest path" ⇒ Dijkstra. "Range queries + point updates" ⇒ segment tree / Fenwick. Pattern recognition isn't magic; it's three to five reps of each pattern.
3. Write the brute force out loud. Even if it's O(n!). The brute force gives you (a) a complexity floor you can verify against, (b) a way to spot-check the optimised answer on small inputs, and (c) clarity on what the answer actually is. Skipping brute force is a common failure mode on hard problems.
4. Run a tiny example by hand. 3–5 elements. Verbalise what each step does. The hand-trace is where most "I know the pattern but the code is broken" bugs surface before you write them.
5. Find the bottleneck. Almost always one specific inner loop or one repeated computation. Then ask: can I cache it, precompute it, amortise it, or binary-search around it? The four-question audit of the inner loop unlocks most O(n²) → O(n log n) improvements.
6. Try a 180° flip. If you're stuck thinking left-to-right, try right-to-left. If you're processing online, try offline (sort the queries, batch). If you're growing a set, try shrinking. The reverse-direction reframe is the single most reliable unstick trick in competitive programming.
7. Ask out loud — but specifically. "Should I assume the values fit in int32?" "Are duplicates possible?" "Are the queries online or batched?" These questions usually surface the trick the problem is built around. Vague questions ("any hints?") burn social capital; specific ones earn it.

How to read constraints — the cheat sheet

Most online judges allocate roughly 10⁸ simple operations per second of compute. The constraint on N tells you which complexity classes are viable. This table is the reflex chart — internalise it well enough to map "N ≤ X" to "O(Y) at worst" without thinking.

Reverse-read this table. If you've spotted the pattern but aren't sure of the expected complexity, look up where the constraint sits and confirm your algorithm's runtime lands above (or in) the viable row. Mismatch = your algorithm is wrong even if it produces correct answers on small inputs.

The hard-problem narrative

Hard problems are not solved by being clever upfront; they're solved by structured climbing. The structure has six rungs. Walk them in order even on problems where rungs 1–3 feel beneath you — those rungs are where the trick reveals itself.

1. Write the brute force explicitly. Even O(n⁵). The brute force is the answer-of-record you'll verify against, the source of small examples to trace, and frequently the structure the optimal algorithm refines.
2. Identify the bottleneck. Almost always one specific inner loop or one expensive repeated operation. Name it: "the inner loop recomputes the sum of nums[i..j]" or "the recursion re-derives f(k) for every parent."
3. Try the four amortisation moves. Cache (memo / DP), precompute (prefix sums, sparse table), amortise (two pointers, monotonic stack), or binary-search-around (when the answer is monotone in a parameter). Most O(n²) → O(n log n) wins come from exactly one of these four.
4. Try a different angle. Iterate backwards. Convert online queries to offline. Swap the dimensions in 2D DP. Convert "build up" to "tear down." Frame as graph / matrix exponentiation. Almost every hard problem yields to one particular reframe; trying three or four is faster than staring at the brute force.
5. Ask the interviewer a constrained question. "If I had a way to precompute X in O(N), would that help?" The answer is often "yes — and here's how to get X in O(N)." This is a legitimate move, not begging — senior interviews expect dialogue, not silence.
6. Code what you've got — even if it's partial. A clean O(n²) on a hard problem with the bottleneck identified and the optimisation discussed is better than a half-typed O(n log n) that doesn't compile. Verifiable progress scores; aspirational mess doesn't.

The day-before and post-interview protocol

Two short checklists that prevent the most common day-of and after-the-fact failure modes.

Day before the interview

• Do not grind new problems. Re-solve three problems from your "known cold" list. The point is warmth, not learning.
• Skim templates. BFS, two pointers, binary-search bounds, DP recurrence shapes. Five minutes of refresh, not study.
• Eat. Sleep. Exercise. No caffeine after 2pm. The cognitive cost of a poor night's sleep is larger than any last-minute LC.
• Re-read the company's engineering blog or recent talks. Helps in behavioural and signals "I care."
• Lay out clothes, charger, water, ID. Anything you can do the night before is one fewer cognitive load on the morning.

Within 24 hours after

• Write down every question you got. Title, surface, what you said, what they pushed on. Tracker grows over loops.
• Note what you didn't know. Adds to your study list with provenance: "I bombed segment tree at Acme, March 14."
• Note interviewer behaviour signals. Did they nod? Smile? Stop you? Ask a hard follow-up after you finished? These predict outcomes better than your own internal sense.
• Send a thank-you note within 24h. Two lines, specific to one thing discussed. Doesn't move offers but signals professionalism.

Further reading

• Anders Ericsson — Peak: Secrets from the New Science of Expertise. The deliberate-practice canon. The methodology in this page is mostly a specialisation of Ericsson.
• Cal Newport — Deep Work. The case for long, uninterrupted blocks of practice — and why grinding LC in 10-minute fragments doesn't work.
• SuperMemo — Twenty rules of formulating knowledge. The original spaced-repetition rulebook. Applies directly to flashcarding LC patterns.
• Aline Lerner — interviewing.io blog. Empirical data on what actually predicts interview success. Pattern fluency, communication, calmness — not problem count.
• McDowell — Cracking the Coding Interview, chapters 1–6. The methodology chapters age well even though the problems date.
• Adjacent: the problem-solving hub. The mental models, the patterns playbook, the books list.
• Adjacent: the pattern playbook. The twenty-pattern curriculum this methodology trains against.