WAIT — Stale — last commit 2y ago

• 26+ active contributors
• Other licensed
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 71% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

A curated collection of 120+ interactive Python Jupyter notebooks teaching coding interview algorithms and data structures (arrays, strings, trees, graphs, sorting, etc.) with unit-tested reference implementations, constraint definitions, Big-O complexity analysis, and an Anki flashcard deck for spaced-repetition memorization. Monolithic educational structure organized by topic: arrays_strings/, then parallel directories for trees/, sorting/, graphs/, etc., each containing challenge/ (problem statement + test stubs), solution/ (reference implementation), and test_*.py (unit tests). Root includes init.py for module-based import and anki_cards/Coding.apkg for standalone flashcard study. Notebooks are Jupyter .ipynb files with markdown sections for Problem Statement, Constraints, Test Cases, and Algorithm explanation.

Software engineering candidates preparing for technical interviews, junior developers learning algorithms and data structures, and interviewers seeking reference implementations with well-documented solutions and test cases.

Mature and actively maintained: the README indicates 'continually updated' challenges, comprehensive test coverage via nose, 120+ challenges across multiple categories, and an established Anki deck (anki_cards/Coding.apkg) suggesting sustained use. The file structure shows consistent patterns (each challenge has challenge/.ipynb, solution/.ipynb, and test_*.py), indicating a well-established baseline that is regularly extended.

Low risk for a learning resource: the codebase is primarily documentation and reference code (notebooks + tests) rather than a runtime dependency, so API breakage is unlikely to cascade. Single-maintainer risk is present (donnemartin as sole operator based on GitHub handle), but the project's educational nature means it tolerates slower update cycles. Dependency footprint is minimal (jupyter, nose) and stable; no production deployment risk.

The README mentions 'soon provide on-demand incremental hints' (issue #22), indicating active roadmap planning. The 'continually updated' note and Binder badge suggest recent maintenance, though specific commit history is not visible in the provided file list. The focus appears to be on expanding challenge coverage while maintaining solution quality and test consistency.

Clone the repository and explore interactively via Jupyter: git clone https://github.com/donnemartin/interactive-coding-challenges.git && cd interactive-coding-challenges && pip install jupyter nose && jupyter notebook. Then open any challenge notebook (e.g., arrays_strings/compress/compress_challenge.ipynb) to see the problem statement, write your solution, and run the unit tests.

Daily commands: For learning: jupyter notebook then open any challenge.ipynb to attempt the problem and run the integrated test cases. For validation: nosetests or nose2 to execute all test.py files across the repo and verify solutions. For using Anki flashcards: import anki_cards/Coding.apkg into Anki desktop app (https://apps.ankiweb.net/).

• arrays_strings/compress/compress_challenge.ipynb: Exemplar challenge notebook showing the expected structure: problem statement, constraints, test cases, and empty function stub for the learner to fill in.
• arrays_strings/compress/compress_solution.ipynb: Exemplar solution notebook with fully implemented algorithm, step-by-step explanation, Big-O complexity analysis, and notes on trade-offs.
• arrays_strings/compress/test_compress.py: Exemplar unit test file using nose framework; defines all test cases referenced in the challenge notebook and validates both challenge and solution implementations.
• anki_cards/Coding.apkg: Standalone Anki flashcard deck exporting key algorithmic concepts and data structure facts for spaced-repetition memorization on mobile and desktop.
• README.md: Hub documentation: links to challenge overview, Anki deck download, sister repo (system-design-primer), and sets expectations for learning outcomes.
• CONTRIBUTING.md: Guidelines for contributors: defines how to propose new challenges, format notebooks, write tests, and maintain consistency across the 120+ challenge base.

To add a new challenge: create arrays_strings/new_challenge/ with init.py, new_challenge_challenge.ipynb (problem + empty function), new_challenge_solution.ipynb (full solution + Big-O), and test_new_challenge.py (unit tests using nose assertions). Reference existing challenges (e.g., arrays_strings/compress/) as templates. Ensure test_*.py imports from the solution module and follows the existing test pattern. Update anki_cards/Coding.apkg if adding new key concepts.

Notebook-based structure requires Jupyter to edit challenges; direct Python file editing is possible but notebooks are the canonical format. Test file imports assume the module structure (e.g., from arrays_strings.compress import ...) so directory init.py files must exist. Anki flashcard deck (.apkg) requires Anki app; the deck is binary and not human-editable in the repo. Some challenges (e.g., two_sum/test_two_sum.py) may lack challenge/solution notebooks if they are stubs, so check both file types before assuming completeness. No CI/CD configuration visible (no .travis.yml, .github/workflows/, setup.py), so tests are run manually or by contributor before commit.

• Two-pointer technique — Fundamental pattern for problems like rotation, permutation checking, and string reversal that reduces space complexity by avoiding auxiliary data structures.
• Hash table / Hash map design — Enables O(1) average-case lookups for problems like permutation and duplicate detection; understanding collision resolution and load factors is core to interview readiness.
• Priority queue / Heap — Underpins efficient scheduling and k-largest/smallest queries; the priority_queue challenge teaches heap insertion and extraction, critical for problems like merge k sorted lists.
• Big-O time and space complexity analysis — Every challenge notebook details algorithm complexity; mastering Big-O notation (O(n log n), O(n²), O(1) space, etc.) is non-negotiable for conveying solution trade-offs in interviews.
• String compression and run-length encoding — Classic interview problem testing loop control, string manipulation, and array bounds checking; the compress challenges demonstrate both naive and optimal approaches.
• Array rotation in-place — Teaches clever index arithmetic and space-efficient array manipulation without creating new buffers; rotation/ challenge is a gateway to understanding array algorithm optimization.
• Spaced repetition learning (Anki) — The Anki flashcard deck leverages cognitive science to optimize retention of algorithm concepts and patterns; reinforces learning beyond notebook walkthroughs.

• donnemartin/system-design-primer — Sister repo by same author covering system design and OO design interviews; complementary Anki decks for design vs. algorithmic interview prep.
• TheAlgorithms/Python — Large crowdsourced collection of algorithm implementations in Python; overlaps on algorithm coverage but lacks notebook-based learning structure and test-driven approach.
• keon/algorithms — Curated Python algorithm implementations organized by topic with LeetCode-style difficulty; similar goal but no interactive Jupyter notebooks or Anki integration.
• VisuAlgo/visualgo.net — Interactive algorithm visualization tool complementing written solutions; pairs well with this repo's explanations by showing dynamic execution traces.
• LeetCode/LeetCode — Commercial coding interview platform with thousands of problems and instant judge feedback; this repo is a self-study alternative with curated, in-depth solutions and offline learning.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add pytest configuration and GitHub Actions CI workflow for automated test execution

The repo uses nose for testing but lacks automated CI. Currently there's no way to verify that all 120+ challenges pass their unit tests on every commit. This is critical for a repo designed to teach best practices. A GitHub Actions workflow would catch regressions when contributors add new challenges or modify existing ones.

• [ ] Create .github/workflows/tests.yml to run pytest/nose on Python 3.8+ for all test_*.py files across arrays_strings/, bit_manipulation/, and other challenge directories
• [ ] Add pytest.ini or setup.cfg to configure test discovery and output formatting
• [ ] Update CONTRIBUTING.md to document the testing requirement for PRs
• [ ] Verify the workflow passes against existing test files like arrays_strings/compress/test_compress.py, arrays_strings/hash_map/test_hash_map.py, etc.

Create a Jupyter notebook linting/validation script to catch broken notebook cells

The repo contains 100+ Jupyter notebooks (*_challenge.ipynb and *_solution.ipynb files) but there's no validation that notebook code cells are syntactically correct or that imports work. Contributors could accidentally break notebooks. A pre-commit hook or CI step using nbval or nbconvert would catch broken cells before they're merged.

• [ ] Add a Python script (e.g., scripts/validate_notebooks.py) that uses nbconvert or nbval to validate all *.ipynb files in arrays_strings/, bit_manipulation/, and other subdirectories
• [ ] Include notebook syntax validation and optional execution of code cells to catch ImportError or runtime issues
• [ ] Integrate into GitHub Actions workflow created in PR #1, or as a standalone CI job
• [ ] Document the validation step in CONTRIBUTING.md with instructions for local testing

Add type hints to all test_*.py files and create a mypy static analysis CI job

All test files (e.g., test_compress.py, test_hash_map.py, test_priority_queue.py) lack type annotations. Since this repo teaches best practices for coding interviews, adding type hints and mypy validation would serve as an educational example and catch subtle bugs. This is especially valuable because it demonstrates modern Python practices.

• [ ] Add type hints to function signatures in arrays_strings/compress/test_compress.py, arrays_strings/hash_map/test_hash_map.py, bit_manipulation/bit/test_bit.py, and other test files (reference: ~25 test files total)
• [ ] Create mypy.ini configuration file with appropriate settings for the codebase
• [ ] Add a GitHub Actions job to run mypy on all test_*.py and challenge solution files
• [ ] Document the type-hinting standard in CONTRIBUTING.md with examples from existing test files

• Add missing solution notebook for arrays_strings/two_sum/ (test_two_sum.py exists but no .ipynb files visible in file list); create two_sum_challenge.ipynb and two_sum_solution.ipynb following the compress/ pattern.
• Expand test coverage for arrays_strings/priority_queue/test_priority_queue.py by adding edge cases (empty queue, single element, duplicate priorities) and validate them against priority_queue_solution.ipynb.
• Create a new challenge for arrays_strings/merge_sorted_arrays (common interview problem) by drafting merge_sorted_arrays_challenge.ipynb, merge_sorted_arrays_solution.ipynb, test_merge_sorted_arrays.py, and corresponding Anki flashcard entry.

This is an educational coding challenges repository with minimal security risks. The primary concerns are related to dependency management (missing version pinning and use of deprecated testing frameworks) rather than application logic vulnerabilities. The codebase contains no database queries, web endpoints, or credential storage. The use of Jupyter notebooks is inherent to the project's purpose. No hardcoded secrets, injection vulnerabilities, or infrastructure misconfigurations were detected. Recommendations focus on strengthening dependency management practices and ensuring notebook integrity.

• Low · Jupyter Notebook Dependency Without Version Pinning — Dependencies/Package file (jupyter). The dependency file specifies 'jupyter' without a specific version constraint. Jupyter notebooks can execute arbitrary code and have had security vulnerabilities in the past. Without version pinning, unpredictable versions may be installed during dependency resolution. Fix: Pin Jupyter to a specific stable version (e.g., 'jupyter>=1.0.0,<2.0.0') and regularly update to patched versions. Consider using a requirements.txt or setup.py with explicit version constraints.
• Low · Nose Test Framework Deprecated — Dependencies/Package file (nose). The 'nose' testing framework is deprecated and no longer maintained. It has known security and compatibility issues. The project should migrate to pytest or unittest (Python standard library). Fix: Migrate test suite from nose to pytest or unittest. Update test execution commands accordingly. Remove nose dependency.
• Low · No .gitignore Security Analysis — .gitignore. While a .gitignore file exists, without reviewing its contents, there's a risk that sensitive files (environment variables, API keys, credentials) could be accidentally committed. The file structure shows no evidence of .env or secrets files, but best practices should be verified. Fix: Verify .gitignore includes: *.env, *.key, *.pem, credentials, secrets/, .DS_Store, pycache/, *.pyc. Add patterns for IDE files (.vscode/, .idea/). Consider using git-secrets or similar pre-commit hooks.
• Low · Jupyter Notebook Files in Repository — Multiple .ipynb files throughout arrays_strings/, bit_manipulation/, etc.. Jupyter notebook files (.ipynb) are JSON-based and can contain arbitrary code and output. If notebooks were created by untrusted sources or contain sensitive information, they pose security risks. Large notebooks can also be difficult to review in version control. Fix: Review notebooks for hardcoded credentials or sensitive data. Consider storing notebooks separately or using nbstripout to remove output before committing. Use --trust-only-on-notebook-open when running untrusted notebooks.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/donnemartin/interactive-coding-challenges shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live donnemartin/interactive-coding-challenges repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/donnemartin/interactive-coding-challenges.

What it runs against: a local clone of donnemartin/interactive-coding-challenges — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in donnemartin/interactive-coding-challenges | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 760 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of donnemartin/interactive-coding-challenges. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/donnemartin/interactive-coding-challenges.git
#   cd interactive-coding-challenges
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of donnemartin/interactive-coding-challenges and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "donnemartin/interactive-coding-challenges(\\.git)?\\b" \\
  && ok "origin remote is donnemartin/interactive-coding-challenges" \\
  || miss "origin remote is not donnemartin/interactive-coding-challenges (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 760 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~730d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/donnemartin/interactive-coding-challenges"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.