Coding Interview Preparation Plan: 12 Weeks (and a 6-Week Version)
Topics first, then easy-to-hard practice and mock interviews: a 12-week coding interview plan, a 6-week version and a solving routine.
A solid coding interview preparation plan takes about 12 weeks at 11 hours a week: four weeks learning the core topics (arrays, strings, hashing, linked lists, trees, graphs, dynamic programming), then eight weeks of practice that moves from easy to medium to hard problems, with mock interviews from about the 60% mark. If you have less time, a 6-week version below keeps the same order and cuts the volume.
This plan follows the structure of the Tech Interview Handbook, a widely used open guide, and the advice Amazon gives its own software engineering candidates. Use it with our system design interview preparation plan if your rounds include design. Interviewing within a week? Use the seven-day technical interview plan instead.
The 12-week plan
The Tech Interview Handbook recommends about three months at 11 hours a week for well-rounded preparation, starting with topics and moving to mixed practice. The weekly order below follows its sequence.
| Week | Focus | Output by the end of the week |
|---|---|---|
| 1 | Arrays, strings, hash tables, recursion | Two-pointer, sliding window and frequency-map patterns solved from memory |
| 2 | Sorting and searching, matrices, linked lists, queues, stacks | Binary search template; reverse and merge linked lists without bugs |
| 3 | Trees, graphs, heaps, tries | BFS and DFS written cleanly; top-k with a heap |
| 4 | Intervals, dynamic programming, bit manipulation, maths | Five classic DP problems explained aloud with the recurrence |
| 5–6 | Easy problems across all topics, mixed | 30–40 easy problems, each in under 20 minutes |
| 7–11 | Medium problems, mixed; mock interviews start around week 8 | 60–80 medium problems; two mocks a week from week 8 |
| 12 | A few hard problems, revision of weak topics, full mock loops | A list of patterns you can name on sight |
The handbook stresses keeping some mixed practice in every week "so that you don't forget about the earlier topics", and suggests starting mock interviews when you're about 60% through your plan. That's roughly week 8 here.
The 6-week version
| Week | Focus |
|---|---|
| 1 | Arrays, strings, hashing, two pointers, sliding window |
| 2 | Linked lists, stacks, queues, binary search |
| 3 | Trees and graphs (BFS, DFS), heaps |
| 4 | Dynamic programming and intervals |
| 5 | Mixed medium problems, timed; first mock interviews |
| 6 | Weak topics, two mocks, company-specific practice |
How to solve a problem in the interview
Amazon tells its software engineering candidates to expect to write "syntactically correct code—no pseudo code", and to "check for edge cases and validate that no bad input can slip through". It evaluates code that is scalable, robust and well tested. A repeatable sequence covers all of that:
- Clarify. Restate the problem, ask about input size, duplicates, negative numbers and empty input.
- Work an example. Walk through a small input by hand, aloud.
- Brute force first. Say the simple solution and its complexity, so you have a baseline.
- Optimise. Look for the pattern (hash map, two pointers, heap, DP) that removes repeated work.
- Code it cleanly. Use clear names; talk while you write.
- Test. Run your example, then edge cases: empty input, one element, duplicates, large values.
- State complexity. Time and space, and what you would change for bigger inputs.
A daily routine that works with a job or college
| Time | Weekday (about 90 minutes) | Weekend (about 3 hours) |
|---|---|---|
| Warm-up | Re-solve one problem from last week without looking | Review the week's mistakes |
| Main | Two new problems on today's topic, timed | A timed set of four mixed problems |
| Review | Write the pattern and one-line insight for each problem | One mock interview, or explain three solutions aloud |
Keep a simple log: problem, pattern, time taken and what tripped you up. By week 6 the log tells you exactly which topics need another pass.
Mistakes that slow people down
| Mistake | Better |
|---|---|
| Solving hundreds of random problems | Practise by pattern, then mix topics |
| Reading solutions after five minutes | Struggle for 20–30 minutes, then read, then re-solve the next day |
| Practising silently | Talk through your thinking; interviews grade your reasoning |
| Skipping edge cases | Test empty, single-element and duplicate inputs every time |
| No mock interviews until the last week | Start mocks around 60% of the way through the plan |
Practise explaining, not just solving
Mock interviews with a friend are the best way to practise thinking aloud. For solo practice, InterviewGPT can read a coding problem on your screen, transcribe your explanation and suggest an approach with complexity and edge cases, so you can compare it with your own. Our guide to the AI assistant for coding and system design interviews explains what to look for. Use it where AI help is permitted. Download InterviewGPT for Windows and try a timed problem in a free 10-minute session.
