You write a standard solution, just like on LeetCode, and run it through the CLI. It identifies the problem by ID or title, executes your code against local test cases, and shows the result. It currently supports around 1.4k problems and multiple languages, including Python, C++, Rust, Java, Go, TypeScript, Swift, and others. The project is still an MVP. System design, SQL, and concurrency problems are not supported yet, but support for more problem types is planned. Made in Haskell! |
One nice thing is the LLM can “reason” about my weak areas and tailor the drills it generates next to keep me on a productive path.
I personally don’t get much value from pulling in 1,400 arbitrary problems but this is cool for people who want to hit the ground running.
> It currently supports around 1.4k problems and multiple languages, including Python, C++, Rust, Java, Go, TypeScript, Swift, and others.
It would be interesting to have a variant where you get the input data through stdin or a file on disk, and verify by writing to stdout. That way you could bring your own language
- you could simply spawn a docker container for each programming language and run user submitted code inside no?
There are already projects that can submit your solutions through the LeetCode API and return the results. But I don't really like that approach, so I decided to build an open set of tests that aims to match the quality of LeetCode's tests as closely as possible. This way, you can run everything locally, without needing for example, an internet connection.
I see the project being useful for its most straightforward purpose: testing your solutions locally on your own hardware, without any submission delays and even completely offline. Since the tests are open, people can also build different tools around them. For example vim extensions and other integrations. Ofc it's not that simple, we currently support about 1400 problems (out of 4000~, including premium), and not all topics are covered.
As for test cases, there are occasionally solutions that are technically incorrect but still pass because a particular edge case isn't covered. We maintain our own test cases, including a DSL for writing large stress tests, and try to cover all possible cases.
In the worst case, a solution might pass our local tests but fail on LeetCode. I expect such cases to be rare and one of the benefits of having the tests open is that when someone finds a missing case, it can be added so nobody else runs into the same issue.