suryav2006-git/leetcode-practice-solutions

Purpose and Shape

This is a LeetCode solution corpus, not a deployable application. Each numbered directory is an independent problem unit containing a problem README and one or more language-specific submissions. The root catalog groups problems by algorithmic topic; stats.json is repository-level metadata.

Entry Points and Execution Boundary

There is no shared executable, package manifest, service, or application runtime. The effective entry points are LeetCode-compatible solution files, invoked by the LeetCode judge with platform-provided inputs and types:

• 0001-two-sum/0001-two-sum.cpp

• 0001-two-sum/0001-two-sum.java

• 0001-two-sum/0001-two-sum.py

Each file must be compiled/interpreted independently in its selected language; solutions are not intended to call one another.

Problem-Unit Contract

A directory is the primary architectural boundary: problem statement/documentation plus alternative implementations of the same contract. Language coverage varies by problem.

• 0002-add-two-numbers/README.md

• 0002-add-two-numbers/0002-add-two-numbers.cpp

• 0002-add-two-numbers/0002-add-two-numbers.java

Inputs, outputs, and judge-owned structures such as linked-list or tree nodes are externalized to LeetCode. Local code provides the expected algorithm method/class rather than CLI parsing, persistence, or network handling.

Algorithm Families: Sequence and Search

A large portion addresses arrays using hashing, sorting, pointers, sliding windows, and binary-search variants. These are isolated implementations rather than reusable shared modules.

• 0015-3sum/0015-3sum.cpp

• 0033-search-in-rotated-sorted-array/0033-search-in-rotated-sorted-array.java

• 1011-capacity-to-ship-packages-within-d-days/1011-capacity-to-ship-packages-within-d-days.cpp

Typical flow: judge supplies an array/string and parameters → solution derives an answer or mutates the supplied collection → judge validates result.

Algorithm Families: Structured Data and Traversal

Linked-list, tree, and grid problems rely on judge-provided node/grid models. Traversal or pointer-rewiring remains contained within the corresponding problem directory.

• 0206-reverse-linked-list/0206-reverse-linked-list.py

• 0098-validate-binary-search-tree/0098-validate-binary-search-tree.cpp

• 0200-number-of-islands/0200-number-of-islands.java

Important boundary: list/tree node declarations and test harnesses are not repository-owned; code must remain compatible with platform definitions.

Multi-Runtime Support

The material runtimes are C, C++, Java, Python, and SQL, with C++ and Java present for most units. SQL is used for the database-specific challenge:

• 0007-reverse-integer/0007-reverse-integer.c

• 0509-fibonacci-number/0509-fibonacci-number.py

• 0175-combine-two-tables/0175-combine-two-tables.sql

There are no declared external services, databases, APIs, deployment infrastructure, or cross-language build orchestration. The only external execution environment is LeetCode’s online judge and, for SQL, its supplied relational schema/data.

Repository-Level Index

The root README acts as a topic-to-directory navigation index, while each leaf README describes its individual challenge.

• README.md

• stats.json

• 0875-koko-eating-bananas/README.md

Adding a solution means creating/updating an independent numbered directory and its implementations; it does not require modifying a central runtime or dependency graph.