Research
Jun 23, 2026AlgoArena8 min read

Auditing the Arena 90 Campaign Path

How the 90-node campaign was pinned to existing problems, test-count coverage, topic balance, and a stable curriculum contract.

Research figure

Auditing the Arena 90 Campaign Path

90
Pinned nodes
16,815
Test cases
100
Min/node

The campaign is a curated path over real AlgoArena problems: 90 pinned nodes, 16,815 total test cases, and no node below 100 cases.

Topic coveragenodes by bucket
Strings / tries12 nodes
Arrays13 nodes
Graphs9 nodes
Trees9 nodes
Campaign audit grid9 x 10
W1
W2
W3
W4
W5
W6
W7
W8
W9

Each dot is a pinned problem ID with a stored test-count snapshot. The public claim is coverage and stability, not a hidden curriculum model.

Pinned nodes: 90 (existing problem IDs, one per campaign node) | Test cases: 16,815 (static audit total across the pinned path) | Min/node: 100 (no tiny-test nodes in the campaign set)

Arena 90 is not meant to be a prettier problem list. It is a campaign: a paced path through the patterns a learner is likely to see in interviews and contests.


That means two things have to be true at once. The nodes must be real practice work, not invented map decoration. And the map has to feel authored, not like a spreadsheet dropped over fantasy art.


What shipped


The campaign currently pins 90 existing AlgoArena problem IDs in lib/study-plans.ts. Each node carries a static title, track, difficulty, and test-count snapshot so the campaign can be audited without depending on live Firestore reads.


That distinction is important. A generated query can make a page feel full, but it cannot promise that a learner's path is stable. A pinned campaign can be reviewed like a product surface: the team can inspect which concept appears at node 14, which problem backs node 57, and whether the total testing surface is large enough for medals to mean something.


The pinned path covers 14 topic buckets:


  • arrays
  • stacks and queues
  • binary search
  • linked lists
  • greedy and intervals
  • heaps and priority queues
  • bit manipulation
  • math and number theory
  • graphs
  • DSU
  • 1D dynamic programming
  • 2D dynamic programming
  • trees
  • strings and tries

  • The public audit numbers are intentionally simple: 90 nodes, 16,815 total test cases, an average of about 187 tests per node, and a minimum of 100 tests on every node. That last number matters because campaign medals should not hinge on a tiny hand-written sample.


    The topic distribution is intentionally uneven. Arrays and strings appear more often because they are early and recurring interview patterns. Graphs, trees, and dynamic programming occupy fewer nodes but carry higher conceptual load. The audit is not trying to prove a universal curriculum; it is making the current editorial shape visible enough to debate.


    Why pin instead of query


    The practice library is large and keeps improving. A campaign path should not drift every time the underlying catalog changes order. Pinning keeps the promise stable: node 27 should mean the same challenge tomorrow that it meant today.


    The pinned layer also gives the map a testable contract. If a future swap lowers coverage, duplicates a theme, or points at a stale problem, the audit surface can catch it.


    That stability matters for screenshots, support, analytics, and pedagogy. If a teacher tells a student to retry node 33, both people need to mean the same exercise. If a user says a boss node feels too easy, the team needs to know which problem they played. If a future product note says Arena 90 improved coverage, the old and new paths need comparable baselines.


    The alternative is a campaign that changes silently. That can look fresh in the short term, but it makes progress harder to trust. A campaign should be authored, not sampled.


    Medal model


    Arena 90 medals reward partial progress:


  • one medal for passing any test case
  • two medals for passing at least half
  • three medals for passing every case

  • That model is deliberately different from an all-or-nothing solved badge. A learner who gets 80 of 180 cases has useful evidence: they understood part of the invariant and still have a specific gap to close.


    Medals also avoid a common problem in beginner practice: a failed submission collapses too much information into zero. The partial-credit model lets the UI distinguish "the solution does not compile" from "the invariant works for half the generated cases but fails edge coverage." That is a better learning signal and a better progression signal.


    Route contract


    The route layer has to serve both product and visual design. Product needs prerequisites, unlocks, current-node focus, medals, and accessible labels. Art direction needs a map whose roads and landmarks are planned around the campaign's actual route.


    This research note does not publish a map asset as evidence. The evidence is the route contract: the 90 nodes are pinned, each node has a known problem and coverage snapshot, and the UI layer has a stable coordinate system for interaction. A stronger illustrated map can be built on top of that contract, but it should not be used to hide curriculum gaps.


    What the figure shows


    The figure on this page is deliberately plain. It shows topic balance and the 9-by-10 campaign grid because those are the parts of the system a reader can audit. Decorative map art would make the page look more exciting while saying less about whether the campaign is valid.


    For a research page, the right artifact is the one that lets a reviewer ask better questions: Are early nodes over-weighted toward arrays? Are graphs introduced late enough? Are boss nodes backed by enough tests? Which buckets should change before the next version?


    What this audit does not claim


    The audit does not claim the 90 problems are the final perfect curriculum. It does not claim that test count alone measures problem quality. It does not claim that the map art is finished.


    It claims the current campaign is public, complete enough to explain, and traceable to shipped data. Future swaps should preserve the same bar: real problem IDs, visible coverage, stable route placement, and a reason for each editorial change.


    Source trail

    lib/study-plans.ts
    app/practice/study/[slug]/page.tsx

    Related notes

    View all