# leetcode_problem_rating rates contest problems with Elo and MLE > This project publishes a self-calculated difficulty rating for LeetCode weekly and biweekly contest problems, computed from an Elo rating system plus maximum likelihood estimation and delivered as a Vue frontend on GitHub Pages. The backend that does the crawling is deliberately closed source. **zerotrac/leetcode_problem_rating** — Self-calculated rating of problems in leetcode weekly/biweekly contests. - Repository: https://github.com/zerotrac/leetcode_problem_rating - Stars: 700 · Forks: 66 - Language: Vue - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/zerotrac-leetcode-problem-rating ## A rating for contest problems that is calculated, not voted LeetCode already shows a difficulty rating for every problem, but that number is a community signal, aggregated from votes and from how many people solved it. This project takes a different route and publishes what it calls a self-calculated rating of problems in LeetCode weekly and biweekly contests, based on an Elo rating system as well as maximum likelihood estimation. The stated purpose is narrow and honest. The project says the result is not 100 percent accurate, but sufficient for evaluating the relative difficulty of a problem. That distinction is the one to hold on to. A calculated rating is a model output fitted to contest outcomes, and like any fitted number it is reliable for comparing problems that sit in the same difficulty range and unreliable as an absolute difficulty claim across the whole scale. The audience is people who want to know whether a problem was harder than it looked for the people who solved it, which is a different question from how many people found it hard. ## The data comes from crawlers and the backend stays closed The architecture has an unusual and deliberate split. The documentation states that all the data needed during calculation is obtained by web crawlers, and then gives the reason the backend is not open source: in order not to violate any potential terms and regulations, the backend code will not be opened. The same paragraph notes a second consequence, that the APIs are different among contests, so the result does not contain the problems from the 1st to 62nd weekly contests. Two things follow for anyone planning to use this. The first is that the numbers are not reproducible from the code in the repository, because the part that produces them is not there. The second is that the dataset has a hard lower bound at contest 63, so a historical analysis of early contest difficulty is not possible with this data, and a rating for a modern problem has no same-era comparison from this source. This is a case where the restriction is defensible in spirit, since automated scraping of a commercial site is exactly the kind of thing that needs care, but it leaves you depending on the maintainer's continued operation of that backend. ## The frontend is a Vue app and the raw data ships as a text file What is in the repository is the frontend plus the published data. The project description says it is a frontend project deployed to GitHub Pages, and the repository layout matches: src/, public/, a babel.config.js, a vue.config.js, a tsconfig.json, a package.json, and the data files. The technology choices are visible in the manifest. It is a Vue 3 project using vue-router and vuex for state, element-plus for the interface components, vue-i18n for translations, and axios for HTTP, built with the Vue CLI 5 toolchain and TypeScript around 5.5. The scripts section is short and the build step does something worth noting, because it copies the data files into the output directory alongside the compiled app: ```json "scripts": { "serve": "vue-cli-service serve", "build": "vue-cli-service build && cp data.json ratings.txt LICENSE README.md gen.py ./dist", "lint": "vue-cli-service lint" }, ``` The published artifact therefore carries ratings.txt, the JSON data, the licence and the project description, so a GitHub Pages deployment is self-contained and does not need a server. The raw data itself is the file to look at, since the documentation points to ratings.txt for the raw data sorted in descending order, and says it will be updated every week after the contests. A gen.py script sits in the repository root and is copied into the build output, and a data.json file is present as well, so there are two machine-readable forms of the same information. ## Getting the ratings into your own workflow There is no install step here, and the project does not describe one, because what you consume is a static file rather than a library. The route the documentation gives is the deployed site on GitHub Pages, where the ratings are browsable, and the raw file ratings.txt for the data itself. The repository is MIT licensed, with the licence file at the root and the licence identifier in the package manifest, so you can take the data and build your own tooling on top of it. The one thing to get right is the file format, and the documentation does not spell it out, so the first practical step is to open ratings.txt and look at the first few lines to see how a problem, its contest, its rating and whatever else is recorded are laid out. A weekly update means the file changes, so anything you build should re-fetch rather than vendor a copy, and should record the date it read the file. The related projects listed in the documentation give an idea of how others consumed it. LeetCodeRating is a Chrome extension that displays the problem ratings on the official LeetCode site, and refined-leetcode is another extension that integrates several projects and includes a timer, a blocklist, user rating prediction and problem rating display, with both noted as available only on the LeetCode China site. ## Where a calculated rating stops being the right tool There are clear cases where this number is the wrong instrument. If you are choosing what to study next, the number of people who solved a problem and the community vote it carries tell you something different from a fitted difficulty estimate, and the community signal is arguably better calibrated for that decision because it reflects actual attempts. If you need an absolute difficulty, calibrated against a scale with a known meaning, neither the community vote nor this estimate gives you that, and the honest answer is that difficulty is a property of a solver, not of a problem. If you need history before contest 63, the data simply does not exist here. If you need to reproduce or audit the numbers, you need the backend, and the project is explicit that it will not be released. The realistic use is comparative and local: sort a set of recent contest problems by this rating to see which ones the model considers the hardest, and treat that ordering as a prompt for your own judgement rather than as the answer. ## Conclusion Adopt this project if you want a defensible difficulty number for contest problems rather than the community vote counts, and if you are willing to treat the value as relative rather than absolute. Do not expect a reproducible pipeline, because the crawler and rating backend are closed source and the data covers only contests from the 63rd onward. Before you rely on the ratings, open ratings.txt and check the most recent entries against the contests you care about, and read the note that the result is not fully accurate but is sufficient for evaluating relative difficulty. ## FAQ ### How is the leetcode_problem_rating difficulty number calculated? The corresponding backend calculates the rating of problems in LeetCode weekly and biweekly contests based on an Elo rating system as well as maximum likelihood estimation. The project states the result is not 100 percent accurate but is sufficient for evaluating the relative difficulty of a problem. ### Why is the backend of leetcode_problem_rating not open source? All the data needed during the calculation is obtained by web crawlers, and the project states the backend code will not be opened in order not to violate any potential terms and regulations. The repository contains the Vue frontend and the published data instead. ### Which LeetCode contests are covered by the ratings? The APIs differ among contests, so the result does not contain the problems from the 1st to 62nd weekly contests. The raw data in ratings.txt is sorted in descending order and is updated every week after the contests. ### Where can I get the raw problem rating data? The raw data is in ratings.txt at the root of the repository, sorted in descending order and updated weekly. The project is also deployed to GitHub Pages, and the Vue frontend reads a data.json file that is copied into the build output. ### Can I show the problem ratings on the LeetCode website? Two related Chrome extensions are listed in the project documentation as doing this. LeetCodeRating displays the problem ratings on the official LeetCode site, and refined-leetcode integrates several projects with features like a timer, a blocklist, user ratings prediction and problem ratings display. Both are noted as only available on the LeetCode China site. ## Sources - [Issues](https://github.com/zerotrac/leetcode_problem_rating/issues) - [License: MIT](https://github.com/zerotrac/leetcode_problem_rating/blob/main/LICENSE) - [README](https://github.com/zerotrac/leetcode_problem_rating/blob/main/README.md) - [zerotrac/leetcode_problem_rating on GitHub](https://github.com/zerotrac/leetcode_problem_rating) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zerotrac-leetcode-problem-rating