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)?
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?
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?