How to prepare for coding interviews in 15 days
Be honest about what fifteen days can do
Fifteen days will not turn you into someone who has seen every problem. It can make you reliably good at the dozen or so patterns that account for most of what product companies ask, and it can fix the habits that cost people offers: starting to code before they understand the problem, running out of time on the second question, and freezing when the first idea fails.
If you are four to fifteen years into your career, you already know how to build software. The gap is rarely knowledge. It is that you have not solved a problem from a blank editor, against a clock, with nobody to nudge you, in a long time. The plan below is built around closing that gap, not around collecting more material to read.
Set the budget before you set the plan
Decide how many hours a day you can protect. For most people with a full-time job that is two hours on weekdays and four on weekends. Write the number down. A plan that assumes six hours a day and gets two will leave you demoralised by day four; a plan that assumes two and gets two will finish.
Then decide the order of topics by your interviews, not by a generic list. Check what the company actually tests. Some loops are two coding rounds and a design round; some are four coding rounds. Weight your time to match.
Days 1 to 5: foundations, timed from the first day
Start with the patterns that unlock the most problems: arrays and hashing, two pointers, sliding window, stack, and binary search. Do two or three problems a day, each on a clock of 25 minutes. Timing from day one matters because the clock is part of the skill. Untimed practice trains a slower, more comfortable version of the thing you will be asked to do.
- Read the problem twice and restate it in your own words before touching the keyboard.
- Write down two or three edge cases first: empty input, a single element, duplicates, the largest allowed size.
- Brute force first, out loud or in a comment, then improve it. A correct slow answer beats an unfinished clever one.
- When the 25 minutes are up, stop. Do not keep going "just to finish". Note where you were stuck.
Good first problems for this stretch are First rescan, Pairs under budget and Longest under-budget stretch. Each has three graded hints, so you can see what a nudge looks like without being handed the answer.
Days 6 to 10: trees, graphs, heaps and the first design round
Move to recursion-heavy and structure-heavy material: trees, graphs, heaps, intervals, linked lists. These feel harder because the state you track is larger. The fix is almost always the same: name what the recursive call returns, name what you carry down, and say the base case first.
Add one system design session in this window if your loop includes one. You do not need a polished diagram. You need to be able to state requirements, estimate scale in a sentence, pick a data model, and name two trade-offs. Our guide to practising system design without AI help lays out a routine for that.
By day eight, return to one problem you got stuck on during days one to five and redo it from scratch. If you cannot, the problem was not learned; it was recognised.
Days 11 to 14: mixed sets under interview conditions
Stop practising by topic. Interviewers do not announce the pattern. Do mixed sets of two problems in 50 minutes, in a quiet room, with no documentation, no autocomplete help and no second monitor of notes. Practise saying your reasoning aloud even if nobody is listening; it keeps you from going silent when it counts.
Keep a plain log: problem, pattern, minutes taken, whether you passed the hidden cases, where you got stuck. After a week the log tells you your weak patterns more accurately than your feelings do. Most people overestimate their strength in whatever they practised last and underestimate the pattern they avoided.
Spend the final minutes of each session on review. Read a clean solution only after your clock has run out, close it, and implement it again from memory. The second implementation is where the learning happens.
Day 15: light work and logistics
Do one easy problem to stay warm and stop. Check your editor setup, your connection, the language you will use, and the exact format of the round. Sleep is worth more than a fourth problem.
What a plan should adapt to
A fixed list is a fine start, but it ignores what you actually did. If you are quick on windows and slow on graphs, day 12 should have more graphs. Unaided builds the plan from your resume and stack, sized to a 7, 15 or 30 day run and to the hours you give it, then adjusts the weighting as your logged attempts show where you lose time or lean on hints. That is the mechanism, nothing more mysterious: the plan responds to your history, and the hidden tests tell it the truth.
You can follow this guide by hand with a notebook and a timer. If you would rather have the plan, the clock and the hidden tests handled for you, start your plan. Prices are on the pricing page, and you can try one problem free first.