Foundations

A four-week prep plan

This is a calendar for someone who can spend about eight to ten hours a week and who wants a balanced pass over the patterns on this site. It is not a prescription from an employer, and it is not a claim that four weeks is what anyone needs. If your invitation arrives in six days, do week one, the common mistakes page, and two timed sessions. If you have three months, repeat the timed sessions and do not invent extra patterns for their own sake.

The format guide comes first, once, because it stops you from studying a rumor. If a recruiter has already told you the sections, bias the calendar toward those sections. A loop that is mostly behavioral should not spend every evening on heaps. A loop that is a pure coding screen should not skip the timers in favor of rereading principles.

Week 1: finish small things on purpose

Read the format guide and the time management page on the first day. Then do the temperature rehearsal in that page under a real timer, even though it is easy. You are installing the ritual: restate, mean example, code, edges.

For the rest of the week, learn three patterns well enough to rewrite them from a blank file. Arrays and hashing on day two. Two pointers on day three. Sliding window on day four. Each day should include the practice drill at the bottom of the page, not only the reading. Reading feels like progress and disappears under a clock.

Day five is a timed mixed set: one map problem and one window problem you have not looked at in the previous hour, 45 minutes total, with a checkpoint at 25 minutes. Use the checkpoint rule from the time page. Day six, fix whatever failed, slowly. Day seven, off, or a short walk-through of your notes if rest makes you more anxious than work. Write down the one bug you actually hit. That note is more useful than a highlight in a guide.

Hours: about ninety minutes on pattern days, and one longer timed block. If you only have six hours in the week, drop day five's second problem, not the timer. An untimed second pass through a guide is the first thing to cut.

Week 2: strings, stacks, search, and a human story

Day one: strings, including the fork between a bag of characters, a palindrome, and a window. Say the fork out loud. Day two: stacks and queues, and implement the level-order preview only if you have time. The queue policy is the part that must stick. Day three: binary search. Rewrite the lower-bound function until the invariant is boring. The drive-capacity example can wait until day four if the classic search is still shaky. Do not collect both on a day when you are already tired. A sloppy invariant is worse than a postponed page.

Day four is the debugging session: fix the average bug under five minutes, then write a five-sentence work-sample answer. Day five and day six: draft three real STAR stories using the Leadership Principles page. Record one of them. Listen for "we" where you mean "I." This is not a break from technical work. It is the other half of many loops, and it gets worse when you leave it until the night before.

Day seven: a 45-minute timed set that mixes a string or stack task with a binary search. Score yourself only on whether you followed the phases, not on whether you felt clever. The common mistakes page is optional reading at the end of this week if the same bug has already appeared twice.

Week 3: trees, graphs, heaps, and a greedy proof

Day one: trees. Draw the tree before you code. Implement height and level order. Day two: graphs. Include the isolated room and the cycle. If your search hangs, you have learned the visited set in the only way it sticks. Day three: heaps and top-k. Compare the heap with a full sort on a small input so the complexity story is something you measured once. Day four: greedy. The point is the counterexample, not the syntax of sorted. Write the failing start-time rule beside the working one.

Day five: rest or repair. Pick the page from the week that you cannot rewrite. Do only that page. Day six: a timed session, 50 minutes, one graph or tree task and one greedy or heap task. Day seven: tell one STAR story again, aimed at a different principle than last week, and throw away the tag if the story does not fit. Add a fourth story only if the first three are already speakable. A fifth unfinished story is not an asset.

By the end of this week you should be able to say, for each pattern, the one-sentence reason to choose it and the one bug you personally hit. If you cannot, do not start week four's new topics. Repeat the shaky day. The calendar is a default, not a debt.

Week 4: one harder tool, one design, and a mock

Day one: dynamic programming. Do the hop counts until the recurrence is obvious, then the budget subset, including the test that catches the upward loop. Stop there. You do not need a catalog of grid problems this week. Day two: redo one older pattern you disliked. Mastery is repetition, not coverage. Day three: the system design session, thirty minutes, recorded. Delete every technology name that is not tied to a requirement. Day four: the common-mistakes page, slowly, with a pencil. Mark the three you have already committed. Day five: a full mock of whatever your invitation describes. If you still do not know the format, use 70 minutes as a practice number, label it as practice, and do two coding tasks plus five minutes of a spoken story. The number is not special. The label is, because the format guide asked you not to pretend.

Day six: postmortem. For each mock task, write whether you failed in reading, in approach, in coding, or in testing. Those are different failures and they have different fixes. A testing failure means the next mock gets more mean examples, not a new framework. Day seven: off, or a light reread of your one-page personal notes. Do not open a new guide.

How to adjust without negotiating with yourself

If you miss a day, you miss a day. Do the next scheduled day rather than stacking two pattern pages into one evening. Stacked pages are how the drills get skipped. If a page takes longer than the slot, it was the right page and the calendar was optimistic. Stay.

If you want more hours, add timed sessions, not more patterns. A second pass through graphs under a timer teaches more than a first pass through a pattern this site does not have. If you want fewer hours, keep week one's three patterns, the timer, one debugging session, and two stories. Cut heaps and dynamic programming before you cut maps and windows.

Use the homepage link list only as optional color, a few posts a week, and do not let it replace a drill. Public write-ups are someone else's memory. Your blank-file rewrites are evidence. When a post names a topic you have not practiced, schedule that topic. When a post claims to list exact questions, leave it. The about page of this site explains that boundary, and the plan does not cross it.

At the end of the four weeks, you should have: a ritual for a timer, six pattern pages you can rewrite, a visited-set you believe in because you once omitted it, two to four stories you can tell in two minutes, one design sketch you can redraw, and a written note about the bug you personally hit most often. That is a useful outcome. It is not a guarantee of an offer, and the plan does not become more effective if you pretend that it is.