kdn251/interviews: a link list with a data structure appendix, last touched in May 2025

The BST row promises O(log n) and never mentions balance

The binary search tree entry is the most used part of this repository and the most likely to be misremembered. The definition is given correctly: a type of binary tree in which the value in each node must be greater than or equal to any value in the left sub-tree, and less than or equal to any value in the right sub-tree. Then come four rows, access, search, insert and remove, each listed as `O(log(n))`.

Those four numbers hold only when the tree stays balanced, and the text never says so. Nothing in the entry mentions self-balancing trees, rotation, or what happens when keys arrive in sorted order, which is precisely the case that degrades a binary search tree to a linked list. There is no complexity row for an unbalanced tree anywhere in the section.

The consequence is concrete for an interview. A candidate who recalls the table will state O(log n) for a tree that was built from already-sorted input, and an interviewer who knows the tree is degenerate will hear a wrong answer delivered confidently. The fix is one sentence the entry does not contain, and it is the difference between knowing the data structure and knowing its contract.

Three unrelated structures share the same four rows

Read the linked list, stack and queue entries side by side and the same block appears under all three. Access is `O(n)`, search is `O(n)`, insert is `O(1)` and remove is `O(1)`, in each case. The entries themselves are distinct and correct in their descriptions: a linked list is nodes pointing to the next, with singly-linked, doubly-linked and circular variants; a stack is last in, first out with push and pop; a queue is first in, first out with enqueue and dequeue.

What the repeated table does not say is the precondition. Insert into a linked list is O(1) once you hold a pointer to the node you are inserting after, and O(n) if you have to find that position first, and the entry never distinguishes the two cases. The same applies to removal. Pushing onto a stack is unconditionally O(1), which is a different guarantee from the one the linked list row is quietly relying on.

The consequence is that the table reads as a measurement when it is a template. Study the definitions rather than the rows, and work out for each operation what you already hold a handle to before you claim a cost.

Every external link is undated, and the last push was 2025-05-12

The repository is not archived, and its last push was 2025-05-12. It has never published a GitHub release, so there is no version history and nothing to pin. The README is a set of links, and a set of links with no dates is a set of links you have to check.

The scale of that is worth stating. There are twelve online judges, from LeetCode and HackerRank through Kattis, Codility, CodeChef, Sphere Online Judge and InterviewBit. There are five live coding and mock interview services: The Daily Byte, Pramp, Gainlo, Refdash and Interviewing.io. Then YouTube, Instagram, articles, video lectures, interview books, computer science news and a directory tree section. Not one entry carries a date, a price, a free tier note, or a signal that the service is operating.

The consequence for someone planning three months of preparation is that the list can send you to a service that has changed its name, changed its pricing, or stopped existing, and the file will not tell you which. The dates are the part a maintained list would add first, and their absence is the clearest signal of how this repository should be read.

The top of the file is a referral, not a recommendation

The first line of the README pitches a product with a tracked link, followed by a claim about how many people have used it, and both links carry a referral parameter. The same pattern reappears further down: The Daily Byte appears again under live mock interviews and again under live coding practice, and Pramp's link under live coding practice carries a different referrer code entirely.

Nothing is wrong with a maintainer monetising a list they maintain. It is still information a reader should have while weighing the ordering, because a sponsored entry at the top of a resource list is not the same as the entry a maintainer would have put there otherwise, and the file gives you no way to tell the two apart. There is no annotation separating a paid placement from a free one.

The consequence is that the ranking of resources in this repository carries no information about quality. Treat every entry as an unordered set, and if you are choosing a paid service, price and current status will have to come from the service's own site rather than from this page.

Twelve judges and five mock services, with no criteria for choosing

The online judges section lists LeetCode, Virtual Judge, CareerCup, HackerRank, CodeFights, Kattis, HackerEarth, Codility, Code Forces, Code Chef, Sphere Online Judge and InterviewBit. The live coding section lists The Daily Byte, Pramp, Gainlo, Refdash and Interviewing.io. Each is a name and a URL, and each section is presented as an equivalent set of options.

They are not equivalent, and the list gives you no axis on which to compare them. Some are problem repositories with discussions, some are competitive programming arenas with timed rounds, some are assessment products aimed at hiring, and some are peer-to-peer mock interview marketplaces where the quality of a session depends on who happens to be online. The list also mixes two of these together, since CareerCup sits among the judges while the mock interview services have their own section.

The consequence is that a reader new to interview preparation gets a menu with no guidance, and the choice that actually matters, which problem set matches which company's format, is exactly the information the list does not carry.

The real content is four solution directories, and one is a book

The top level of the repository holds `.DS_Store`, `.gitignore`, `.project`, `LICENSE`, `README-zh-cn.md`, `README.md`, and four directories: `company/`, `cracking-the-coding-interview/`, `leetcode/` and `uva/`, plus `images/` and the Eclipse project files `interviews.iml` and `.project`. The project is reported as Java, and while no Java source sits at the top level, those Eclipse files are how a Java project declares itself.

Two observations follow. The first is that this is a solutions repository with a README attached, not a document, and the README is only one of two, the other being a single Simplified Chinese translation. The second is the `cracking-the-coding-interview/` directory, which is solutions to a published book's problems, sitting in the same MIT-licensed repository as the author's own notes. That is worth knowing before you copy anything from it into a portfolio, and it is also worth noting that the README's table of contents does not link that directory at all.

The `.DS_Store` file is committed at the root, which tells you the repository is maintained by hand on a Mac rather than through a review checklist. Small thing, but it is the kind of detail that predicts the state of the link lists.

The data structures section is the part worth revising from

Setting the links aside, the section is a genuinely useful one-page reference, and its value is that everything uses the same notation. The tree family is laid out in order: a tree is defined as an undirected, connected, acyclic graph, a binary tree has at most two children per node called left and right, and then the three shapes that actually come up in interviews, full where every node has zero or two children, perfect where all interior nodes have two children and all leaves share a depth, and complete where every level except possibly the last is full and the last level is as far left as possible.

After that come the structures with less common coverage. A trie, also called a radix or prefix tree, stores keys as strings where no node holds its own key and position in the tree defines it, with the root associated with the empty string. A Fenwick tree, or binary indexed tree, is a tree in concept but an array in practice, computing parent and child indices with bitwise operations on the binary representation of the index and holding pre-calculated range sums, which is why range sum and update are both `O(log(n))`. A segment tree stores intervals and answers which stored segment contains a given point, at `O(log(n))` for range query and update. A heap is defined by the heap property with a max and min variant, and is the one structure here with an O(1) operation, accessing the maximum or minimum, against `O(log(n))` for insert and remove.

If you revise one thing from this repository, revise this. The definitions are short, correct, and use one consistent set of complexity labels, which is more than most scattered interview notes manage.

Editorial conclusion

Use this repository for the data structures section and treat the rest as a set of starting points to verify. The trie, Fenwick tree, segment tree and heap entries are concise and correct enough to revise from, and having one document that defines the whole family in the same notation has real value. Two things to watch. The complexity table is a template rather than a measurement: the binary search tree row promises O(log n) for all four operations without saying the guarantee depends on balance, and three unrelated structures share an identical set of rows. And every external link is undated, with the last push to the repository on 2025-05-12 and no releases, so nothing in the file tells you whether a judge or a mock-interview service still exists. Before you plan a study schedule around it, check three things: whether a listed service still runs, whether the referral links matter to you, and whether you can derive the complexity of a specific operation rather than recall the row.

Frequently asked questions

Official sources

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