Spend the first week on your fingers, not on problems. After years of shipping features, what decayed is not your reasoning, it is your ability to type a hash map count, a grid BFS and a binary search from memory without looking anything up. Weeks two to four rebuild patterns starting from easies you will find insulting. Weeks five and six add a 35-minute timer and the sound of your own voice, which is where most senior candidates actually lose the round.
What actually rusted, and what did not
The instinct is to open a medium on day one, stall on it for forty minutes, and conclude you have forgotten how to code. You have not. Open your last three pull requests. They are better than anything a new grad writes.
Three specific things went. Syntax recall under a clock, because your editor has been finishing collections.deque for you for years. The ritual of thinking out loud in front of a stranger, which nothing in your job rehearses, since design docs are asynchronous and standups are status. And tolerance for a problem with no product context, no existing code, and no ticket explaining why anyone wants it. None of those are repaired by grinding mediums, and grinding mediums in week one is how people quit in week two.
You also keep advantages a new grad does not have. You debug fast. You spot the edge case before you are asked. You can talk about a trade-off without rehearsing it. The last two weeks of this plan exist to convert that into something an interviewer can actually score.
Week 1: three drills from memory, and nothing else
No problem sites this week. You are not solving problems, you are rebuilding typing. Three drills, every morning, from a blank file, with no autocomplete, no documentation tab, and no assistant.
The count
Given a list of strings, return the most frequent one, ties broken by first appearance. Then run it on three test cases you wrote yourself, one of which is an empty list.
The grid BFS
Shortest path from top-left to bottom-right of a grid of open cells and walls, four directions, returning -1 when unreachable. Mark cells visited when you enqueue them, not when you dequeue them.
The lower bound
In a sorted array, return the leftmost index whose value is greater than or equal to the target, and the array length if there is none. Not whether the value exists. The lower bound form is the one interviews actually build on.
Each one has to land in under ten minutes, correct on the first run, with zero lookups. On day one expect twenty to thirty minutes each and at least one syntax error you would be embarrassed to show a colleague. That is the point of measuring it. By Friday all three should be under ten, and that is a gate: do not start week two until you pass it.
| Drill | What it exposes | Pass condition |
|---|---|---|
| The count | The default-dict or get-or-default idiom, sorting by value, whether your language preserves insertion order in a map | Under 10 minutes, correct on your own three tests |
| Grid BFS | Which import gives you a queue, visiting at enqueue time so you do not revisit, bounds check before the grid read | Under 10 minutes, returns -1 on a fully blocked grid |
| Lower bound | Whether you write while lo < hi with hi = mid, or while lo <= hi with hi = mid - 1, and whether you mix the two under pressure | Under 10 minutes, correct on empty, all-smaller and all-larger arrays |
The reason this comes first is arithmetic. The first six minutes of a 35-minute round are the expensive ones. Spend them recalling that a priority queue defaults to a min heap and that you wanted the opposite, and that time comes out of thinking, not out of slack. The interviewer does not see rust, they see hesitation.
Weeks 2 to 4: patterns, from easies upward
Start below your level on purpose. An easy solved in eight minutes with the trigger written down beats a medium you half-finished with the editorial open in the next tab. One pattern per session, and a pattern is not finished until you can write its trigger sentence, meaning the property of the input that should make it fire.
- Sorted input, and you need a pair meeting a condition, fires two pointers.
- Longest or shortest run subject to a constraint fires a sliding window.
- Nearest greater or smaller element fires a monotonic stack.
- Shortest path with unweighted edges fires BFS, and never DFS.
If you cannot write the sentence, you memorised a solution rather than learning a pattern, and it will not survive the version with different wording.
| Week | Patterns | Session shape | Length |
|---|---|---|---|
| 2 | Counting and hashing, two pointers, sliding window, stacks | Three easies, then one medium | 60 min |
| 3 | Tree traversal and depth, BFS by level, linked lists, binary search variants, heaps and top-k | Two easies, then two mediums | 75 min |
| 4 | Graphs on grids and adjacency lists, backtracking, intervals, one-dimensional DP | One easy, then two mediums | 90 min |
Five sessions a week, so roughly twenty problems a week and about sixty across the three weeks. One rule holds all of it together: every session opens by re-solving one problem from the previous session, from a blank file, before you read anything new. It costs ten minutes and it is the only reason week four is possible.
Weeks 5 and 6: the timer and the speech
The failure mode changes now. It is no longer knowledge, it is delivery. Two sessions a day: an unlabelled problem pulled at random from the weeks two to four topics, a 35-minute timer, a screen recording running, and you talking aloud from the first second even though nobody is there.
The opening is a fixed ritual, four to six minutes, identical every time:
- Restate the problem in your own words, including the input type and what gets returned.
- Ask exactly one clarifying question that could change the answer. Whether the array can be empty is filler. Whether the intervals arrive sorted by start is not.
- Say the brute force out loud with its complexity, even when it is embarrassing.
- Name the improvement, the data structure that buys it, and the new complexity.
- Ask whether they want you to code that. Only then do you type.
Then review the recording, but only the first six minutes of it, at 1.5 speed. Count every silence longer than twenty seconds. In week five you will find three or four. By the end of week six you want none, and the way there is narrating the dead ends. Saying that you are checking whether sorting first breaks the index requirement is a sentence. Staring at the screen is not. In week six, replace two solo sessions with live mocks against a human, and spend the recovered time re-solving whatever broke.
The three habits senior candidates specifically fail on
These are not beginner mistakes. Each one is the direct result of several good years of engineering.
1. Coding before narrating. At work the code is the explanation, and nobody makes you defend a plan for a thirty-line function before you write it, so you stopped doing it. In an interview the plan is a graded artifact. A senior who opens the editor at minute two and types quietly for fifteen has handed the interviewer nothing to score, and a correct solution that arrived in silence reads as memorised rather than solved. The fix is mechanical: nothing gets typed until step five of the ritual above.
2. Building the production version. You will reach for input validation, a custom exception type, a small interface, a note about thread safety, because that is what code review trained into you. In a 35-minute problem none of it is scored and all of it costs clock. Solve the stated problem for the stated inputs. Pay the production instinct with one sentence, that in real code you would validate the grid here but will assume it is well formed, and move on.
3. Skipping the brute force. Seniors dismiss it, usually silently, because they can already see the good answer coming, or they deflect by saying they would just reach for a library at work. Both lose points. The brute force is a free checkpoint, and stating its complexity is what makes your improvement legible as an improvement. Say the quadratic answer in one sentence, then beat it.
Where this plan, and this tool, are wrong for you
Six weeks buys you the coding rounds and nothing else. A senior loop is usually two coding rounds plus two or three system design and behavioural rounds, and none of that appears above. If your loop is design heavy, compress this rebuild to four weeks and spend the rest elsewhere. If you moved into management and have not written the interview language in years, one week of re-fluency is not enough. Give it two, accept that the plan is now seven weeks, and do not skip the gate. And if your first interview is more than eight weeks out, slow weeks two to four down rather than piling more problems into them.
On tooling, the honest limitation runs against us. During a timed session in weeks five and six, Code Copilot is the wrong tool, and opening it inside the timer destroys the only unfaked measurement in this plan. It belongs at minute 36, when you want the optimal solution with the intuition, a dry run and the Big-O in one place rather than spread across four forum threads. The practical facts: OfferPilot AI runs on Windows 10 and 11 only, with no macOS, Linux, mobile or browser version. Its overlay is excluded from screen capture at the operating system level, so it does not appear in Zoom, Teams, Meet, OBS or screenshots. That covers screen sharing and nothing beyond it. It does nothing about a webcam, a lockdown browser, a proctor sitting next to you, eye tracking, or a phone pointed at your desk. Where an assessment forbids outside help, the six weeks before it are the part that counts.
Start tonight, not Monday
Open a blank file and run the count drill right now against a timer. Whatever number comes back is your baseline, and it is the one measurement here you cannot argue with. Then put five weekday sessions in the calendar and defend them like meetings. If the loop also has behavioural rounds, the company Q&A generator builds a role-specific bank, and it belongs in weeks five and six, not week one. The free tier is five minutes a day with no card.