# Striver's A2Z DSA Sheet: a C++ solution archive with a fixed file template > This repository is a plain C++ archive of solutions for the topics in Striver's A2Z data structures and algorithms sheet, organised into sixteen numbered topic folders where each file follows the same template: question, approach, code, time complexity and space complexity. It is a reference sheet, not a course, and it declares no licence. **Codensity30/Strivers-A2Z-DSA-Sheet** — Contains everything related to Stiver's A2Z sheet along with question, approach and code. - Repository: https://github.com/Codensity30/Strivers-A2Z-DSA-Sheet - Stars: 1,007 · Forks: 341 - Language: C++ - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/codensity30-strivers-a2z-dsa-sheet ## A reference sheet for the Striver A2Z course list The repository exists to serve one course sheet. The README describes it as containing everything related to Striver's A2Z sheet along with the question, the approach and the code, and it links the sheet itself as a resource. That is the honest scope of the project: it is not a general algorithm library and it is not a teaching course. It is a companion archive for people working through a specific, well-known list of data structures and algorithm problems in C++. The stated audience is students and interview candidates, and the disclaimer in the README says the solutions are meant as a reference and learning resource, and recommends understanding the problem solving techniques and attempting each problem before looking at the solution. That framing matters, because the file format is designed for comparison after you have tried, not as a place to copy an answer you have not reasoned about. ## Sixteen numbered topic folders, from arrays to tries The directory layout is the main navigation mechanism, and it follows the sheet's order rather than any alphabetical arrangement. At the top level you find 01.Arrays, 02.Binary Search, 03.Strings, 04.Linked List, 05.Recursion, 06.Bit Manipulation, 07.Stack and Queues, 08. Sliding Window, 09. Heaps, 10. Greedy Approach, 11. Binary Trees, 12. Binary Search Trees, 13. Graphs, 14. Dynamic Programming, 15. Tries and 16. Strings (Hard), alongside the README. Each topic has its own directory, and each of those is further divided into difficulty levels containing the solutions for the problems in that category, with the approach recorded alongside them. The difficulty split mirrors how a practice platform sorts a problem list, so someone who wants the medium problems in a topic does not have to read the easy ones first. A small inconsistency in the naming is worth noting, since one folder carries a space after its number while the others do not, which is the kind of detail that trips up scripts that build paths from these names. ## Every file records the same five parts The file template is where most of the value sits, because it forces a solution to be explained rather than just compiled. A solution file is a C++ file that carries, in order, the question written as a problem statement, a brief explanation of the approach used, the C++ code of that approach, a time complexity analysis and a space complexity analysis. Because every author fills the same five slots, two solutions to different problems can be read side by side, and a reviewer can see whether the complexity notes match the approach without reverse engineering the code. Filenames correspond to the problem number or carry a brief description, so a directory listing is a usable index. The cost of the format is that it does not fit every problem well: a proof sketch, a walkthrough of a counterexample or a note on a subtle implementation trap has no obvious slot, and the natural place for it is inside the brief approach paragraph. ## The contribution path: fork, branch, pull request The README sets out an explicit contribution workflow, and the reason it is spelled out is that a repository full of small independent solutions attracts many small pull requests. Fork the repository, create a branch for the change, make the change and add your solutions, commit with a descriptive message, push to your fork and open a pull request on the original repository explaining what changed and why it should be merged. The commands given are: ```bash git checkout -b your-branch-name git commit -m "Add solution to Problem X" git push origin your-branch-name ``` The commit message format in the example, Add solution to Problem X, tells you how the project expects contributions to be labelled, which is useful for a maintainer triaging a queue of additions. Note what the workflow does not include: there is no mention of a build step, a test suite, a formatting tool or a contribution that adds a new language. The project is C++ throughout, and the acceptance bar described in the README is a good solution plus an explanation of why it should be merged, which leaves the review depth to the maintainer. ## Consistency as the reason the sheet works The README places a consistency note right after the resource link, and it is the design principle behind the whole archive. The same file template applied across every topic and every difficulty means a reader who has understood how one solution is presented knows how to read all of them, and a contributor who has written one file knows exactly what to write next. The number in the filename and the difficulty folder together give a second axis of consistency, so a specific problem can be found by a route that does not depend on remembering the topic name. What this buys you is speed of retrieval under time pressure, which is the situation an interview candidate is actually in. What it does not buy you is depth: the approach paragraph is explicitly a brief explanation, so the archive is a good answer to what does a working solution look like, and a weak answer to why this particular approach is the right one for a constraint you happen to have. ## What the archive does not give you Several things a developer might expect from a code repository are simply absent, and their absence shapes how you should use it. There is no build system, no test suite, no continuous integration and no dependency manifest, so the files are read and copied rather than built and run as a project. The language is C++ only, with no Python or Java variants, so a candidate interviewing in another language still has to translate the approach yourself, which is the real work anyway. The repository declares no licence, so there is no clear permission to redistribute the code or to fold it into a product, and that is a point to settle before you copy from it. There are no GitHub releases either, so there is no versioned history to pin against, and the only changelog is the commit log itself. The last push was on 2026-05-09, which is a fact to weigh when you compare the folder list with the course sheet you are currently working through, since a renamed or retired topic would show up as a missing directory rather than as a release note. ## Conclusion Use this repository when you want a fast, uniform C++ reference for a topic you are revising the night before an interview, and you are comfortable reading someone else's approach to check your own. Do not treat it as a learning path, since the upstream course sheet is where the teaching lives, and do not copy code into a product without checking the licence position, because none is declared. Before you rely on a file, open it and check the complexity notes against your own constraints, and remember the last push was on 2026-05-09, so check whether the topic list still matches the course you are following. ## FAQ ### What does the Striver's A2Z DSA Sheet repository contain? It contains solutions for the topics in Striver's A2Z sheet, written in C++, with each topic in its own directory and each of those divided into difficulty levels. The repository has no GitHub releases. ### What is inside a solution file? Each file carries five parts in order: the question as a problem statement, a brief explanation of the approach, the C++ code, a time complexity analysis and a space complexity analysis. Filenames use the problem number or a brief description. ### How do I contribute a solution to this repository? Fork it, create a branch with git checkout -b your-branch-name, add your solution, commit with a descriptive message such as "Add solution to Problem X", push to your fork and open a pull request explaining the change and why it should be merged. ### Can I use the code from this sheet in a commercial project? The repository declares no licence, so there is no clear permission for redistribution or reuse in a product. That question is worth settling before you copy code from it. ## Sources - [Codensity30/Strivers-A2Z-DSA-Sheet on GitHub](https://github.com/Codensity30/Strivers-A2Z-DSA-Sheet) - [Issues](https://github.com/Codensity30/Strivers-A2Z-DSA-Sheet/issues) - [README](https://github.com/Codensity30/Strivers-A2Z-DSA-Sheet/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/codensity30-strivers-a2z-dsa-sheet