The two-week interview sprint, day by day

Two weeks is a real interval, not a panic interval. In fourteen days you can move a well-prepared-but-uneven candidate to a solid one, and a shaky candidate to a passable one — the difference between those outcomes is fewer heroic streaks and more architecture. The sprint exists to decide, before you start, exactly what "ready" means, and then to spend every day on the highest-leverage activity available that day.

A sprint is a plan with a clock. Without the clock, it is just a mood.

Days 1–2: diagnose before you train

Take the first two days to build the repetition inventory. Sit a timed thirty-minute, five-problem mock and record five numbers: problems solved, problems solved without hints, pattern named correctly before code, time over budget, and panic signals (long silences, restarting, jumping to code without a plan). Then write down in one column the patterns you can execute cold, and in the other the ones you can only attempt. That second column is your entire two-week target list — the sprint is a treatment for the diagnosis, not a course in computer science.

A paper log beats the memory of your own past performance, because memory flatters. Sketch the shape you log with every attempt:

# daily attempt log, days 3 - 10
problem  pattern        no-hint  over-time  verdict
lc3      sliding_window yes      0m         COLD
lc11     two_pointers   yes      2m         WARM
lc743    dijkstra       no       9m         PANIC

Be honest about the no-hint number. It is the single most predictive figure you own, because it measures what actually happens in an interview, while "attempts completed" measures what happens in a bedroom with the solution tab open.

Days 3–7: pattern blocks

Now the grinder days, but shaped: cluster, then scramble. Each day owns one pattern from your "cannot execute cold" list. Morning: reread the pattern's telltale phrases and skeleton. Midday: three same-pattern problems, timed at twenty-five minutes each. Evening: nothing. Yes, nothing — retrieval practice beats cramming, and your brain consolidates overnight.

Rotate blocks like this, then bend the table to your diagnosis:

Day	Pattern block	Drill
3	Sliding Window	3 problems, 25 min each
4	Two Pointers	3 problems + 1 short mock
5	Tree DFS / Tree BFS	3 problems, rebuild skeletons
6	Top K / Heaps	3 problems, 25 min each
7	Dynamic Programming start	3 classic recurrences

If your day-1 column says "all pointers fine, trees scary", spend a second day on trees. The skeleton bends; the diagnosing habit does not.

Days 8–10: scramble and mock

Pattern blocks build fluency inside a pattern, but interviews do not announce their patterns. From day 8, every set is a mixed set: five problems across different pattern families in forty-five minutes, and the first ninety seconds of each problem must be spent naming the pattern out loud before touching the keyboard. Your identification speed — pattern named correctly before code — is now the number you are training, not raw solves.

Sit two full mock interviews on days 9 and 10, with another human or a recording, then grade them against the same five numbers from day 1. What you want is not an improved score but a narrowed diagnosis: the problems you now execute cold, the ones still stalling you, and the behavioural stories that fell apart under time pressure.

Scoring a mock so it teaches you something

A mock interview is only as good as the grade it produces, and the grade has to be structured. Score every mock on four axes out of five: pattern identification speed, correctness of the first coherent approach, conversational flow (did you think out loud or go quiet?), and the terminating check (did you test your own code out loud before declaring done?). The axis that drops most often — usually conversational flow — is your priority for the next mock, because the other three improve with volume while flow only improves with deliberate attention. Date-stamp the score and re-grade a week-old mock before each new block, then let the drift decide where the next three hours go.

Days 11–12: the role-specific block

Two days out, compress the generalist fluff and go role-specific. If the target company runs system design rounds, run two full system design mocks with a fixed skeleton — requirements, estimation, API, data model, high-level design, deep dive, wrap-up. If the target role is data-heavy or front-end heavy, swap the block accordingly. Redeem any spare hour on your most recent miss: the problem from day 1 that still does not feel cold.

Days 13–14: taper and logistics

The taper is where sprints are won. Cut volume by half, keep only light re-drills of your cold patterns, and stop learning new material forty-eight hours out. Do the logistics then, when it is cheap: route and commute times, water bottle, mock-interview environment, the shared code editor URL, backup power. And re-read your eight signal-rich behavioural stories and their result numbers on the last evening — interview-day answers are worse when you pantomime confidence instead of recalling evidence.

Three hard rules for all fourteen days

• Never practise sleep-deprived. Retrieval practice runs on consolidated memory, and consolidation is a sleep function.
• Track the miss, not the solve. Your log's most useful entry is the pattern you misidentified and what the telltale phrase should have been.
• No new material after day 12. Novelty breaks the taper; every minute past that point buys panic, not competence.

What two weeks can — and cannot — do

Two weeks will not turn a first-year into a staff engineer, and pretending otherwise is how sprints become destructive. What it can do is raise your floor: choke on a medium live on the whiteboard less, name patterns faster, run system design without freezing, and answer behavioural questions with evidence instead of vibes. That floor is exactly what separates "did okay" from "did not embarrass myself" on an unlucky day.

Use the question bank to build the day-1 diagnosis and the mixed sets, follow the study tracks if your diagnosis needs a longer runway, and set the drills at exactly the right difficulty with the practice engine, which scrambles pattern sets so your identification speed gets trained, not just your fluency.