Cut the fortnight in half and give each half one job. Week 1 is build week: one pattern per day, two problems, and a trigger sentence you write out in your own words, the kind that reads "sorted array plus a target sum implies two pointers from both ends". Week 2 is simulate week, and it adds no new material at all: six timed 45-minute sessions, each scored out of five on clarify, brute force stated, optimise, code, test. By day 14 the score sheet tells you which of those five steps you keep dropping under the clock, which is usually the reason a solved problem still fails the round.
Why the split, and why week 2 is sealed
Two weeks is the shortest window where you can afford to spend half of it not learning anything new. Most people spend all fourteen days in build mode, meet a fresh pattern on day 13, and walk into the call having never once run the whole performance end to end against a clock. The result is a candidate who genuinely knows sliding window and still goes silent for ninety seconds at minute four.
So week 2 is closed to new topics. No new patterns, no quick look at tries, no first attempt at 2D dynamic programming. The problems are unseen, but every technique they need was covered in week 1. If a session throws something you never studied, that is information about your gaps, not permission to reopen the syllabus with five days left.
Week 1: one pattern a day, one trigger sentence a day
Each day is roughly two hours: 30 minutes reading the pattern and writing its template from memory, two problems at 30 minutes each with a visible timer, then 15 minutes writing the trigger sentence. The sentence is the deliverable. The problems exist to earn it.
| Day | The trigger sentence you should be able to write by the end of the day | Two problems |
|---|---|---|
| 1 Hash maps |
"I need to know whether I have seen a value before, or how many times, so I want a map from value to index or count built in one pass." | Two Sum, Group Anagrams |
| 2 Two pointers |
"Sorted array plus a target sum implies two pointers from both ends. If it is unsorted and sorting would destroy the indices I have to return, it is a hash map instead." | Valid Palindrome, 3Sum |
| 3 Sliding window |
"Longest or shortest contiguous run subject to a constraint implies expand right, shrink left while the window is invalid, record the best as I go." | Longest Substring Without Repeating Characters, Minimum Size Subarray Sum |
| 4 Binary search |
"The answer is a number in a known range and I can cheaply test whether a candidate k works, so I binary search the answer rather than the array." | Search in Rotated Sorted Array, Koko Eating Bananas |
| 5 Trees and graphs |
"Fewest steps on an unweighted graph implies BFS with a queue. Does a path exist, or explore this whole region, implies DFS with a visited set." | Binary Tree Level Order Traversal, Number of Islands |
| 6 Heaps and intervals |
"Top k out of a large stream implies a heap of size k, not a full sort. Overlapping ranges implies sort by start, then merge into the last interval." | Top K Frequent Elements, Merge Intervals |
| 7 1D dynamic programming |
"The answer at position i is built from a fixed number of earlier answers, so I say what dp[i] means in one English sentence before I write any code." | Climbing Stairs, Coin Change |
What makes a trigger sentence work
The sentences above are examples, not the assignment. Yours will be worse on day 1 and sharper by day 7, and the ones you wrote yourself are the ones that actually fire in a live round. Four rules keep them useful:
- Name the cue, not the technique. "Use sliding window for substring problems" is a label. "Longest contiguous run subject to a constraint" is something you can spot in the first line of a problem statement.
- Include the counter case. Every sentence should say when the pattern is wrong, because the expensive mistake is not failing to recall two pointers, it is reaching for it on unsorted input and losing eight minutes.
- Under thirty words, written by hand. Anything longer is a summary of the editorial, and you will not retrieve a paragraph under pressure.
- Test it on the first line only. Open an unseen problem, read one sentence, close it, and say which trigger fired. If nothing fires, the sentence is wrong, so rewrite it that evening.
By day 7 you have seven sentences on one card. That card is your entire revision material for week 2. Read it for two minutes before a session and never during one.
Week 2: six timed sessions and the five-step rubric
Days 8 to 13 are one 45-minute session each, hard stop, spoken out loud, on the machine and editor you will actually use. Sessions 1 to 4 are a single unseen medium. Sessions 5 and 6 are a 15-minute easy followed by a 30-minute medium inside the same 45 minutes, because that is how a real screen paces, and because the second problem with a tired brain is where people come apart. Record the audio on your phone. Nobody scores their own narration honestly from memory.
Minutes 0 to 4, clarify and state the brute force
Two questions that could change your plan: input size, duplicates, empty or negative values, whether it is already sorted. Then say a working brute force aloud with its complexity. No typing yet.
Minutes 4 to 8, optimise aloud
Name the pattern, say the trigger sentence that fired, state the new time and space, then say "I will code that" before your hands move.
Minutes 8 to 35, code
Keep talking. If you stall for more than twenty seconds, say out loud what you are stuck on, because in a real round that sentence is what earns you a hint.
Minutes 35 to 45, test and close
Trace one normal example by hand, then one edge case. Find your own bug before the timer does. Finish with the final complexity and one line on what you would change with more time.
Then spend ten minutes scoring the recording. One point per step, zero or one, no half marks.
| Step | Scores 1 only if | What a repeated zero means |
|---|---|---|
| Clarify | You asked at least two questions before writing anything, and at least one answer changed your approach. | You are treating the interview as an exam. Script two questions you ask every single time and open with them. |
| Brute force stated | A correct brute force and its complexity were spoken inside the first four minutes. | You leap at the optimal and go quiet when it does not come. Ban typing until minute four for two sessions. |
| Optimise | You named the pattern and the reason before coding, and gave the improved time and space. | Your trigger sentences are labels, not cues. Rewrite the three that never fired. |
| Code | Running code by minute 35, no pseudo-code left in the file, no syntax you had to look up twice. | This is language fluency, not algorithms. Spend two evenings on the standard library calls you keep fumbling. |
| Test | You traced a real example plus one edge case and caught or ruled out a bug yourself before time. | The most common zero by a distance. Set a second alarm at minute 35 that you are not allowed to ignore. |
Keep the six scores in one grid, five rows by six columns. The shape matters more than the average. A column of fives beside a column of twos is a bad day. A row that reads zero four times out of six is your interview, and it is the one thing here you can still fix in the days you have left. Where you want a worked solution after a failed session, read it after you have scored yourself, never during. Code Copilot captures the problem with Ctrl+Alt+S and returns the intuition, a dry run and the Big-O, which is a reasonable editorial substitute at minute 46 and corrosive at minute 20.
Day 14: no problems
Re-read the seven trigger sentences, re-read the six score grids, and run the machine check. Join a test call on the platform named in your invite, share your screen and look at the shared view on a second device, silence notifications, and run a hello world in the editor you plan to use. If a behavioural round is stapled to the technical one, write out the four answers you know are coming instead of improvising. The company Q&A generator builds a role-specific bank in a few minutes, which is a better use of day 14 than a fifteenth medium.
Where this plan is the wrong plan
Six sessions is a small sample. An average of 4 out of 5 is a signal, not a guarantee, and self-scoring runs generous by roughly a point until you have listened back to yourself twice. The rubric also assumes a human is watching. On an auto-graded online assessment nobody scores your clarifying questions or your narration, only whether the submission passes hidden tests, so for those rounds you deliberately drop clarify and optimise-aloud and practise raw speed instead. Two weeks will not carry you through senior system design either, and it cannot manufacture fluency in a language you are still looking up.
Be equally plain about tooling. OfferPilot AI runs on Windows 10 and 11 only, with no macOS, Linux or mobile build, so on a Mac the day 14 machine check still applies to you and the software does not. Its overlay is excluded from screen capture at the operating-system level, so it does not appear in Zoom, Teams, Meet or a screen recording, and that is a fact about screen sharing and nothing else. It does nothing about a webcam, a lockdown browser, a proctor sitting with you, or a phone camera pointed at your desk, and where an assessment forbids outside help the useful window is the fourteen days before it, not the round. Nothing here rehearses on your behalf either. The five steps become automatic because you ran them six times against a clock, not because you read the rubric.
Start tonight, not tomorrow
Day 1 costs two hours and produces one sentence about hash maps. If tonight is already gone, run days 1, 2, 3, 5 and 7 as a shortened build week and keep all six sessions intact, because simulate week is the half that is genuinely scarce. For the reading block, the free tier is five minutes a day with no card required, and the paid options sit on the pricing page.