An Extensive Reference of Commonly Used Algorithms

Mastering Algorithms is a free, structured guide to the algorithms and data structures that actually come up — in coursework, in technical interviews, and in production code. It covers 36 topics across nine areas, each with a plain-language explanation, a complexity analysis, a worked example traced step by step, and Python you can run.

What distinguishes it is the verification. Every code listing on this site is executed before it is published. Sorting algorithms are tested against Python's own sorted() across thousands of randomised inputs; pattern-matching algorithms are checked against brute force; the neural network's backpropagation is validated against numerically estimated gradients. Every worked example is traced from the algorithm printed on the same page, so the numbers in the walkthrough are the numbers the code actually produces.

That sounds like a low bar. It is not one most algorithm tutorials clear — and when a trace is wrong or an implementation does not match its stated complexity, the reader who is trying hardest to follow along is the one who gets stuck. In August 2026 the entire site was re-audited line by line and 58 corrections were applied. You can read more about that process on the about page.

What's Covered

What Each Chapter Gives You

• A plain-language explanation of what the algorithm does and why it works, before any code appears.
• Pseudocode and runnable Python. Pseudocode for the idea, Python for the details — tested, not just typed.
• Complexity analysis for time and space, including the cases where the stated bound depends on the implementation shown.
• A worked example traced step by step, generated from the algorithm on that page.
• The failure modes. Where an implementation breaks — negative numbers, duplicate keys, adversarial input — the limitation is stated rather than skipped.
• History and context. Who invented the algorithm, when, for what problem, and how it fits into the broader story of computing.
• Common misconceptions called out explicitly — the things that everyone learns wrong the first time, corrected before they become bad habits.
• Practice problems linked to the relevant LeetCode exercises, with the pattern explained rather than just the answer.

Editorial Standards

The material on this site is written and maintained by one author with a background in computer science, working from primary sources: the original papers where each algorithm was first published, the CLRS textbook for canonical presentations, the source code of production implementations where relevant. Every chapter goes through a review process before publication:

1. Every code listing is executed. Not just syntax-checked — actually run against representative inputs. Sorting algorithms are tested against Python's sorted() across thousands of randomised arrays. Graph algorithms are tested against known-correct implementations from NetworkX. Pattern-matching algorithms are tested against brute-force baselines. Nothing goes on the site until the code produces the correct output.
2. Every worked example is traced from the actual algorithm. When a chapter says "here is what happens step by step," the trace is generated from executing the code on that page — not written from memory or copied from elsewhere. If the code changes, the trace changes with it.
3. Every complexity claim is checked. A quoted O(n log n) is checked against the specific implementation shown, which sometimes reveals subtleties — a recursive implementation using O(log n) stack space, an in-place variant that trades constants for asymptotic bounds, a "linear time" claim that hides a factor of the alphabet size.
4. Every historical claim is cited. Dates, names, and attributions come from primary sources or well-established secondary references (CLRS, Knuth's TAOCP, the ACM Digital Library). Where competing claims exist — and cryptography is full of them — the site names the competing accounts and explains which is currently accepted.
5. The site is periodically re-audited. In August 2026 a full line-by-line correctness audit was performed, resulting in 58 corrections across the site. The corrections were substantial: they included fixing a Timsort implementation that did not actually detect runs, cryptography guidance that predated TLS 1.3, and several worked examples whose arithmetic did not follow from the algorithms above them. That kind of audit will be repeated periodically.

If you find an error — a code bug, a wrong complexity, an example that does not match the algorithm, a factual claim that is out of date — please let us know. Every reported error is verified and, if confirmed, corrected quickly. The about page has more on the process.

What This Site Is Not

To set expectations honestly:

• It is not a course. There are no video lectures, no interactive exercises, no autograder. It is a reference designed to be read and returned to, more like a good textbook than a MOOC. If you want an interactive learning experience with feedback, this is not that.
• It is not a competitive programming training site. The material touches on interview preparation and links to LeetCode problems, but it is not organised around a training plan. For that, use LeetCode, Codeforces, or a dedicated competitive-programming resource like USACO Guide.
• It is not comprehensive. 36 topics is a lot, but it is a small fraction of the space. Some important areas — parallel algorithms, distributed algorithms, approximation algorithms, quantum algorithms, computational geometry beyond the basics — are not covered. Where a topic is out of scope, the site does not pretend otherwise.
• It is not a substitute for reading the primary sources. Every chapter links to relevant original papers where appropriate. If you are working on something serious, read them.

Where To Start

The chapters are ordered so each builds on the last, but nothing stops you jumping straight to what you need.

• New to algorithms? Begin with the introduction, then complexity analysis — almost everything else assumes it.
• Preparing for interviews? Trees, graphs and dynamic programming are where most of the questions live.
• Looking something specific up? The chapter index lists all 36 topics.

How To Read These Chapters

Every chapter follows the same rough shape, and knowing that shape upfront makes it easier to find what you need on a page you have not read before.

1. An overview that describes what the algorithm does and what problem it solves, without any code. If you are trying to remember the general idea, you can stop after this section.
2. Historical context — who invented the algorithm, when, and what problem they were solving. This section often reveals design decisions that are otherwise hard to justify (why does DES have 56-bit keys? why is bubble sort called that? why did NIST hold a competition to choose AES?).
3. A structural explanation of how the algorithm works, with clear diagrams or step-by-step traces where they help.
4. Pseudocode that captures the algorithm's essence without language-specific noise.
5. Runnable Python that has been executed and tested against reference implementations.
6. Complexity analysis covering time and space, best/average/worst cases, and the subtleties (like when a stated bound depends on the implementation choices shown).
7. Variants and cousins — related algorithms, common optimisations, and when to reach for each.
8. Common misconceptions called out explicitly. These are the things people get wrong the first time, corrected before they become bad habits.
9. When to use it, and when not to — an honest opinionated recommendation about where the algorithm fits in the modern toolkit.
10. Related links to other chapters that build on or contrast with the current one.

For interviews and study, we recommend reading the overview, complexity, and misconceptions sections thoroughly, then coming back to the history and variants when you have time. For practical work, the "when to use it" section is usually the highest-value part.

About the Site

Mastering Algorithms is written and maintained by a single author with a background in computer science and a specific interest in the details that get elided in most introductory treatments. The site started as a personal reference — a place to write down the things I found myself repeatedly looking up — and grew into a public resource as the material accumulated. The editorial voice is deliberately consistent: opinions where they matter, historical context where it illuminates, and honesty about the limits of each algorithm.

Corrections and topic suggestions are welcome. See the contact page for how to reach me. Every reported error is verified before being applied, which sometimes takes a few days, but every genuine correction eventually lands on the site.