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/Blankj/awesome-java-leetcode 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.

AVOID — Stale and unlicensed — last commit 5y ago

• 3 active contributors
• ⚠ Stale — last commit 5y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 94% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected

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

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

What it runs against: a local clone of Blankj/awesome-java-leetcode — 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 Blankj/awesome-java-leetcode | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 2005 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Blankj/awesome-java-leetcode. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Blankj/awesome-java-leetcode.git
#   cd awesome-java-leetcode
#
# 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 Blankj/awesome-java-leetcode and re-run."
  exit 2
fi

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

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

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "Companies.md" \\
  && ok "Companies.md" \\
  || miss "missing critical file: Companies.md"
test -f "note/0001/README.md" \\
  && ok "note/0001/README.md" \\
  || miss "missing critical file: note/0001/README.md"
test -f ".github/FUNDING.yml" \\
  && ok ".github/FUNDING.yml" \\
  || miss "missing critical file: .github/FUNDING.yml"
test -f ".gitignore" \\
  && ok ".gitignore" \\
  || miss "missing critical file: .gitignore"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2005 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1975d)"
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/Blankj/awesome-java-leetcode"
  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).

A curated LeetCode algorithm problem solution repository in Java with 500+ problems solved, covering Easy/Medium/Hard difficulty levels. Each problem includes working source code in src/ and detailed explanatory notes in note/ folders with diagrams (e.g., note/0011/water.png for the rain water trapping problem), plus company-specific interview problem mappings (Companies.md lists problems by employer like Facebook, Google). Flat structure: src/ contains Java solution files organized by problem number (inferred), note/ contains numbered subdirectories (0001–0025+ visible) each with README.md explaining the approach and supporting images (water.png). Root has Companies.md mapping problems to hiring companies and README.md as the index. No build system or project configuration visible.

Software engineers preparing for technical interviews at FAANG companies (especially Facebook per the README), competitive programmers transitioning from ACM to industry, and Java developers sharpening data structures and algorithms skills through structured practice.

Actively maintained educational resource with 500+ solved problems organized by difficulty and company, evidenced by README dated content and Companies.md index. No CI/CD pipeline visible (.github/FUNDING.yml only), no test suite in file list, and commit recency unknown—likely a curated study guide rather than production software. Verdict: actively developed educational project, not production code.

Single-maintainer risk (Blankj as sole author based on repo name). No dependency management files (pom.xml, build.gradle, package.json absent), so no supply chain risk but also unclear how solutions are verified or executed. No visible test suite means correctness relies on LeetCode's online judge validation only. Explanatory content may lag behind LeetCode problem updates.

Ongoing solution additions (README promises 'updating'). Recent work appears to be expanding coverage across difficulty levels and adding explanatory notes with visual aids (diagrams in note/ dirs). Facebook interview problem list actively maintained in README.

No build setup required. Clone the repo: git clone https://github.com/Blankj/awesome-java-leetcode.git && cd awesome-java-leetcode. Browse note/000X/README.md for explanations and open src/ (inferred structure) to view Java solutions. No compilation step—examine .java files directly or copy solutions to LeetCode editor.

Daily commands: No runtime—this is a source reference. To test a solution: copy the Java code from src/ into LeetCode's online editor and submit, or compile locally with javac Solution.java and write a main() harness. No package manager or build command required.

• README.md — Entry point documenting the entire repository structure, LeetCode problem coverage, and Facebook interview question mapping—essential for understanding project scope and navigation.
• Companies.md — Comprehensive mapping of LeetCode problems by tech company interview profiles—critical reference for contributors prioritizing which solutions to implement.
• note/0001/README.md — Template example showing the documentation standard for each problem (solution explanation, complexity analysis, code walkthrough)—defines contribution format.
• .github/FUNDING.yml — Sponsorship configuration—indicates project sustainability model and contribution incentive structure.
• .gitignore — Build artifact and IDE exclusion rules—ensures repository cleanliness and prevents accidental commits of compiled Java bytecode.

• Problem Note Directory (note/{NNNN}/) (Markdown, PNG/JPG images) — Stores markdown explanation, diagrams, and complexity analysis for a single LeetCode problem
  • Failure mode: Missing or incomplete explanation reduces learning value; diagrams fail to render if image links broken
• Java Source Code (src/ implied) (Java 8+) — Contains compilable Java implementations of LeetCode solutions, indexed by problem number
  • Failure mode: Code does not compile or produces incorrect output; Time/Memory Limit Exceeded on LeetCode submission
• README.md Index (Markdown table) — Provides sortable table of all problems by difficulty (Easy/Medium/Hard) and number; serves as primary entry point
  • Failure mode: Table becomes inconsistent with actual problem coverage; links rot as problem directories renamed or deleted
• Companies.md Cross-Reference (Markdown list) — Maps problem numbers to companies known to ask them in interviews; enables job-seeker filtering
  • Failure mode: Company question lists become outdated as hiring criteria evolve; missing problems reduce targeted utility

• LeetCode platform → Developer local machine — Developer reads problem statement, constraints, examples from LeetCode website
• Developer local machine → GitHub Repository (src/) — Developer writes and commits Java solution code to version control
• Developer local machine → GitHub Repository (note/) — Developer writes markdown explanation and creates diagrams for solution walkthrough
• GitHub Repository → GitHub Web UI — GitHub renders markdown and indexed tables for browser viewing; users browse solutions online
• End user (job candidate) → Companies.md — Candidate filters problems by target company interview requirements

Add a new LeetCode solution

1. Create a new directory under note/ with zero-padded problem number (e.g., note/0150/) (note/0150/README.md)
2. Write comprehensive solution explanation in README.md, including problem statement, approach, time/space complexity, and code walkthrough (note/0150/README.md)
3. Add corresponding Java implementation file in src/ directory (implied structure: src/Solution0150.java or src/com/example/Solution0150.java) (src/Solution0150.java)
4. Update the main README.md table with new problem entry, title, difficulty tag, and solution link (README.md)
5. If problem is in company interview list, update Companies.md with mapping (Companies.md)

Add visual diagrams to a problem explanation

1. Create diagram image (PNG/JPG) in the problem's note directory (note/0011/water.png)
2. Embed image reference in the problem's README.md with descriptive caption (note/0011/README.md)

Update company-specific LeetCode mappings

1. Review LeetCode's company interview question list for a specific organization (Companies.md)
2. Add or update problem number entries for that company in Companies.md (Companies.md)
3. Reference company list in main README.md if adding a new frequently-interviewed company (README.md)

• Java — Primary language for LeetCode submissions; enforces strong typing and OOP patterns useful for algorithm practice; aligns with enterprise hiring standards
• Markdown (README files) — Human-readable documentation format native to GitHub; enables easy code review, collaborative editing, and renders nicely in web UI
• Git + GitHub — Distributed version control with social features; facilitates community contributions, problem tracking, and serves as searchable archive

• Separate solution code (src/) from documentation (note/)

  • Why: Allows independent evolution of explanation detail level without cluttering source code; enables different license/access models for each
  • Consequence: Requires dual maintenance—code and docs can drift; contributors must update both to keep problem fully resolved

• Organize by problem number (0001, 0002, ...) rather than by algorithm category or difficulty

  • Why: Mirrors LeetCode's native numbering system; simplifies cross-referencing external resources and discussions
  • Consequence: Makes algorithm-based study (e.g., 'all DP problems') less discoverable; requires README tables or Companies.md cross-indexing

• Include company interview mappings in repository

  • Why: Provides high-signal filter for job candidates; increases relevance and engagement from target user base
  • Consequence: Creates maintenance burden as company hiring practices change; risks becoming stale if not updated regularly

• Does not provide interactive online judge or compilation environment—relies on LeetCode platform for testing
• Does not offer video explanations or animated walkthroughs—text and static images only
• Does not include unit test harnesses or formal test suites—explanations and manual verification sufficient
• Does not track progress/achievements per user—is a static knowledge base, not a learning platform
• Not a LeetCode API wrapper or scraper—manually curated solutions only

• Avg cyclomatic complexity: ~6.5 — Repository predominantly houses medium-complexity LeetCode problems (strings, trees, graphs, DP); estimated average problem difficulty ~Level 6–7 across Easy/Medium/Hard distribution; individual algorithm complexity ranges O(1) to O(2^n)
• Largest file: README.md (250 lines)
• Estimated quality issues: ~3 — Primary issues are documentation

• Documentation-code desynchronization (Medium) — note/{NNNN}/README.md vs implied src/Solution{NNNN}.java: Explanation may describe algorithm that differs from or becomes stale relative to actual implementation; no automated sync mechanism
• Incomplete company mappings (Medium) — Companies.md and README.md: Some problems listed in company interview focus areas may lack full solutions in repository, creating dead-end references for candidates
• No problem difficulty validation (Low) — README.md Easy/Medium/Hard sections: Difficulty tags are manually assigned and not validated against LeetCode's official difficulty; potential mismatch or inconsistency

• Repository root (288 files across 50+ problem directories) (Human bandwidth) — Single-threaded manual curation bottleneck: every new LeetCode problem requires human contributor to write explanation, code, and update indices; no automation
• Companies.md and README.md table updates (Data consistency) — All new problems require manual entry in multiple indices; table maintenance is O(n) work per addition and prone to inconsistency
• Link integrity checking (Quality assurance) — No automated verification that all markdown links to problems, images, and company references remain valid; broken links discovered only by users

No pom.xml or build.gradle means no clear Java version or dependency specification—solutions assume a modern JDK (likely Java 8+). Solutions are raw problem implementations without package declarations or imports listed in file structure; must assume they're self-contained or assume standard java.util imports. No test suite means correctness is entirely dependent on manual LeetCode submission. Company problem lists in README and Companies.md may drift from LeetCode's actual interview question pools over time.

• Two-Pointer Technique — Core pattern for array and linked list problems (problems 0026, 0028, 0015 visible in README); essential for in-place operations and intersection detection.
• Hash Table / HashMap Collision Handling — Problem 0001 (Two Sum) and many others rely on Java's HashMap; understanding collision strategies and get/put complexity is critical for optimization.
• Dynamic Programming (Memoization vs. Tabulation) — Problem 0053 (Maximum Subarray) and 16.11 (Diving Board) explicitly mention this; DP is frequent across Medium/Hard problems and interview questions.
• Stack-based Parsing — Problem 0020 (Valid Parentheses) is foundational; stack patterns appear in expression evaluation, backtracking, and depth-first traversal across the problem set.
• Linked List Pointer Manipulation — Problems 0021, 0025 (visible in README) require careful pointer updates and cycle detection; common interview pitfall area.
• Binary Search and Search Space Reduction — Problem 0035 (Search Insert Position) and others require log(n) complexity; binary search patterns appear across array and matrix problems.
• Greedy Algorithm Design — Interview problems often require proving greedy correctness; understanding when greedy works (vs. DP) is key to problem selection strategy.

• doocs/leetcode — Alternative community-driven LeetCode solution repo in multiple languages (including Java); provides cross-language learning and alternative approaches to same problems.
• halfrost/LeetCode-Go — Parallel LeetCode solutions repo in Go with detailed illustrated explanations; excellent for comparing algorithmic approaches across languages and visual problem walkthroughs.
• greyireland/algorithm-pattern — Algorithm pattern guide with focus on teaching patterns (sliding window, two-pointer, BFS/DFS) applicable across LeetCode problems; complements this repo's problem-by-problem approach with meta-strategy.
• labuladong/fucking-algorithm — Beginner-friendly algorithm tutorial in Chinese/English covering core data structures and patterns; provides foundational knowledge to understand solutions in awesome-java-leetcode.
• trekhleb/javascript-algorithms — Language-agnostic algorithm implementations with visualizations; useful for understanding underlying logic before translating to Java solutions in this repo.

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 Java solution source files (src/ directory) to match note/ documentation

The repository shows a note/ directory with 40+ problem explanations (0001-0044), but the file structure doesn't show a src/ directory with corresponding Java implementations. The README references '[src][src]' as containing source code, but these files are missing or not listed. This is a critical gap since the repo's purpose is to provide both solutions and explanations.

• [ ] Create src/ directory structure mirroring note/ (e.g., src/LeetCode0001.java, src/LeetCode0002.java, etc.)
• [ ] Implement Java solutions for problems 0001-0044 that are documented in note/
• [ ] Ensure each solution includes complexity analysis comments matching the corresponding note/ README

Complete the README.md Easy section and add Medium/Hard problem listings

The README.md snippet shows the Easy section is incomplete (table header visible but no entries). Given 40+ problems in the note/ directory, there should be a comprehensive table listing all problems by difficulty with links to solutions. This is critical for repo discoverability and navigation.

• [ ] Complete the Easy section table in README.md with Problem #, Title, and link to src/ solution
• [ ] Add Medium and Hard sections similarly, organizing by difficulty as mentioned in the README intro
• [ ] Include problem difficulty badges and tags (e.g., Array, String, DP) for each entry to help contributors find problems by topic

Add GitHub Actions workflow to validate Java solution syntax and complexity

With 40+ Java solution files, there's no CI pipeline to ensure code compiles and follows quality standards. This prevents accidental broken submissions and helps new contributors understand code quality expectations.

• [ ] Create .github/workflows/java-validate.yml to compile all src/LeetCode*.java files using javac
• [ ] Add checkstyle or similar linting rule to enforce consistent code formatting across solutions
• [ ] Configure workflow to fail the build if solutions don't compile or have obvious syntax errors, preventing low-quality PRs

• Expand note/00XX/README.md explanations with time/space complexity proofs and edge case walkthroughs for problems 0001–0010, currently listed but may lack detailed analysis.
• Add visual diagrams (similar to note/0011/water.png and note/0004/my_draw.jpg) for graph problems (e.g., 0200 Number of Islands, 0207 Course Schedule) in their note/ directories to improve learning clarity.
• Create a structured Companies.md section with difficulty levels (Easy/Medium/Hard) for each company's problem list, currently flat, to help interviewees prioritize by their weakness areas.

This is a LeetCode algorithm learning repository with minimal security risks. The codebase consists primarily of educational algorithm solutions in Java without external dependencies, database connections, or web services. No hardcoded credentials, sensitive configuration files, or infrastructure components were detected. The repository follows good practices by excluding sensitive files (.gitignore is present). Minor considerations include standard best practices for any Java project.

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

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

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