Most CS fundamentals answers link to a runnable mini-project

The two halves point at each other

The pitch is that you can answer, run and measure computer science fundamentals. Two parts make that work.

The quiz is multiple choice with five alternatives, in English, Portuguese and Spanish. The detail that makes it different from a trivia app is what happens after you answer: the explanation appears next to the question, covering the concept itself, why the right alternative is right, why each of the others is wrong, and a link to the mini-project that shows the idea running.

So a wrong answer is not just marked wrong. You get an explanation of the specific mistake you made, because the distractors are the misconceptions and each one is addressed.

The mini-projects are the second half. Small programs that make one concept observable, each with tests, a demo or a benchmark, and documentation in all three languages.

Three examples in the introduction show the intent. A race condition that loses updates and four ways to fix it. A B-tree that reads three pages where a binary tree reads sixteen. A SQL injection and the query that stops it.

Those three are chosen well, incidentally. Each one is a claim you can check rather than believe, and the page counts are the kind of specific number that makes a data structure argument land.

Everything runs in Docker, and the README states the consequence plainly: the only requirement is Docker. This also means a beginner can use Docker without installing each language runtime separately.

Thirty-two areas, and the table is the syllabus

Each area has a quiz and, except for the two theory-only ones, a folder under `projects/` with its mini-projects and study references. The table lists what each area demonstrates.

The foundations come first. Big O and algorithm analysis covers measuring a function and naming its growth curve, the master theorem, and why comparison sorts cannot beat n log n. Algorithms covers the same six sorts in seven languages, dynamic programming, where brute force stops, and hybrid quicksort. Data structures covers a hash map from scratch, graph algorithms, a B-tree on disk, LRU cache, Bloom filter, trie and balanced trees.

Then systems. Operating systems covers CPU scheduling, paging and the TLB, memory allocators, deadlock detection and a mini shell. Networks covers reliable delivery over a lossy channel, a mini TCP, ALOHA and CSMA/CD, a DNS resolver and subnets. Databases is marked theory in its name and covers a mini relational engine with three join algorithms plus a normalisation tool. Transactions covers isolation levels and their anomalies, overselling under load, what an ORM costs, and the outbox and saga patterns.

Then the areas most curricula treat as chapters in a book. Concurrency covers a counter race with four fixes, dining philosophers and ten thousand connections on three runtimes. Parallelism covers speed-up by cores and Amdahl's law. Security is described explicitly as defensive, local-only labs covering SQL injection, XSS and CSP, CSRF, access control, SSRF, passwords and sessions, JWT and uploads.

The lower half is applied engineering. Compilers, state machines, information theory, digital logic, OOP, functional programming, design patterns and SOLID, software architecture, testing, protocols, messaging, load balancing, performance, cache, rate limiting, file systems, observability, blockchain, continuous integration, and artificial intelligence and LLMs.

Two areas have no mini-projects and are marked theory only: electronics with a 170-question quiz and software engineering with a 150-question quiz.

The stated totals are 32 quizzes with 3,384 questions, each in three languages and each with a theory summary to read before answering, and 86 mini-projects.

A bun workspace with separate quiz and benchmark tooling

The repository root is a TypeScript and bun workspace, and the scripts in package.json show how the two halves are validated.

"workspaces": [
  "benchmarks",
  "quiz",
  "tools/*"
]

Four workspaces, which map to the four top-level directories of the same names plus `projects/` for the content itself.

The quiz has three scripts. `quiz:validate` runs a validation script, `quiz:blind` runs a blind script, and `quiz:compare` runs a comparison script. The names say what they do: content is validated, then reviewed blind, then compared. A quiz bank is only useful if the questions are right and the distractors are wrong for the right reason, and building scripts for that is a better use of automation than checking file formats.

Benchmarks are separated into their own workspace with a `bench` script pointing at a CLI under `tools/bench/`, and scaffolding lives at `tools/scaffold/` with a `new:project` script, which is how a new mini-project is created with the right structure. There is also a `dashboard:css` script pointing at a separate entry point.

`docs:index` generates the status page from the repository rather than maintaining it by hand, which is why the README calls the live status generated from the repository itself. A generated status page makes its repository-derived status easier to check.

Type checking runs across all four TypeScript projects, and the toolchain is deliberately mixed: biome for linting and formatting, markdownlint-cli2 for Markdown, TypeScript 7.0.2 and bun types. There are also per-language format configs at the root, ruff.toml for Python, rustfmt.toml for Rust and.clang-format for C, matching the range of languages the mini-projects use.

The status page and the roadmap are the honest part

Two mechanisms in the repository deal with the failure mode every large study repository has, which is claiming more than it has.

The first is the generated status page. The README states the live status of every area, covering questions written, blind review and mini-projects done, is generated from the repository itself, and points at `docs/en/README.md` for it.

Three separate numbers per area is a better model than one. Questions written can be high while blind review is low, which tells you the content exists but has not been checked. Mini-projects done tells you whether the runnable half exists. A single completion percentage would hide exactly the distinction that matters.

The second is `PLAN.md`, which the README describes as holding the full roadmap with the acceptance criteria that were checked. Acceptance criteria that were checked, rather than promised, is the useful phrase.

The claim in the README is that every area is finished, with the 32 quizzes, 3,384 questions and 86 mini-projects all complete.

That is a claim worth testing rather than accepting. Work on the project started in October 2026, and all three releases are dated 2026-10-10, with v1.0.0 labelled ci-pipeline, every area complete, and v1.0.1 and v1.0.2 as fixes. So the whole corpus was produced inside a short window and then labelled version 1.0.0 on the day it was finished.

That is not a reason to skip it. It is a reason to sample before committing an afternoon to it, and the status page exists precisely so you can.

It was written with Claude Code, and that is stated up front

One paragraph in the introduction addresses how the content was produced, and it is more disclosure than most study repositories offer.

The README states that work on the project started in October 2026, that it was written with Claude Code using Claude Opus 5.5, and that it was reviewed by its author.

That distinction matters for how you read the material. Generated explanations of a concept are usually correct and occasionally confidently wrong, and a reviewer who has not independently checked each of 3,384 questions will not catch every bad distractor. The repository also carries an `AGENTS.md` and a `CLAUDE.md` at the root, and a `.claude/` directory, so the agent configuration is part of the project rather than a hidden step.

For a learning resource, the practical advice is to treat the explanations as a first pass and verify against the mini-project. That is not a criticism of the format; it is what the format is good at. The code you run either demonstrates a B-tree reading three pages or it does not, and that check is independent of whoever wrote the prose.

The project is MIT licensed and has Conventional Commits and SemVer badges, so its own history follows the conventions it teaches in the software engineering area.

Editorial conclusion

Adopt this repository as a structured self-study path if you want each definition tied to a program you can run and measure, and read it in your own language since everything is in English, Portuguese and Spanish. Skip it if you learn better from books or videos, since it is a reference rather than a curriculum with sequencing pressure. Verify first that Docker works on your machine, because the README states it is the only requirement, and check the status page to see which areas are actually complete rather than assuming from the table.

Frequently asked questions

Official sources

1. AlexGalhardo/computer-science-fundamentals on GitHub
2. License: MIT
3. Project website
4. README
5. Releases