From never having programmed to understanding algorithms
Thirty-six weeks, ten hours a week, in Python. The first thirteen weeks teach you to program at all. The rest teach you how data is organised, how algorithms work, and how to tell whether code you are looking at is right. Every technical word is defined the first time it appears — click any underlined term to see what it means.
A binary tree — what weeks 26 to 29 teach you to build
Nothing here assumes you have written a line of code before. By the end of week 13 you will have built about twenty small programs and will be able to write a class from a blank file.
Install the two pieces of software you will use for the next nine months, and prove they work.About 2 hours, before the clock startsWeeks 1–3Telling the computer what to do
Storing information, making decisions, and repeating work. These three ideas sit underneath every program ever written.About 30 hoursWeeks 4–6Reusable steps, and Python's built-in containers
Packaging work into functions, and the four ways Python stores collections of things: lists, dictionaries, tuples and sets.About 30 hoursWeeks 7–10Reading crashes, working with files, and finding bugs
How to read an error message instead of panicking, how to save and load data, and how to work out why a program is doing the wrong thing.About 30 hoursWeeks 11–13Building your own kinds of thing
Classes let you bundle information together with the actions that work on it — and one object holding a reference to another is the idea every data structure ahead is built from.About 30 hours
The same skills, applied to the question of how to organise information so that programs stay fast as they grow. This half is where the well-known names live: hash tables, trees, graphs, sorting, dynamic programming — with testing and reading unfamiliar code sitting in the middle of it, because both pay off across everything that follows them.
A vocabulary for describing how badly a program slows down as its input grows — and a proper look at recursion.About 20 hoursWeeks 16–20Structures that lay things out in a line
Arrays, linked lists, stacks, queues and hash tables — the workhorses. Build each one yourself, then use the built-in version forever after.About 50 hoursWeeks 21–23Proving code does what you think
How to tell whether code is correct — your own, and the code a model hands you that looks right.About 30 hoursWeeks 24–25Reading code you did not write
Entering a codebase cold, following one path through it, and changing something safely without understanding all of it.About 20 hoursWeeks 26–29Trees and graphs
Structures that branch instead of running in a line. This is the hardest stage in the roadmap and deserves the extra time.About 60 hoursWeeks 30–32The classic algorithms
Searching, sorting, and the graph algorithms behind route-finding and dependency resolution.About 50 hoursWeeks 33–35Choosing the right approach
The previous stages gave you tools. This one is about recognising which tool an unfamiliar problem calls for.About 40 hoursWeek 36 and beyondOptional depth
Specialised structures and ideas worth knowing about. Treat this as a menu, not a checklist.About 20 hours, then ongoing
Type every example yourself
Do not copy and paste, and do not just read. Watching someone code feels like learning and is not. The gap between understanding a video and writing code on a blank screen is the entire skill, and copying skips exactly the part that builds it.
Build each structure once, then never again
Implement every structure from scratch a single time, so it stops being magic. After that, use the version that ships with the language — it is faster and it has had its bugs found already.
Thirty minutes before you look at a solution
Struggling is the part that teaches. Reading a solution before you have genuinely tried feels efficient and leaves nothing behind.
Keep a mistake log
Write down the problem, why you failed it, and the pattern you missed. Read it back weekly. This is the highest-value habit in the whole roadmap, and the one most people skip.
Done means from a blank file
A topic is finished when you can re-implement it with nothing in front of you, and say what it costs in time and memory. Recognising code is not the same as being able to write it.
Six hours learning, four hours solving
Of ten hours a week, roughly six go on learning and implementing and four on problems. Reading without solving is the single most common way people spend months and gain little.
| When | Hrs | What you do |
|---|---|---|
| Mon–Tue | 3 | New topic: read and watch, then write notes in your own words. |
| Wed | 2 | Implement the structure or algorithm from scratch, with nothing to refer to. |
| Thu–Fri | 3 | Solve four to six problems on the topic, working from easy up to medium. |
| Sat | 1 | Re-solve two problems you previously failed, taken from your mistake log. |
| Sun | 1 | Review: say the costs out loud, update your notes, plan the week ahead. |
About eight to nine months at ten hours a week to reach the end of week 36. That is a normal, honest timeline starting from zero. Anyone promising mastery in eight weeks is selling something.
The week numbers are a guide, not a deadline. Two stages in particular — trees and graphs in weeks 26 to 29, and dynamic programming in week 33 — are where most people slow down or give up. If you fall behind, take the extra weeks there rather than skipping ahead. Everything later depends on those two.
This roadmap is written for becoming a better engineer rather than for passing interviews. Where the two differ, it favours understanding fewer things properly over covering more things quickly.