Milestone map
Milestone map
3 milestones
Implement Sorting Algorithms and Core Data Structures
8–14 weeks
Implement from scratch without standard library implementations: merge sort, quicksort (median-of-three pivot), heap sort, binary search tree (insert, delete, in-order traversal), and a hash table with chaining. Write a test harness with at least ten test cases per data structure, including edge cases.
Proof required
Submit: a public GitHub repository containing all five implementations with a test harness showing correctness on at least ten cases per data structure (including empty input, single-element, sorted, and reverse-sorted); a performance benchmark comparing merge sort, quicksort, and heap sort on 1,000 / 10,000 / 100,000 random integers; and a 150-word explanation of the performance results. A CS lecturer or senior engineer must confirm the implementations are correct.
What gets checked
- All five implementations are from scratch — no standard library sort or hash map used for the core algorithm
- Test harness includes edge cases — empty input, single-element, sorted, and reverse-sorted
- A CS lecturer or senior engineer has confirmed the implementations are correct
Common mistakes
- Using language built-ins (Python sorted(), Java Collections.sort()) — the proof requires implementing the algorithm, not calling it
- Test harness that only tests the happy path — edge cases are where sorting bugs hide
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Are all implementations from scratch — no standard library algorithms used?
- Does the test harness include edge cases — empty input, single-element, sorted, reverse-sorted?
- Do benchmark results match expected complexity — merge sort and heap sort stable O(n log n), quicksort average O(n log n)?
You'll sign in first, then come straight back here.
Implement Graph Algorithms and Dynamic Programming
8–14 weeks (after milestone 1)
Implement from scratch: BFS and DFS (with cycle detection), Dijkstra's shortest path, Bellman-Ford (with negative cycle detection), Prim's MST, and at least three dynamic programming solutions — one 1D DP (coin change or Fibonacci with memoisation), one 2D DP (longest common subsequence or edit distance), and one DP-on-graphs problem.
Proof required
Submit: a public GitHub repository containing all graph algorithms and DP solutions with a test harness covering at least eight cases per algorithm (including cycles, disconnected graphs, and negative edges where applicable); and a 200-word explanation of why Bellman-Ford is necessary when Dijkstra fails, with a concrete counterexample. A CS lecturer or senior engineer must confirm the implementations are correct.
What gets checked
- All graph algorithms are from scratch — no standard library graph libraries used
- Test harness includes adversarial cases — disconnected graphs, negative cycles, and single-node graphs
- Bellman-Ford explanation includes a concrete counterexample showing Dijkstra's failure with negative edges
Common mistakes
- DP solutions that use recursion without memoisation — the proof requires DP, not brute-force recursion
- Graph test harness that only tests connected graphs without negative edges
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Are all implementations from scratch — no graph library utilities used?
- Does the test harness include disconnected graphs, negative cycles, and single-node cases?
- Does the Bellman-Ford explanation include a concrete counterexample for Dijkstra with negative edges?
You'll sign in first, then come straight back here.
Present Portfolio and Solve a Novel Algorithmic Problem Live
2–4 weeks to prepare and schedule (after milestone 2)
Present your full algorithm implementation portfolio to a CS lecturer or senior engineer in a live technical review. The reviewer will pose a novel algorithmic problem not in your portfolio, and you must sketch a solution and analyse its complexity in real time.
Proof required
Submit: a recording or transcript of the live technical review with a CS lecturer or senior engineer; the portfolio repository as the basis for the review; and documentation of the novel problem posed, your on-the-spot solution sketch, and the reviewer's assessment.
What gets checked
- Review was live — not a written submission with async response
- A novel problem was posed that was not in the portfolio
- Reviewer's assessment of the on-the-spot solution is documented — even if partially correct
Common mistakes
- Live review that becomes a portfolio walkthrough without a novel problem being posed
- Novel problem that is identical to one in the portfolio — must be genuinely new
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Was the review live — not async?
- Was the novel problem genuinely not in the portfolio?
- Is the reviewer's assessment of the on-the-spot solution documented?
You'll sign in first, then come straight back here.