Study Roadmap¶

A course this size needs an order. This is the sequence that works, and — more importantly — what you should be able to build at the end of each phase. Reading without building does not produce an engineer.

1. Foundations¶

Parts 1–6 · Weeks 1–3

Build fluency in the core language: how Python runs, values and variables, control flow, functions and the functional toolkit, data structures, and files/errors. This is the bedrock everything else stands on.

Set up the modern toolchain early (Python 3.13 + uv) so you practise in a real environment.
Write small programs daily; type every example yourself rather than reading passively.
By the end you should reach for the right container by instinct and write clean functions with type hints.

2. Object-Oriented & Advanced Python¶

Parts 7–8 · Week 4

Learn to model with classes, choose composition over inheritance, and use protocols and ABCs. Then tackle concurrency: async/await, threads vs processes, the GIL, and how to make Python fast.

Internalise SOLID as a lens, not a checklist.
Be able to explain concurrency vs parallelism and when to use each — a frequent interview question.

3. Professional Toolchain¶

Part 9 · Week 5

Adopt the practices that separate hobby code from production code: packaging with pyproject.toml, testing with pytest, quality gates with ruff and mypy, and the NumPy/pandas data stack.

Wire ruff, mypy, and pytest into pre-commit so quality is automatic.
Aim to write a test before fixing any bug from here on.

4. Web, APIs & Databases¶

Part 10 · Week 6

Connect Python to the outside world: HTTP and REST, building typed APIs with FastAPI, and persisting data with SQL. This is where your code becomes a service other systems can use.

Build one small FastAPI service end to end and call it from a client.
Always parameterise SQL; understand why string-built queries are dangerous.

5. CI/CD, Containers & Infrastructure¶

Parts 11–13 · Weeks 7–8

The differentiator for solutions-consulting roles: what CI/CD is and how pipelines are built, Docker and Kubernetes, and deploying across cloud, on-premises, and hybrid infrastructure with IaC and GitOps.

Containerise your FastAPI service and push it through a GitHub Actions pipeline.
Be able to whiteboard a hybrid topology and justify what runs where by data gravity.

6. System Design & Interview Mastery¶

Parts 14–16 · Weeks 9–10

Bring it together: distributed-systems building blocks and observability, then the full interview loop — DSA patterns, coding-round technique, the solutions-consulting design interview, behavioural prep, and the capstone.

Do timed mock interviews; practise narrating your reasoning aloud.
Rehearse the capstone story until you can tell it end to end from memory.

Cheat Sheet · Cloud vs On-Prem vs Hybrid¶

◆. Where should this workload run?¶

Decide by data gravity and constraints, not dogma

Cloud when the workload is stateless, bursty, or latency-tolerant, and you want elasticity and pay-as-you-go scale without owning hardware.
On-premises when data is large, sensitive, or regulated (residency/compliance), latency to existing systems is critical, or you have heavy sunk hardware investment.
Hybrid when both are true at once: keep regulated data and its compute on-prem, burst the public-facing tier into the cloud, bridge with a private interconnect, and drive both from one pipeline.
The four hybrid enablers: private network bridge, consistent orchestration (Kubernetes everywhere), unified identity, and centralized observability.

Cheat Sheet · The CI/CD Pipeline Spine¶

◆. Commit to production, every time¶

Build once, deploy many

1. Trigger — a push or merge to the main branch starts the pipeline.
2. Gate — run tests, linting, type checks, and security scans; never build a failing commit.
3. Build — produce one immutable container image tagged by commit SHA.
4. Scan & push — check the image for vulnerabilities, then store it in a registry.
5. Deploy — promote that same image to each environment (cloud, on-prem, or both).
6. Observe — watch metrics, logs, and traces; roll back by re-deploying the prior image.

Cheat Sheet · Big-O Quick Reference¶

◆. Complexity & common Python costs¶

The efficiency vocabulary interviewers expect

Growth (best→worst): O(1) < O(log n) < O(n) < O(n log n) < O(n²) < O(2ⁿ).
dict / set: average O(1) membership, insert, and lookup — the go-to for de-duplication and counting.
list: O(1) index and amortised append; O(n) insert/delete at the front or membership test.
Sorting: O(n log n) — often the right first step that unlocks two-pointer or binary-search solutions.
Pattern triggers: “pairs/lookups”→hash map; “sorted array”→two pointers/binary search; “substring/subarray with a constraint”→sliding window; “shortest path / levels”→BFS.

Cheat Sheet · The Design-Interview Framework¶

◆. Six steps for any system-design prompt¶

Requirements first; earn every component

1. Requirements — functional and non-functional (scale, latency, availability, consistency, budget, compliance).
2. Estimate — rough users, QPS, data size, read/write ratio to justify decisions.
3. High-level design — major components and the data flow between them.
4. Deep-dive — go deep where the interviewer probes: data model, an API, a bottleneck.
5. Scale & evolve — add caching, replicas, sharding, and queues, narrating each trade-off.
6. Wrap up — summarise, name risks, and state what you’d monitor. For consulting, tie it to cost, compliance, and deployment topology.