Phase 0 — Foundations & Complexity

Weeks 1–6 | Aug 1 – Sep 7, 2026

Before you touch a single LeetCode problem, you need a working mental model of why some solutions are fast and others are not. This phase builds that model from the ground up. It is not glamorous. It will not feel like coding. Do it anyway — every medium-hard problem you cannot crack in Phase 3 or 4 will trace back to a gap you left here.

The exit state for this phase is simple: given any algorithm, you can reason about its cost without guessing. You can look at code with loops, recursion, or both, and state its time and space complexity with a derivation, not just a label. That ability is what separates people who “know algorithms” from people who actually solve hard problems.

Why This Phase Is Non-Negotiable

Most self-taught engineers skip formal complexity analysis and replace it with intuition (“this looks quadratic”). Intuition works until it doesn’t — and it breaks exactly on the problems you most want to solve. Here’s what the skip costs you:

  1. You can’t prune your solution space. If you don’t know whether O(n log n) is fast enough for n = 10⁶, you’ll waste time coding a solution that TLEs before you understand why.

  2. You can’t compare approaches. “Approach A feels cleaner” is not useful when you need to pick between O(n²) and O(n log n).

  3. You can’t verify recursive algorithms. Recursion without recurrence relations is cargo-cult programming. You’re hoping it works, not knowing it does.

Topics Covered

Topic

Depth Required

Common Mistake

Big-O / Big-Θ / Big-Ω notation

Full formal intuition; derive for any code

Confusing Big-O (upper bound) with worst-case performance

Single, nested, halving loops

Derive complexity mechanically

Assuming nested loops are always O(n²) — they’re not if ranges differ

Recurrence relations

Master Theorem (all 3 cases) + substitution method

Eyeballing recursive code complexity instead of writing the recurrence

Space complexity

Call stack included

Forgetting recursive call stack adds O(depth) space

Amortized analysis

Dynamic array doubling proof

Treating worst-case single operation as representative of all operations

Loop invariants

Write one for any iterative algorithm

Skipping invariants → bugs you can’t reason about

Proof by induction

One worked example per algorithm

Treating induction as a math-class-only tool

Mathematical toolkit

Log identities, modular arithmetic, combinatorics basics

Treating math as optional — it’s not

Pseudocode discipline

4-step problem-solving protocol

Going straight to code before understanding the algorithm

3 Things Most Learners Get Wrong About Complexity

1. Big-O is not the worst case — it’s an upper bound. Big-O describes asymptotic behavior and can be applied to best, average, or worst case. The common shorthand “O(n) is the worst case” is technically wrong. Merge sort’s worst-case time complexity is Θ(n log n) — both an upper and lower bound. Learn the difference between O, Ω, and Θ early.

2. O(1) does not mean “fast” — it means “doesn’t scale with input size.” Accessing a hash map is amortized O(1). Accessing an array element is O(1). They are not equally fast in practice — the hash map involves a function call, potential collision handling, and cache misses. Understanding asymptotic notation without understanding that constants exist is half an education.

3. Recursive complexity cannot be eyeballed. A function that calls itself twice is not automatically O(2ⁿ). A function that calls itself twice on half the input is O(n). You need the recurrence. Write it. Then solve it.

Phase Duration & Schedule

  • Duration: 6 weeks (Weeks 1–6)

  • Start: August 1, 2026

  • End: September 7, 2026

  • Weekly commitment: 10–15 hours/week personal time

See 05_exit_criteria_and_projects.md for the week-by-week breakdown.

Files in This Phase

File

What It Covers

01_big_o_mastery.md

Full complexity analysis: O/Θ/Ω, loop analysis, space complexity, amortized analysis

02_recurrence_relations.md

Master Theorem, substitution method, recursion trees

03_mathematical_thinking.md

Induction, loop invariants, logarithm identities, combinatorics

04_pseudocode_and_invariants.md

Problem-solving protocol, pseudocode conventions, mental tracing

05_exit_criteria_and_projects.md

Exit criteria, 3 micro-projects, week-by-week schedule