Daily_CF_Problems is a daily Codeforces practice repository

Two problems a day, with a hint and an editorial

Daily_CF_Problems is a repository for practising competitive programming skills by solving daily Codeforces problems, and the main activities section sets out the routine precisely. Every day except Sunday, two Codeforces problems of different difficulty are updated in a dated file, and at least one of the two problems receives a solution. The two problems for a given day live at daily_problems/${YYYY}/${MM}/${MMDD}/problems.md, with hints included in that file, and the solutions live alongside in a solution/ subdirectory named after the problem code, for example solution/${problem_code}.md. The repository is a working site as well, hosted at yawn-sean.github.io/Daily_CF_Problems/, and the README's table of today's problems links out to the Codeforces gym pages and to the editorial files in the repository. The current listing shows two problems at difficulty 1700, one described as a shortest path problem and the other as an iterate over exercise, which is a fair sample of the range: both are hard enough to need thought and neither is a warm-up.

The directory layout does the organising

The structure is the specification, and there are only three directories at the top level, daily_problems/, categories/ and SheepCup/. Inside daily_problems/ the path encodes the date, so a specific day's problems and solutions are found by date alone, and that structure is what makes a repository of this kind navigable at all. A reader who wants to revisit what they solved in March opens the March folder. A reader who wants the editorial for a specific problem goes through the solution file named after the problem code. The categories/ directory holds a file per method, with the problems organised by the methods their solutions used, which is the second axis of the collection. The SheepCup/ directory is present at the top level but is not described in the README, so what it contains cannot be determined from the documentation available here, and that is worth noting if you are assessing the repository's coverage. The stats page linked from the README tracks the current submission statistics, which is how the project shows participation.

Submitting a solution is a naming convention

Contributing is simple to describe, and the convention is the part that matters. Your solution goes in the personal_submission folder for the relevant day, that is daily_problems/${YYYY}/${MM}/${MMDD}/personal_submission, and the code file has to be named ${problem_code}_${your_name}.{py/cpp/...}, with the extension matching the language you wrote it in. The pull request title follows the same pattern of being machine readable, ${YYYYMMDD} ${INFO}, which means the history of the repository is a dated log of contributions rather than a list of opaque commit messages. Those two rules do more work than they look. A predictable filename means a script can find every submission for a given problem, which is what makes a leaderboard and a participation count possible at all, and a date first in the pull request title means the commit history sorts into the same shape as the directory tree. A repository that is mostly one file per problem has no way to be indexed without conventions, and these are the conventions.

The category index is built after the fact, not before

The categorisation scheme is the part of the design that deserves a second look. Problems are grouped by the methods their solutions use, and the file is categories/${method}.md. The ordering implied by that wording is that a problem lands in a method category once someone has written a solution for it and that solution has used that method. In other words, the taxonomy is derived from the solutions rather than imposed on the problems up front. That has a clear advantage, since the categories reflect techniques that genuinely worked rather than a guess made before anyone tried, and it avoids the problem of assigning a problem to a topic it does not really belong to. It also has a consequence for anyone browsing the categories, since the index of what is covered by a given method grows only as people solve problems, so a method with no solutions has no file and no problems. The selection of daily problems is described in terms of difficulty differing between the two, not topic, so the daily set is not themed and the topical coverage comes from the category files over time.

What this is, and what it is not

The value of the repository is a routine rather than a syllabus. For a competitive programmer who wants a daily problem with a hint if they get stuck and an editorial if they do not, and who would like their solutions to be read by someone else, this is a ready made structure that asks only that you follow a file naming convention. It is not a teaching resource in the sense of a course, since the problems are chosen for difficulty difference rather than to build a topic, and it is not a dataset, since the archive is organised for human browsing by date and by method. The hosted site with its statistics page is what makes it feel like a community project rather than a personal folder, and the daily update of problems and solutions is the activity that keeps it alive. The repository is not archived, the last push was on 2026-10-20, and there are no GitHub releases, so the content is the product and the commit history is the changelog. The primary language is C++, though the submission convention explicitly allows py and other extensions, so the solutions in the tree are not all in one language.

Editorial conclusion

Adopt Daily_CF_Problems if you want a daily competitive programming routine with hints available and a public place to publish your own solutions, and if you are comfortable working in a Markdown-only repository. Do not adopt it as a curriculum, since the problem selection is not themed or sequenced by topic, only categorised afterwards by the method a solution used. Verify first that the daily cadence suits you, since nothing is published on Sunday, and that the categories directory reflects the methods you want to drill, because a problem is filed under a method only once a solution for it exists.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Yawn-Sean/Daily_CF_Problems on GitHub