AlgoDS: 300 problems, no build file, and a language switcher pointing elsewhere

There is no build file anywhere in the repository

The top level of the tree is short enough to read in one line, and what is missing from it matters more than what is there.

There is a gitignore, a licence file spelled with a c, three readme files, an IntelliJ module file, a GitHub directory and a source directory. There is no build descriptor of any kind: no Maven file, no Gradle file, no wrapper, no toolchain declaration.

So nothing in the repository states which Java version the code targets, how it is compiled, or what a reader should expect when they clone it. The committed module file is the closest thing to a project definition, and it is the artefact of one specific IDE rather than something a build tool consumes.

That is consistent with how the file describes itself. It is a collection of solutions to common algorithmic problems and implementations of data structures in Java, created by one person to learn algorithms, and it presents itself as something you read and run in an editor rather than something you consume as a dependency. For that purpose no build file is needed. For anyone who wants a repeatable compile or a test command, the repository does not give you one.

The question lists are text files whose names differ in case from the answer folders

The navigation is built around difficulty levels rather than around topics, and it is worth spelling out because the two halves of each level do not match.

There are three question files at the top of the problems directory, one per level, with capitalised names. There are three answer directories beside them, one per level, with the same names in lower case. The easy link goes to a capitalised text file and a lower-case directory; the same pattern holds for medium and hard.

On a case-sensitive filesystem those are two different names, which is harmless as long as nobody renames anything. It also means the naming is not coming from one source, since a script that generated both would normally produce the same case.

The topic view cuts across those directories. Arrays, linked lists and binary trees each get their own numbered section in the file, and each entry links to a single file inside the level directory that matches its difficulty. So the same file could have been filed by topic instead, and the two schemes are maintained by hand next to each other.

For a reader, the practical effect is that the difficulty view and the topic view are both navigable but only one of them is authoritative, and neither is generated from anything.

Two entries in the linked list section are both numbered one

The numbered lists in the file are hand-written, and the hand-writing shows.

In the linked list section the numbering runs one, one, three, four. The first two entries are the singly linked list implementation and the doubly linked list implementation, both data structures rather than problems, and the second one inherits the number one.

The same section also contains two cycle problems, which is normal for interview practice, but their titles are close enough to be confusing: one is the cycle problem and the other is finding where a cycle begins. The second one's file name carries a numeric suffix to distinguish it, while the link text does not make that distinction.

None of this affects the code. It does affect the thing a reader actually uses here, which is the list, since a numbered list that skips and repeats is harder to scan for the one problem you came for.

The binary tree section is the longest, running past twenty-five entries, and it is where the file ends mid-link. So the final problem in that section has its heading and its number and nothing after it.

Filenames drop spaces, and in four cases they drop words too

The convention for naming solution files is clear: spaces removed and lower case, which is ordinary for this kind of repository. The interesting part is where the transformation changes the meaning.

Four entries show it. The rotated-array minimum problem is titled as finding the minimum in a rotated array, and its file is named for finding the minimum in a rotated sorted array, which is a different problem statement. The shuffled-array problem keeps its name but the space disappears into the word, producing a file that reads as one token. The binary tree left side view has a capital letter in the middle of the word it should not. And the problem titled as converting a sorted list into a balanced search tree has a file named for converting a sorted array instead, while a neighbouring entry titled as a list does have a list in its file name.

So the mapping from title to file name is not mechanical. If you go looking for a solution by reading the titles and then guessing the file name, four of a hundred will send you to the wrong file, and in two cases the file you land on solves a slightly different problem than the one the heading describes.

Searching the repository by file name rather than by title avoids the problem entirely, which is the practical advice.

The language switcher links to another account, and the Russian readme is never linked

The first line of the file is a language switcher, and it has two problems.

It offers one other language, Chinese, and the link for it points into a different account's copy of the repository rather than into this one. So the English readme sends you to a Chinese readme that someone else maintains, which means the two can and do drift.

Meanwhile this repository contains three readme files at its root: the English one, a Chinese one and a Russian one. The Chinese file here is not the file the switcher points at, and the Russian file has no link anywhere in the English one.

None of this affects the Java code. It does affect anyone who arrives from the Chinese version, because the account a link points at decides who gets pull requests and issues for the text, and a reader has no way to tell from the link that they are on a different copy.

The licence file at the root is spelled with a c, which is worth noting only because it makes the file harder to find by search from a repository browser, and the recorded licence identifier for the project is MIT.

More than 300 problems, added continuously, with the last commit in October 2023

The file makes a claim about its own currency and the repository history tells a different story, so both belong in the same paragraph.

The claim is that the author is adding solutions continuously, and that more than 300 problems and solutions are provided so far, alongside the algorithms and data structures.

The dates say the last push to the default branch was on 27 October 2023, and the repository publishes no tagged releases at all, so there is no version to check the count against and nothing to diff against the file's own list. The repository is not marked archived.

The consequence for a reader is that this is a snapshot. The file lists a specific number of problems per topic, and those counts will not change on their own. If you are working through a curriculum, you are working through a list that stopped moving three years ago.

The homepage field points to the author's personal site over plain HTTP rather than to documentation for this project, which tells you where the repository sits in the author's work: one artefact among several, linked from a personal page.

The catalogue is classic interview topics, and one section ends mid-link

What the repository covers is worth stating plainly, because the boundary is sharper than the word collection suggests.

The topics are the standard three: arrays, linked lists and binary trees. The arrays section runs to eleven entries, covering rotation, duplicates, peak finding, maximum subarray, the kth largest element, the longest increasing subsequence, rotating an image in place, shuffling, and searching in a rotated array. The linked list section covers both list implementations plus deletion, palindrome detection, reversal, intersection, cycle detection, removing a node from the end, merging two sorted lists, merging k sorted lists, and sorting a list.

The binary tree section is the longest and the most systematic: level order traversal, left-leaf sums, inversion, an iterator, the three traversals, flattening, symmetry, the same-tree check, depth, balance, conversion from a sorted list, validation, the kth smallest element, zigzag traversal, deletion, lowest common ancestor, side views, mode in a tree, and subtree sums.

Each section ends with a link to the problems directory for the many that are not listed, so the file is a curated index rather than the full inventory. The count of 300 sits well above what these three sections enumerate, which means most of the collection is only reachable by browsing the directory.

Editorial conclusion

AlgoDS is worth browsing rather than depending on. If you want a worked Java solution to a classic array, linked list or tree problem, the density is high and the naming is predictable enough to search. Three things to check before you lean on it. There is no build file, so nothing declares a language version, a test runner or a dependency set, and the committed module file means the project expects an IDE. The catalogue is organised around classic interview topics, so anything you need outside that set is not here. And the file says solutions are being added continuously while the branch was last pushed on 27 October 2023, with no tagged releases, so treat the contents as a snapshot of one person's practice rather than a maintained curriculum.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository