A personal competitive programming archive, with a to-do list attached

One person's preparation, published as it happened

The README opens with the reason the repository exists, and it is more specific than a generic learning claim. It contains a set of learning resources and coding challenge solutions implemented as a result of the author's training, in order to pass a Microsoft interview that led to an offer for a software engineering internship and a full time role. That framing tells you what kind of artefact this is. It is a training log that happens to be useful to other people, not a course designed for them.

The technologies are listed as three badges, C++, Python and Java, with the repository's primary language being C++. That mixture is the reality of interview practice, where the platform you are preparing for decides the language, and the folder structure follows the platforms rather than the languages. The solutions are therefore a cross-section of one person's habits: the same author, the same conventions and the same explanations, applied across many different problem sets and difficulty levels.

The author also links a personal site, a LinkedIn profile, a mentoring profile on MentorCruise, a PayPal link and a Buy Me a Coffee button. Those are personal, promotional surfaces rather than project infrastructure, and they are worth noting because they tell you how the project is sustained. There is no company behind this repository, no funded team and no support commitment, and the funding model is donations and mentoring work.

That is not a criticism, it is a description of the shape. A repository maintained by one person in the course of their own preparation will have gaps, will have uneven coverage, and will change when that person has other things to do. The last push was on 2026-07-21, and the repository is not archived.

The folder map is a map of platforms, not of topics

The structure of the repository is documented as a table, and it is worth reading the table rather than the prose, because the table is the actual content index.

The solution folders are named after where the problems came from: geeksforgeeks, HackerRank, codingblock, codesignal, codechef, UVA, interviewbit, leetcode, and in the top level listing also codebyte, codeforce, hackerearth and spoj. Most have their own README that links to the solutions inside. The naming is inconsistent in case and separator, which is a small sign of a repository grown over years rather than designed in one sitting.

The study notes sit alongside them, and this is the part with a longer shelf life. Lectures holds notes about algorithms and data structures, MUST_KNOW_ALGORITHMS.md is a checklist of algorithms to know, system-design holds interview preparation notes for system design, Reading holds free e-books about competitive programming, and books is another reading collection. There is also learn_data_structures with warm up coding examples, must-do-exercises, design-pattern, a python_tricks.md file, and algorithm and tryexponent directories.

Two entries in the top level listing are worth flagging: an AI directory and an agents-training directory, which sit oddly next to a competitive programming archive. They suggest a personal knowledge base that has grown past its original scope.

For a reader, the practical consequence is that there is no single path through it. The table gives you a directory of resources, not a syllabus, and the notes and the solutions are not cross-referenced in a way that would tell you which technique each problem was testing.

The fifty item checklist is a backlog, not a table of contents

The last long section of the README is a numbered list under the heading Incoming Materials, fifty entries long, and it is the most revealing document in the repository. It runs from Prefix Sum, Sliding Window Technique and Binary search through GCD of two numbers in LogN, Sieve of Eratosthenes and Segmented Sieve, modular arithmetic, bit manipulation, greedy algorithms, two pointers and Kadane's algorithm, through recursion, divide and conquer, the next greater or smaller element using a stack, parenthesis problems and backtracking, into constructive algorithms and heap problems, then inclusion-exclusion, nCr and nPr for queries, Rabin Karp, prefix function, KMP, Z-function and Manacher's algorithm. From there it moves to graph and tree work, DFS and BFS traversal, diameter of a tree, Euler tour, LCA by Euler tour and by binary lifting, distance between two nodes, subtree problems, connected components, topological sort, cycle detection and bipartite checks, then the shortest path family, Dijkstra, Bellman-Ford, Floyd Warshall, bridges in a graph, Prim's algorithm and 0/1 BFS. The tail is the advanced half: dynamic programming including bitmask and tree DP, disjoint set, Kruskal, Fenwick trees with binary lifting on Fenwick, matrix exponentiation, square root exponentiation, segment trees, lazy propagation, the Sprague-Grundy theorem, heavy light decomposition, and FFT and NTT.

That is a very good survey of what competitive programming actually asks, and it is a good picture of the gap between what the repository holds and what it aims to hold. The heading says incoming, which means this is a backlog of notes still to be written rather than an index of notes that already exist.

It is also a useful artefact on its own. For someone planning their own preparation, the list is a curriculum someone else wrote, ordered by increasing difficulty, with the standard vocabulary in it. That the repository's own author has not yet written all of it is a fair signal of the scale of the task, and it is a reminder that a fifty item algorithm syllabus is a multi-year project rather than a weekend read.

The contribution rules are really a code review policy

Most repositories of solutions have a contribution section that is a formality. This one states conditions, and the conditions are unusually specific about what a reviewer will accept.

The rules for when to contribute are: if there is no solution to a problem in the main branch; if your solution is asymptotically faster than the one in the main branch; if your algorithm has the same time complexity but with reduced code size, in which case you comment out the original solution and open the pull request with yours; if you have another method of solving the problem which is asymptotically slower than the original, in which case you comment your solution in the main file; and if you would like to make any positive change to the lectures content.

Read as a whole, that is a policy about preserving a record of approaches. A faster solution replaces the old one, a slower alternative is kept beside it in comments, and the file accumulates the history of how a problem can be solved. It is a convention you will find in some algorithm repositories, and it has a cost: the files grow, and a reader has to work out which block of code is the live solution.

The mechanics are the ordinary GitHub ones, fork, make the change, open a pull request. There is a CONTRIBUTING.md and a CODE_OF_CONDUCT.md at the root, and a .github directory for the templates and workflows.

The contribution rules are also the clearest statement of what this repository values. It is not a library with an API, so there is no compatibility question; the only quality dimensions that matter are speed, size and coverage, and those are what a reviewer is asked to judge.

What you cannot get from it, and what to use instead

The most important limitation is that these are solutions without problems. A repository of solution files is a set of answers, and the questions live on the platforms. The README itself links to the author's profiles on HackerRank, InterviewBit, GeeksForGeeks, LeetCode, Codingblocks, CodeSignal, CodeChef, CodeForces and HackerEarth rather than hosting the statements, and every problem in the tree is keyed to a platform problem you have to find separately.

That matters for two different readers. For someone revising, the missing half is the reasoning. There is no editorial, no proof, and in most cases no explanation beyond a comment in the code, so a solution you do not immediately understand tells you the shape of the approach without telling you why it is correct or why it is the right complexity. For someone learning, the missing half is the test data: a solution in the tree has no accompanying cases, so nothing here can be run against a judge or used as a regression check.

The second limitation is coverage consistency. The list of fifty topics in the backlog is the honest measure of what is not there yet, and the platform folders vary in depth because they grew as the author practised. A reader who assumes a folder is comprehensive will be disappointed by a specific platform.

The third is that none of it is maintained as a product. There are no GitHub releases, no test suite, no continuous integration in the visible tree and no versioning, so a solution that compiled against one judge setup may not compile against another, and nothing in the repository checks that the code still builds.

What to use instead depends on the goal. For judged practice with feedback, the platforms themselves are the tool, and they come with editorials and test data. For a structured approach to a specific problem type, the notes in Lectures and the MUST_KNOW_ALGORITHMS.md checklist fill that role better than the solution tree does. For system design, the system-design folder is the one to read, since none of the platform solutions touch that area. And for a working implementation with tests, nothing here is a substitute.

Licence, maintenance and the mixed language reality

The licence is Apache-2.0, with a LICENSE file at the repository root and a CODE_OF_CONDUCT.md beside it. Apache-2.0 is a permissive licence with an explicit patent grant, so the solutions can be reused in your own code or in commercial work provided the notice and the licence text travel with them. This describes the published terms rather than legal advice.

There are no GitHub releases attached to the repository, so there is no version to pin and no changelog of solutions being corrected. The repository is not archived and the last push was on 2026-07-21, which is a healthy sign of a personal knowledge base that is still being worked in.

The mixed language picture deserves a note, because the primary language listed for the repository is C++ while the README also advertises Python and Java. In practice, a solution's language follows the platform and the problem, and the same problem may appear in more than one folder in more than one language. The practical guidance is to check the file you are about to copy rather than to assume, and to expect that some of it is in a language you do not use at all.

The most useful thing to take from the repository is the shape of it. One person, a clear list of what still needs writing, a contribution policy that keeps slower approaches visible next to faster ones, and a collection of notes that are more reusable than the solutions are. That is a reasonable model for a personal study archive, and it is a reasonable thing to fork if you want the same thing for your own preparation.

Editorial conclusion

Adopt this repository as a reference shelf and a source of worked examples, and as a place to see how one author structures a solution set, not as a curriculum and not as a test suite. It is the wrong tool if you need judged problems with test cases, if you need explanations of why an approach is correct, or if you need anything maintained and versioned, because there are no releases and no CI. Before relying on any of it, check the language of the solution you are about to copy, since the repository mixes C++, Python and Java under platform-named folders, and treat the fifty item checklist as the author's own backlog rather than as a syllabus you have covered.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. omonimus1/competitive-programming on GitHub
4. Project website
5. README