projecthackathonjudgingconstraint-satisfactionhackprincetonreactnextjsfirebaseassignment-algorithmUpdated 2026-07-01

Podium

A judging coordinator for large hackathons that assigns dozens of judges to hundreds of projects across floors, balancing fairness, coverage, and judge travel as a constraint-satisfaction problem.

Podium solves the logistics of judging at scale (built for HackPrinceton): fair distribution, physical efficiency, and judging variety. Every automated assignment navigates a hierarchy of needs that protects the integrity of the event. Source: podium README, 2026-05-31

In Kevin's project graph, Podium belongs with the HackPrinceton website family rather than as an isolated hackathon tool: HackPrinceton landing/demo sites handle the event surface, while Podium handles the judging control plane. Source: User request, 2026-06-25; raw/github/kevin-repos-2026-06-25.json

The priority framework

Assignment is modeled as constraint satisfaction over three tiers:

  1. Necessities (hard constraints) - a judge is never assigned a team they already scored; no judge sits idle while valid teams remain on their floor; judges only get teams within their physical floor/sector.
  2. Strong wants (optimization targets) - even distribution (prioritize teams with the fewest completed scores so all projects reach the review threshold together), anti-clustering (minimize judges scoring the same team simultaneously), and judging variety ("Hammad's Rule" - prevent "fuzzy duplicate" blocks). Source: podium README, 2026-05-31; rule attributed to People Network Ledger
  3. Weak wants (convenience) - physical proximity as a tie-breaker (sequential team numbers minimize judge travel).

The algorithm: multi-pass relaxation & randomized spread

The auto-generator finds the optimal 5-team block for a judge:

  • Phase 1 - historical memory & fuzzy matching. Build a signature map of existing assignments; discard any candidate 5-team block sharing ≥4 teams with an existing block (the "too similar" rule).
  • Phase 2 - shuffled window search. Rather than scanning teams linearly (which produces the "top-heavy" bug where early projects get all judges), shuffle all 5-team indices with Fisher-Yates so judges probe different sections of the floor and coverage spreads naturally.
  • Phase 3 - scoring. Cost = (PressureScore × 1000) + ClosenessPenalty, where pressure is the total existing reviews in a block and the ×1000 weight makes even distribution the primary driver while proximity is only a tie-breaker.
  • Phase 4 - constraint relaxation. If the strict pass finds no dissimilar block but the judge still has teams to see, Pass 2 drops Hammad's Rule to uphold "zero idle time."

Source: podium README, 2026-05-31

Operator tooling and stack

A Team Status Matrix renders each project as a dot on an orange heatmap (0→3+ reviews) with a cyan "active pulse" when a team is being judged; a Judge Status Dashboard tracks Busy / Assignable / Finished (judges with <5 teams left are proactively flagged Finished). Team setup supports manual, bulk-generate, and smart import, plus overwrite/merge that updates names or moves teams between floors without losing scores. Stack: React + Next.js App Router, Tailwind ("Sophisticated Dark"), Framer Motion, and Firebase Firestore with real-time listeners so all coordinator devices stay in sync. Source: podium README, 2026-05-31

Why it matters

Podium is a concrete example of Kevin designing an operational system around ranked constraints. The product is not "assign judges." The product is keeping a live event fair while coordinators are under time pressure and the physical venue has real geometry. The hierarchy matters:

  • hard constraints preserve judging integrity
  • optimization targets improve fairness and spread
  • weak wants make the system pleasant without overruling correctness
  • relaxation keeps the floor moving when ideals conflict

That structure generalizes to agent systems. Many agent workflows need the same explicit ordering: what must never break, what should be optimized, and what can be relaxed when the room is moving. Source: podium README, 2026-06-18

Cleanup note

The local README still contains residual Create T3 App scaffold documentation after the Podium-specific sections. Treat the Podium-specific README content as authoritative for this project page; the scaffold tail is not project signal. Source: podium README, 2026-06-18

Current Evidence (2026-07-01)

This page was refreshed against Kevin's live GitHub inventory, pinned repositories, PortfolioMon cards, README scrape, and downloaded portfolio screenshots. Treat this section as the current evidence anchor; deeper interpretation stays in the surrounding compiled truth.

PortfolioMon card Types Site Screenshot
#007 Podium Web/Data site Podium
  • PortfolioMon card #007; Web/Data; HP 290, ATK 115, DEF 100, SPD 110; standard card. Full-stack hackathon judging and event management platform built for HackPrinceton. Real-time leaderboards, judge assignment, spam prevention, score aggregation, and live results.
GitHub repo Visibility Language Stars Last push Homepage
Kevin-Liu-01/Podium public TypeScript 5 2026-06-16 site

Timeline

Related Pages

HackPrincetonPeople Network LedgerProject Inventory Ledger

10 pages link here

Career GoalsUSERCareer ProfileCareerHackPrincetonProjectsKevin LiuPeopleOMMC - Online Monmouth Math CompetitionProjectsPrinceton ContextUSERProject Inventory LedgerProjectsProject PortfolioUSERStrengthsUSERUser ProfileUSER