TL;DR
This repository contains my solutions to MoureDev’s weekly programming challenges throughout 2022. I completed 18 out of over 50 published challenges, each solved in Java with automated tests and a CI pipeline via GitHub Actions.
It is not a “project” in the traditional sense. It is a training ground where I practiced logic, data structures, algorithms, and development discipline in Java.
Why I did it
In 2022 I was learning Java seriously and needed a place to practice consistently and measurably. MoureDev’s weekly challenges gave me exactly that: a new problem every week, with variable difficulty, that forced me to think in pure logic.
The key decision was not “solving challenges.” It was how I solved them:
- Each solution with its corresponding unit test.
- CI with GitHub Actions to validate compilation and tests on every push.
- Code organized per challenge, not a single giant file with everything mixed together.
I wanted the repository to be evidence of habit, not just results.
What kind of challenges are included
The challenges cover a wide range of problems:
- String manipulation: palindromes, anagrams, ciphers, parsing.
- Math and logic: prime numbers, fibonacci, number bases, date operations.
- Data structures: lists, maps, stacks, trees.
- Classic algorithms: search, sorting, recursion.
- Modeling problems: state machines, validators, simulations.
Each challenge has its own Java class with the solution and a corresponding test class.
Technical decisions
Tests as a requirement, not an extra
From the start I decided that no challenge was “done” without its test. That forced me to think about edge cases from the problem statement, not just the happy path.
It may seem like a minor detail, but it changed how I approached every problem: first I thought about possible inputs, then I wrote tests, and only then the solution.
CI with GitHub Actions
The pipeline is simple: on every push, it compiles with Maven and runs all tests. If anything breaks, I know immediately.
For a practice repository it might seem excessive, but it taught me two things:
- Integrating CI from the start costs little and prevents surprises.
- Having a green badge on the README is a real incentive not to leave broken tests behind.
Custom badge with a self-built GitHub Action
Beyond the standard CI badge, I created a custom GitHub Action that automatically counts how many challenges I have solved and generates a dynamic badge with that number. It was an interesting automation exercise: parsing the repository, counting solutions, and updating the badge on every push without manual intervention.
Organization per challenge
Each challenge has its own class inside an organized package. That avoids name collisions, makes navigation easy, and allows running a specific challenge’s tests without executing everything.
Where I learned the most
Thinking about edges before logic
The most formative challenges were not the hardest ones. They were the ones with tricky inputs: empty strings, negative numbers, single-element lists, integer overflows.
Learning to anticipate those cases before writing code is a skill I use every day.
Recursion vs iteration
Several challenges allowed both approaches. Implementing both and comparing readability, performance, and stack overflow risk gave me practical intuition about when to use each.
What I take from it
- Tests change how you think. Writing tests first forced me to understand the problem before touching it.
- CI in practice repositories is worth it. Low effort, high return in discipline.
- Java as a first serious language gave me solid foundations. Static typing, explicit exceptions, and class structure forced me to be organized from the start.
- Automating repo metrics is formative. Creating the badge GitHub Action taught me to think of the repository as a product, not just a code store.
Conclusion
This repository has no complex architecture or flashy features. But it is the project that best reflects my evolution as a programmer during that period: from struggling with basic problems to having a complete workflow with tests, CI, and organization.
Sometimes the most useful project is not the most impressive one, but the one that forces you to practice honestly and consistently.