liquidslr/interview-company-wise-problems

1. This repository is a curated data catalog, not an application. Its primary purpose is to store LeetCode company-wise question lists as CSV files, organized for direct human browsing or downstream ingestion.

2. The top-level boundary is the company folder. Each folder represents one employer or org (for example, Amazon, Google, Stripe, etc.), and folders are intentionally independent so consumers can pull just the companies they care about.

3. Inside every company folder is the same five-file pattern:

- 1. Thirty Days.csv

- 2. Three Months.csv

- 3. Six Months.csv

- 4. More Than Six Months.csv

- 5. All.csv

4. These files represent time-window slices of the same underlying problem set. The first four are recency-based views, while All.csv is the aggregate or full list for that company.

5. The repeated file structure is the key architectural idea: each company is a self-contained dataset partitioned by recency, which makes the repository easy to scan, compare, and update without needing application logic.

6. The README establishes the content contract: the lists are “curated,” grouped by company, and updated as of 1 June 2025. That date is important because it implies the CSVs are snapshots of a maintained dataset rather than live-synced feeds.

7. There is no backend, UI, API layer, or orchestration code in this repo. The data flow is therefore simple: curated question lists are produced externally, then committed into the corresponding company/time-window CSV files.

8. The main consumers are likely readers, interview-prep workflows, spreadsheet tools, or scripts that parse CSVs. Because the repository is file-based only, the filesystem itself is the query surface and distribution mechanism.

9. The schema boundary is implied by file naming rather than code. Any architecture diagram should show a single standardized dataset format per company, with multiple temporal views under the same namespace.

10. The repo also references an external sibling resource, “system-design-notes,” but that is only linked from the README and is not part of this repository’s internal architecture.

11. In diagram terms, the important model is: one curated content source feeding many company partitions, each partition exposing five time-bucketed CSV views. There are no additional service tiers or runtime dependencies to include.