Competitive Programming Training Tracker for University Clubs and ICPC Coaches

The problem: clubs train with spreadsheets

Many universities have a competitive programming club or an ICPC coach who trains students for regional contests. In Pakistan, India and Bangladesh these clubs can be large: dozens of members practising on Codeforces, AtCoder and CSES, and a few teams of three chosen each season. The coach wants to know who is practising, who is stuck, which topics each member is weak in and which trio should form a team. Today that usually means a shared spreadsheet that members forget to update, and screenshots of profiles.

The data already exists. Codeforces publishes a public API that returns a user's submissions (user.status), rating history (user.rating) and the problem set with tags and ratings (problemset.problems). What is missing is a tool that turns that raw data into training signals a coach and a member can act on.

What already exists and the gap

• Codeforces itself shows each user's profile, rating graph and submissions, and lets clubs create groups and Gym mashups (custom contests from existing problems).
• CLIST aggregates contests and ratings from many judges into one calendar and unified profiles.
• Virtual Judge (vjudge) lets you run contests with problems from several judges.
• CSES for Teachers lets teachers create courses on the CSES judge and track students' progress there.
• USACO Guide tracks progress through its own modules.

Each covers a slice: one judge, one contest, or one course. None gives a university coach a club-level view of upsolving backlogs, topic coverage across the club, assigned practice and team practice results with ICPC scoring. That combination is the gap, and it is a real one for any coach running a club.

Inspiration

The habits this tool supports come straight from how strong contestants train: take part regularly, upsolve the problem just above your level after every contest, practise weak topics about 100 to 200 rating points above your current rating, and, for ICPC, play full five-hour team contests and review them. The USACO Guide's pages on practising and contest strategy and the ICPC's published scoring rules (20 penalty minutes per rejected run on a solved problem) are good references for the features.

What you build

• Members: link a Codeforces handle, see their own rating trend, upsolving backlog and topic coverage, and complete practice sets.
• Coaches: invite members, assign practice sets by tag and rating range, record team practice contests, and see the whole club at a glance.
• Teams: a page per team of three with combined topic coverage and a log of practice contests with ICPC-style scoring and review notes.

The technically interesting part

• Syncing politely. The Codeforces API limits how often you may call it. Design a scheduler that syncs members incrementally (only new submissions since the last sync), queues requests, backs off on errors and never hammers the API. Document the design.
• Turning submissions into signals. A submission list is noisy: many attempts, many verdicts. Derive "solved", "attempted but unsolved", "solved in contest" and "upsolved later" per problem, and compute a backlog from rounds the member took part in.
• Topic coverage. Problems carry tags and ratings. Build a coverage matrix per member (tags by rating band) and decide how to show it so a coach can read it in seconds.
• ICPC scoring. Implement team contest scoring exactly as the rules describe, including that compilation errors carry no penalty, and test it.
• Data model. Members, handles, submissions, problems, tags, practice sets, teams and contests, with indexes for the dashboard queries.

How to evaluate it

• Correctness: unit tests for backlog derivation and ICPC scoring against hand-computed examples.
• Sync: time to sync a club of 50 members from scratch and incrementally, and the number of API calls used.
• Usefulness: run it with a real club for three to four weeks. Survey the coach and members: did they upsolve more, and did the coach change any team or practice decision because of it?
• Performance: dashboard load time for a club of 100 members with a year of history.

Suggested plan

• Weeks 1 to 2: interview a coach and a few members, list the questions the dashboard must answer, design the data model.
• Weeks 3 to 5: accounts, clubs, handle linking and the sync job with rate limiting.
• Weeks 6 to 8: backlog, topic coverage and member dashboards.
• Weeks 9 to 11: practice sets, team pages and ICPC contest scoring.
• Weeks 12 to 15: a pilot with a real club, fixes, evaluation and report.

Path to a product

Every university with an ICPC coach has this problem, and so do schools training for informatics olympiads and coaching centres that teach algorithms. A hosted version with a free tier for small clubs and a paid tier for institutions with several coaches is a realistic model, as is offering it free to build a community and a portfolio. Integrations must stay within each platform's API terms. A pilot with a real club and measured results is also a strong portfolio piece.

Scope warning

Do not build an online judge, run untrusted code or scrape any site. Use only official APIs and exports. One judge (Codeforces) done well is the core scope; other platforms are stretch goals only where they offer an official API.

Discuss it and get help

• Want feedback on this idea for your own FYP? Discuss it at /account/fyp-ideas/competitive-programming-training-tracker-for-university-clubs/.
• Stuck on the design or the scope? Ask a question or book a session.
• New to Sefism? Create a free account to save ideas and follow roadmaps.

Learn what you need on Sefism

• Competitive programming roadmap: the training habits this tool supports, from upsolving to ICPC team play.
• Competitive programming cheat sheet: verdicts, ratings, topics by rating band and ICPC scoring.
• Codeforces: the platform whose public API powers the tracker.
• ICPC: the official rules on team composition and scoring.
• CSES Problem Set: a topic checklist you could map practice sets onto.