07 — Phase 5 Exit Criteria & Projects

Phase 5 | Week 36 | Apr 6, 2027

This is the last checkpoint in the 9-month roadmap. If you’ve reached this file having done the work — not skimmed it, done it — you are a materially different engineer than you were in July 2026. Phase 5 exit criteria are implementation-focused. The question is not “do you understand the concept?” but “can you produce correct, working code under time pressure?” That gap — between understanding and producing — is what separates people who talk about segment trees and people who solve problems with them.

Exit Criteria

Criterion 1: Segment Tree with Lazy Propagation in ≤ 45 Minutes

Implement a segment tree supporting range sum queries, point updates, and range add-updates with lazy propagation, from scratch, in under 45 minutes. The implementation must be correct and tested against at least 3 query/update sequences.

How to test yourself: Close all references. Time yourself building it from scratch. Test with:

  • Build from [2, 1, 3, 4, 5]

  • Range query [1, 3] → should return 8

  • Range update [1, 3] add +2 → array becomes [2, 3, 5, 6, 5]

  • Range query [0, 4] → should return 21

  • Point update index 2 set to 0 → array becomes [2, 3, 0, 6, 5]

  • Range query [1, 4] → should return 14

You pass if: Implementation is correct on all 6 test cases and finishes in under 45 minutes.

If you can’t do it: You haven’t implemented it enough times. Implement it from scratch 3 more times — not reading, implementing. The structure always feels shaky until the third clean pass, at which point it becomes mechanical.

Common failure modes:

  • Wrong array size (use 4n, not 2n)

  • Forgetting push_down before recursing in both update_range and query

  • Wrong identity element for the aggregate (0 for sum, ∞ for min, -∞ for max)

  • Off-by-one in segment boundaries (mid = (start+end)//2, right child starts at mid+1)

Criterion 2: Structure Identification in ≤ 5 Minutes

Given a novel problem description, identify which Phase 5 technique is required (segment tree, Fenwick tree, greedy, bit manipulation, KMP/Z/rolling hash, non-comparison sort, or monotonic stack) within 5 minutes, without writing code.

How to test yourself: Find 10 problems you haven’t seen that use Phase 5 techniques. Set a 5-minute timer per problem. Write: (a) the technique, (b) one sentence on why that technique applies.

You pass if: 8 out of 10 correct identifications.

Trigger phrases to internalize:

  • “Range query with updates” → segment tree or BIT

  • “Prefix sum with updates” → BIT is simpler

  • “Locally optimal → globally optimal” + you can sketch an exchange argument → greedy

  • “n ≤ 20, subsets” → bitmask DP (from Phase 4, but same family)

  • “Pattern matching,” “does string contain pattern” → KMP

  • “Rolling window equality, duplicate substrings” → Rabin-Karp

  • “Integers in bounded range, sort in O(n)” → counting/radix sort

  • “Next greater element,” “largest rectangle” → monotonic stack

Criterion 3: Codeforces Div. 2 C/D Problems

Solve at least 3 Codeforces Div. 2 problems rated 1400–1800 that require Phase 5 techniques. All 3 must receive an “Accepted” verdict on the Codeforces platform. Reading solutions and then submitting does not count.

How to find problems: On Codeforces, filter problems by rating [1400, 1800] and tag (e.g., “data structures” for segment trees, “greedy,” “strings” for KMP/Z/hashing). Pick unseen problems. Attempt independently for at least 45 minutes before reading any editorial.

You pass if: 3 accepted submissions, at least 2 of which used Phase 5 techniques, not counting problems you solved only after reading the editorial.

This is the hardest criterion. Codeforces problems are harder than LeetCode at equivalent ratings because they test problem formulation skills, not just known patterns. A 1600-rated CF problem often requires combining two techniques you know. That’s the point.

Projects

Project 1: Advanced DS Library

What to build: A personal code library containing clean, tested implementations of:

  1. Segment Tree with lazy propagation (range sum, range add, point query)

  2. Fenwick Tree with point update and prefix query

  3. KMP with failure function and full search

Each implementation must be:

  • Written from memory (no copying from references)

  • Tested with at least 3 edge cases each (empty array, single element, query on full range, etc.)

  • Stored in your own repo/files with comments explaining the invariant, not just the code

Acceptance criteria: Given any of the three structures, you can locate your implementation, explain what the invariant is (not just what the code does), and pass a peer code review without needing to look anything up.

Format: Three files in this directory or your own repo:

segment_tree.{java|cpp|py}
fenwick_tree.{java|cpp|py}
kmp.{java|cpp|py}

Why this project: You will use these implementations again. An ML Engineer at Zoho doing serious CP or preparing for FAANG needs a personal library of correct implementations. The time spent building it correctly once saves hours of debugging in future contests and interviews.

Project 2: LeetCode 20-Problem Advanced Sprint

What to build: Solve 20 LeetCode problems from Phase 5 topics:

  • 2 Easy

  • 10 Medium

  • 8 Hard

Acceptance criteria: ≥ 65% independent solves (13 out of 20). 65% is honest for this tier — Phase 5 Hards are genuinely hard, and some will require reading editorials. Track honestly.

Tracking table format:

| Problem | Technique | Independent? | Time (min) | Attempt # |
|---|---|---|---|---|
| Range Sum Query - Mutable (307) | Segment Tree | Yes | 32 | 1 |
| Reverse Pairs (493) | Fenwick Tree / Merge Sort | No | 60+ | 2 |

Suggested problems: Use the practice problems listed at the end of each file in this phase (files 01-06). They cover all techniques with appropriate difficulty spread.

Prioritize these if you only have time for 10:

  • LeetCode 307 (Segment Tree baseline)

  • LeetCode 315 (BIT + coordinate compression)

  • LeetCode 732 (Lazy propagation)

  • LeetCode 28 (KMP — implement it properly)

  • LeetCode 214 (KMP application)

  • LeetCode 55 and 45 (Greedy — Jump Game I and II)

  • LeetCode 253 (Meeting Rooms II — greedy + heap)

  • LeetCode 136 and 260 (XOR single/double non-duplicate)

  • LeetCode 215 (Quickselect)

Project 3: Codeforces First 5

What to build: Solve 5 Codeforces Div. 2 problems rated 1400–1800. At least 3 of them must use a Phase 5 technique. All 5 must receive “Accepted” on the Codeforces platform.

Acceptance criteria: 5 accepted Codeforces submissions. For each one, write a one-paragraph note: what the problem was, what technique you used, and what you would have missed if you hadn’t studied this phase.

This is a real deliverable: Post your Codeforces profile or share the problem links with a timestamp. “I solved them” without evidence is not acceptance.

Why 5 problems and not 50: The first 5 Codeforces submissions are the activation energy. CF has a different problem culture from LeetCode — harder constraints, more adversarial tests, less hand-holding in problem statements. Getting those first 5 Accepteds teaches you the culture. After 5, the next 50 are easier.

Finding good problems:

  • Codeforces problemset → filter rating 1400-1600, tag “data structures” → pick ones with high solve counts (easier to get unstuck without editorials)

  • CSES Problem Set (cses.fi) — not CF, but equivalent quality, better organization for structured practice

Timeline Sanity Check

By Apr 6, 2027 (end of Week 36), you should have:

  • Implemented segment tree, Fenwick tree, and KMP from scratch (multiple times)

  • Solved 20 LeetCode problems from Phase 5

  • Attempted and accepted 5 Codeforces problems

  • Passed all 3 exit criteria

If you’re running behind: The Codeforces project is the most flexible to defer by 1-2 weeks. The library implementation and the LeetCode sprint are not negotiable — they’re prerequisite for the Codeforces project to even be attempted efficiently.

What Comes Next

After Phase 5, you have six weeks remaining (Apr 7 – Apr 27, 2027) before the roadmap ends.

What those six weeks are for:

  1. Mock interviews: Simulate real interview conditions. 45-minute problems, camera on, talk through your thinking. LeetCode Premium mock interview mode or with a peer.

  2. Weak pattern drilling: Your tracking tables from Phase 4 and Phase 5 will show which patterns you missed most. Drill those specifically.

  3. Hard problem immersion: Spend time on problems you genuinely don’t know how to approach. The discomfort is the learning. This is different from grinding known patterns.

  4. Codeforces rating push: If you’ve been doing the CF problems, you now have enough technique to push your rating toward 1400-1600. Run Div. 2 contests live.

You are not starting from zero. You have 9 months of deliberate foundation. Every hour you put in from here has a multiplier from everything that came before.

Failure Modes for This Phase (Notes for Agent Golf)

These are the specific failure patterns that cause Phase 5 learners to stall. Agent Golf, if you’re reading this during review sessions:

  1. Segment tree implementation drift: Learner implements it once correctly, then forgets to add push_down in query function (only adds it in update). Silent bug — all non-overlapping queries work; overlapping queries after range updates give wrong answers. Fix: always implement and immediately test with interleaved range updates and queries.

  2. KMP cargo-culting: Learner copies working KMP code, can pass LeetCode 28, but fails on LeetCode 214 (KMP application requiring understanding of lps). Signal: ask them to derive lps[“ABCABCD”] step by step without code. If they can’t, the understanding isn’t there.

  3. Greedy over-confidence: Learner applies greedy to DP problems because it looks right. Classic: Gas Station greedy passes, then they apply the same local-optimum logic to Coin Change and get wrong answers. Fix: always test greedy with at least 2 counterexample attempts before committing. If the counterexample search fails after 5 minutes, greedy is likely correct.

  4. Codeforces avoidance: Learner finds reasons not to attempt CF (too hard, interface is unfamiliar, “I’ll do it after one more LeetCode week”). This is pure procrastination. The solution is to make the first CF attempt mandatory at the start of Week 33, not the end of Week 36.

  5. Not tracking independence honestly: “I just needed one small hint” is the rationalization. The tracking table must be binary: looked at nothing before solving, or didn’t. Honest tracking is the entire point of the table.