Enterprise-grade repository for algorithmic problem solving, software engineering practice, and continuous technical growth.
Auto-generated by
scripts/gen_indexes.py— do not edit between the STATS markers.
| Metric | Value |
|---|---|
| Challenges solved | 50 |
| Source platforms | 2 active (of 16 catalogued) |
| Languages used | 3 |
| Catalogued topics | 47 |
| Catalogued patterns | 145 |
This repository serves as a centralized knowledge base for coding challenges, algorithmic patterns, data structure implementations, and problem-solving methodologies collected across multiple competitive programming and technical assessment platforms.
The primary goal is not simply to store accepted solutions, but to document the reasoning process, architectural decisions, complexity trade-offs, and reusable patterns that emerge while solving real-world algorithmic problems.
Over time, this repository evolves into a structured engineering reference system that supports:
- Continuous learning
- Interview preparation
- Pattern recognition
- Algorithm mastery
- Technical portfolio development
- Knowledge sharing
See platforms/README.md for the full catalog (strengths, ideal use, links).
- LeetCode
- HackerRank
- Codewars
- CodeSignal
- AlgoCademy
- TopCoder
- Exercism
- Pramp
- Interview Cake
- Codility
- StrataScratch
- CodeChef
- Project Euler
coding-challenges/
│
├── articles/ # technical articles (markdown + frontmatter)
├── docs/
├── platforms/ # one folder per (platform, language, challenge) + manifest.json
├── scripts/ # generators (stats indexes) + versioned git hooks
├── src/ # the website (GitHub Pages serves from the master root)
├── stats/ # auto-generated indexes — never edit by hand
└── templates/
Contains solutions organized according to the original source platform.
platforms/
├── leetcode/
├── hackerrank/
├── codewars/
├── codesignal/
├── algocademy/
├── topcoder/
├── exercism/
├── pramp/
├── interview-cake/
├── codility/
├── stratascratch/
├── codechef/
└── project-euler/
This structure enables traceability back to the original challenge.
Domains (topics) and reusable patterns are not physical folders — they are
derived from each challenge's metadata.json and surfaced as data-driven views,
so a single source of truth (the metadata) is never duplicated across folders:
- On the site — the Topic and Pattern explorers (
src/topics.html,src/patterns.html): sortable, filterable tables that link every challenge exercising a given topic or pattern, across all platforms. - On GitHub —
stats/index-topics.mdandstats/index-patterns.md, regenerated on every commit.
This is the view that helps identify strengths, weaknesses, and learning gaps.
Each challenge is stored per language under its platform, as self-contained units that cross-reference each other.
The full standard is documented in docs/challenge-format.md.
Reusable starter files are available under templates/challenge/.
platforms/leetcode/cpp/0001-two-sum/ # C++ proposals
├── solution.{ext} # recommended (if in this language)
├── solution-runtime.{ext} # speed extreme (if in this language)
├── notes.md
├── complexity.md
└── metadata.json
platforms/leetcode/c/0001-two-sum/ # C proposal (e.g. memory champion)
├── solution-memory.{ext}
├── notes.md
├── complexity.md
└── metadata.json
| File | Purpose |
|---|---|
| solution.{ext} | Recommended proposal: fastest runtime that stays lean |
| solution-runtime.{ext} | Speed extreme: asymptotically fastest / early-exit |
| solution-memory.{ext} | Memory extreme: minimum footprint |
| notes.md | Problem analysis, reasoning, and trade-offs |
| complexity.md | Time and space complexity for each proposal |
| metadata.json | Structured data (variants[] + crossReferences) |
Solutions prioritize readability and maintainability over unnecessary optimization.
Every solution should explicitly document:
- Time Complexity
- Space Complexity
- Optimization Opportunities
Each challenge should be mapped to one or more algorithmic patterns whenever applicable.
Improved solutions may replace previous implementations when better approaches are discovered.
There is no default or primary language.
Each challenge ships three proposals (recommended fast + lean, speed extreme, memory extreme); each proposal uses the most performant language for its goal, selected from the allowed language set and justified in the challenge notes. The proposals may use different languages.
Allowed languages:
- C++
- Java
- Python3
- Python
- JavaScript
- TypeScript
- C#
- C
- Go
- Kotlin
- Swift
- Rust
- Ruby
- PHP
- Dart
- Scala
- Elixir
- Erlang
- Racket
The repository architecture is language-agnostic and designed for performance-driven language selection per proposal.
Repository metrics may include:
- Total challenges solved
- Platform distribution
- Difficulty distribution
- Topic coverage
- Pattern coverage
- Learning velocity
- Monthly progress trends
These statistics are generated by scripts/gen_indexes.py from challenge metadata and stored under stats/:
stats/index-overview.md— global totals (challenges solved, source platforms, languages used, catalogued topics and patterns).stats/index-{platform}.md— per-platform breakdown (per difficulty, per language, per type).
A versioned pre-commit hook regenerates them on every commit (enable once with git config core.hooksPath scripts/hooks). See AGENTS.md for details.
Status mirrors the live site (src/assets/data.js): all five phases are shipped.
- Centralized challenge collection
- Pattern catalog
- Complexity analysis
- Metadata generation
- Statistics dashboards
- Automated README updates
- Static website generation
- Searchable challenge index
- Pattern explorer
- Public technical showcase
- Learning timeline — home band with selectable window (all time / year / month / week), GitHub-style heatmap for the year view
- Technical articles —
articles/*.md, indexed by the manifest, rendered by the site ("Writing" section) - Interview preparation resources — covered by the pattern/topic explorer: study-by-pattern and study-by-domain over every solved challenge
- Automated solution classification
- Pattern extraction
- Skill gap analysis — home section derived live from the manifest: difficulty mix, untouched core domains, single-solve domains
Personalized learning recommendations were dropped from scope (not deferred): the repository stores solved work only, so by design there is no catalogue of unsolved problems to recommend from. "What next?" is the agent's job at solve time, with the skill-gap analysis as its input.
Although this repository is currently maintained by a single author, all content follows software engineering standards regarding:
- Consistency
- Documentation
- Traceability
- Reproducibility
- Long-term maintainability
This repository is intended for educational purposes, professional development, and knowledge sharing.
Solutions are published to document learning progress and software engineering practices rather than to provide shortcuts for active assessments or interviews.
Daniel Polo ─ Software Architect & Engineering Enthusiast
Building a long-term knowledge system around algorithms, software design, problem solving, and continuous technical growth.