Tracks
A track is a list of terms in the order they make sense in. Work down it and tick off what you already know; what you have ticked stays in this browser.
Guided paths
Built around a situation rather than a subject, so they pull terms from wherever the situation does.
- 33 terms · Mixed
Start here
The vocabulary almost every engineer meets, whatever they work on. Thirty-three terms, beginning with the ones you have already run into without knowing they had a name.
- 53 terms · Frontend & browser
Frontend
The browser's vocabulary, from the cascade to the render loop to the numbers a review will hold you to.
- 53 terms · Backend & systems
Backend
Servers, storage and the failures between them, in the order the vocabulary becomes load-bearing.
- 56 terms · Platform & DevOps
DevOps
Containers, orchestration, infrastructure as code, delivery and the bill — the platform vocabulary in the order it becomes load-bearing.
- 55 terms · Data engineering
Data Engineering
Where the numbers come from and what shapes them: ingestion, orchestration, modelling, storage and the machinery for knowing it is wrong.
- 53 terms · Applied AI
AI Engineer
Everything between calling a model and running one in production: tokens, prompts, retrieval, tools, evals, cost and the security boundary.
- 57 terms · Architecture & practice
Software Architecture
The words senior engineers argue in: structure, complexity, risk, decisions, migration and the shape of the team underneath it all.
- 58 terms · Design patterns
Design Patterns
Objects, SOLID, the Gang of Four catalogue, persistence and domain modelling, and the named ways all of it goes wrong.
Applied AI
12 topics · 243 terms- 01 · 32 terms
How models work
The mental model. You do not need the maths, but you need to know what a model is, how it was made, and why it behaves the way it does. Read this section once before writing any code, then come back when a term resurfaces.
- 02 · 13 terms
Tokens
Tokens are the unit of everything: cost, latency, context limits and most odd model behaviour. Internalise this section and half the API layer explains itself. Pair with scripts 1 to 3.
- 03 · 30 terms
The API layer
The layer you will live in. It is ordinary HTTP and JSON with a handful of new parameters and failure modes. Pair with scripts 1 to 3, and type these calls yourself at least once without an SDK.
- 04 · 15 terms
Prompting
Prompting is interface design for a probabilistic component. The vocabulary is small but heavily used, and most of it is about being unambiguous.
- 05 · 16 terms
Structured outputs and tool calling
The bridge between free text and code you can actually run. This is the most-used capability in production LLM features and the subject of scripts 4 and 5.
- 06 · 27 terms
Embeddings and retrieval
How machines compare meaning, and how relevant knowledge gets into the context window. This section backs scripts 6 and 7, and as a Postgres person you will feel at home: half of it is indexing and ranking.
- 07 · 20 terms
Agents
An agent is the tool loop from section 5 given autonomy, memory and boundaries. The vocabulary here is young and marketing-polluted; the definitions below are the load-bearing ones.
- 08 · 23 terms
Evaluation and reliability
Evals are to LLM features what tests are to code: the only alternative to superstition. This vocabulary backs script 8 and will dominate any serious applied AI interview.
- 09 · 16 terms
Fine-tuning and customisation
Changing the weights instead of the prompt. Reached for less often than newcomers expect: the decision rule comes first, the techniques after.
- 10 · 20 terms
Local and self-hosted inference
Running models on hardware you control: your M1 Air, your Hetzner box. The vocabulary of memory budgets and speed, and the domain where your infrastructure instincts pay off directly.
- 11 · 14 terms
Security and safety
New attack surface, old discipline. The core fact: the model reads instructions and data through the same channel, and everything here follows from that.
- 12 · 17 terms
Production patterns and cost
Where LLM calls meet the disciplines you already run: caching, routing, failover, budgets and logging. Almost every pattern here is a backend pattern with tokens flowing through it.
Backend & systems
13 topics · 223 terms- 01 · 18 terms
Caching and invalidation
Caching is the cheapest performance win available and the easiest way to serve confidently wrong data. Almost every term here is really about the second half of the problem: knowing when the copy you kept has stopped being true.
- 02 · 24 terms
Data modelling and storage engines
How rows are laid out on disk decides which queries are cheap, and no amount of application code recovers from getting it wrong. This is the layer where a decision made in week one is still costing you in year three.
- 03 · 17 terms
Transactions and isolation
Everybody says ACID in interviews and almost nobody can name the anomaly their isolation level still allows. The vocabulary here is precise on purpose: the words are the difference between a bug you can reason about and one you cannot reproduce.
- 04 · 20 terms
Consistency and replication
The moment there is more than one copy of the data, you are choosing which lie to tell and to whom. These are the words for those choices, and for the failure modes that follow from them.
- 05 · 18 terms
Queues, streams and delivery semantics
Async is how backends stop being one long synchronous call. The delivery guarantees are the part people quote wrong most often, and the part that decides whether your consumer needs to be idempotent.
- 06 · 19 terms
Concurrency and coordination
Two things happening at once, and the machinery for making that safe. Most of these bugs are invisible under test load and obvious at 3am, which is exactly why the vocabulary matters.
- 07 · 18 terms
Resilience and failure handling
Dependencies fail; the question is only what your service does about it. These are the named patterns for degrading on purpose instead of collapsing by accident.
- 08 · 18 terms
API and interface design
The contract is the part you cannot refactor unilaterally, because somebody else's code is holding the other end. Most of this section is about changing things without breaking callers.
- 09 · 15 terms
Deployment, release and rollback
Shipping is a separate discipline from writing the code, and the vocabulary reflects it: nearly every term here exists to separate the act of moving bytes from the act of exposing behaviour.
- 10 · 16 terms
Observability and operations
You cannot fix what you cannot see, and you cannot see anything under an alert storm. This is the language of knowing what your system is doing and agreeing how good it has to be.
- 11 · 13 terms
Scaling and load management
What happens when you multiply the traffic by ten. Half these terms are about adding capacity, and the more useful half are about what to do when you cannot add it fast enough.
- 12 · 19 terms
Security and identity
The security vocabulary a backend engineer actually needs at the interface: who is calling, what they are allowed to do, and which of those two questions you just answered.
- 13 · 8 terms
Testing and test doubles
The four words for fake collaborators get swapped constantly, including by people who wrote the tests. Naming them correctly is the fastest way to make a test review argument short.
Frontend & browser
13 topics · 271 terms- 01 · 25 terms
Rendering and the browser pipeline
Everything between the bytes arriving and a pixel changing on screen. Most frontend performance arguments are really arguments about which stage of this pipeline a change lands in, which is why naming the stages is worth more than any single trick.
- 02 · 28 terms
Layout, CSS and the cascade
The half of the job people claim is easy and then spend an afternoon on. Almost every mysterious CSS bug is one of six ideas here — a context you did not know you created, or a rule that won for a reason you did not check.
- 03 · 29 terms
JavaScript in the browser
One thread does the layout, the paint and your code, and it can only do one of them at a time. These are the words for what that thread is doing, in what order, and why the interface stopped responding while it did it.
- 04 · 28 terms
State, data and re-rendering
Where the data lives, who owns it, and what happens on screen when it changes. Most component bugs are ownership bugs wearing a costume, and most of the fixes have names that make the argument short.
- 05 · 29 terms
Modules, bundling and the build
The pipeline that turns a few hundred source files into the handful of files a browser downloads. Everything here is about shipping less code, or about shipping the same code in a way the browser can keep.
- 06 · 15 terms
Loading, assets and the critical path
Byte order matters as much as byte count: the same page can feel instant or broken depending on what the browser was told to fetch first. This is the vocabulary of that ordering, and of the assets that most often get it wrong.
- 07 · 18 terms
Performance and Core Web Vitals
The metrics are not the point; they exist because 'the page feels slow' is not actionable and 'the largest element paints at 4.2 seconds' is. Learn which number moves when you fix which thing.
- 08 · 15 terms
The network from the browser
The browser is not a HTTP client you control. It has its own rules about what you may request, what you may read back and what it will quietly cache, and those rules are the source of most requests that work in curl and fail in the tab.
- 09 · 19 terms
Browser security
Your code runs on someone else's machine, next to someone else's script, holding someone else's session. These are the attacks that follow from that and the browser features that exist to blunt them.
- 10 · 22 terms
Accessibility and semantics
The interface as it reaches someone not using a mouse and a pair of eyes. Nearly all of it comes down to two questions the browser is already asking your markup: what is this thing, and what is it called.
- 11 · 14 terms
Routing and navigation
The moment an application takes the address bar away from the browser, it inherits everything the browser was doing for free. This is the list of what it inherited, most of which gets rediscovered as a bug report.
- 12 · 15 terms
Storage and platform APIs
The browser's own standard library: four ways to keep data on the device and a set of observers that answer questions a scroll handler used to answer badly. Picking the right one is usually a question about lifetime.
- 13 · 14 terms
Testing a user interface
The pyramid arguments are stale but the vocabulary is not, because the words decide what a failing test actually tells you. The recurring theme is testing what the user does, not how the component does it.
Architecture & practice
10 topics · 177 terms- 01 · 25 terms
Design, structure and tradeoffs
The words for why one arrangement of the same code is better than another. Almost every design review disagreement is one of these ideas being felt by one person and named by nobody, which is why the argument goes in circles until someone says the word.
- 02 · 18 terms
Complexity and how it accumulates
Nobody decides to build a mess. It arrives one reasonable decision at a time, and the vocabulary here exists to make a single one of those decisions arguable while it is still being made rather than two years later.
- 03 · 15 terms
Risk, blast radius and change
Senior engineers are not more cautious than everyone else; they are more specific about what could go wrong and how far it would spread. These are the terms that turn 'this feels risky' into a claim someone can agree or disagree with.
- 04 · 15 terms
Making and recording decisions
How a group of people who disagree arrive at one design and leave a trail explaining why. Most of the pain of joining a codebase is that these documents were never written, so the reasons are gone and only the consequences remain.
- 05 · 14 terms
Legacy systems and migration
Almost nobody starts from nothing. This is the vocabulary of changing something that is already running and already has users, where the hard part is never the new code but the six months where both versions exist.
- 06 · 17 terms
Teams, ownership and Conway's law
The architecture and the org chart are the same drawing. Once you can name the shapes teams come in and what each one is for, half of the arguments that looked technical turn out to be arguments about who owns what.
- 07 · 20 terms
Delivery, flow and technical debt
How work moves from someone's head to production, and what slows it down. The measurements here exist because 'we are moving slowly' is not actionable and 'a change takes nine days to reach production, of which eight are waiting' is.
- 08 · 18 terms
Estimation and planning
The part of the job where engineers are asked to say something confident about the future. These terms will not make your estimates right, but they will let you say precisely why they are wrong, which is what the conversation actually needs.
- 09 · 19 terms
Incidents and what happens after
The vocabulary of a bad afternoon and the review that follows it. Most of it exists to keep two things apart: stopping the bleeding and understanding the cause, which are different jobs done by different people at different times.
- 10 · 16 terms
Judgement and reasoning traps
The named ways that competent people talk themselves into the wrong answer. Knowing them is not about winning arguments; it is about noticing, mid-sentence, that the thing you are about to say is one of these.
Data engineering
8 topics · 203 terms- 01 · 26 terms
Moving data out of the source
Every pipeline starts with somebody else's database that was never designed to be read by you. This is the vocabulary of getting rows out of it repeatedly, without asking permission each time and without melting the thing you are reading from.
- 02 · 25 terms
Time and correctness in streams
Batch has one clock. A stream has two, and almost every confusing streaming bug is the gap between them: the moment something happened and the moment your code found out. These are the words for that gap and for what you are allowed to do while you wait.
- 03 · 29 terms
Modelling for analysis
A warehouse schema is a user interface for people writing SQL under time pressure. The vocabulary here is thirty years old and still the fastest way to settle an argument about why a dashboard is double-counting.
- 04 · 32 terms
Files, formats and table layers
Underneath every lakehouse is a folder of files, and most of its performance and most of its failures come from how those files are written. Knowing these words is the difference between tuning a query and guessing at one.
- 05 · 27 terms
Orchestration and running it in anger
The code is the easy part. This is the vocabulary of the thing that runs it every night, of what happens when one run fails, and of finding out what else is now wrong because it did.
- 06 · 19 terms
Quality, tests and knowing it is wrong
A broken service pages you. Broken data does not — it simply arrives, gets averaged into a number and shows up in a board deck. These are the terms for catching it first, and for the conversation after you did not.
- 07 · 22 terms
Governance, privacy and meaning
Two people quote different revenue figures and both are right, because the number was defined twice. Half of this cluster is about that; the other half is about the rows you are legally not allowed to keep.
- 08 · 23 terms
Cost, layout and query performance
Warehouse compute is billed by what you read, so data layout is a budget decision rather than a tuning detail. These are the words for why one query costs pennies and the same answer costs four hundred pounds.
Platform & DevOps
9 topics · 204 terms- 01 · 27 terms
Packaging: containers and images
A container is a much smaller idea than it looks: a normal process, lied to about what it can see. These are the words for the artefact you build, the layers it is made of and the kernel features that make the isolation real.
- 02 · 19 terms
The orchestrator's model of the world
You stop telling the machine what to do and start telling it what you want, and something else spends the rest of the day closing the gap. Almost every surprising thing an orchestrator does follows from that one swap, and this is the vocabulary of it.
- 03 · 22 terms
Placement, resources and the pod lifecycle
Every workload is a request for someone else's CPU and memory, arbitrated by a scheduler that will happily tell you no. This cluster is what those numbers actually mean, why a workload will not start, and how one gets killed.
- 04 · 23 terms
Traffic into and inside the cluster
The moment there is more than one instance of anything, addressing stops being a hostname and becomes infrastructure. These are the words for how a packet finds a workload, what is allowed to talk to what, and which of it appears on the bill.
- 05 · 23 terms
Infrastructure described in a file
Writing the infrastructure down is the easy half. The hard half is that the file, the state and the real cloud are three different things that disagree, and this is the vocabulary of that disagreement.
- 06 · 23 terms
Pipelines, promotion and GitOps
Between a merged pull request and a running process there is a machine you did not write, moving an artefact through environments. These are the words for that machine, for what it is allowed to promote, and for who pulls versus who pushes.
- 07 · 28 terms
Running it: capacity, failure and recovery
The service works. Now it has to keep working through a zone going dark, a certificate expiring and a team that has never restored a backup. This is the vocabulary of the layer that has to survive, and of the team whose product is that layer.
- 08 · 23 terms
Secrets, identity and the supply chain
Every workload needs credentials it must never contain, and every artefact you run came from somewhere you did not watch. These are the words for handing out identity that expires and for proving where a build came from.
- 09 · 16 terms
What the platform costs
Cloud bills are a delayed, aggregated, badly labelled log of engineering decisions. These are the terms for reading it, for the three prices the same machine has, and for the charges nobody predicted.
Design patterns
10 topics · 201 terms- 01 · 32 terms
Objects, messages and the principles
Before any pattern there is a smaller question: what is one object allowed to know about another. Almost every named pattern is an answer to it, and almost every argument in a code review is really about it.
- 02 · 16 terms
Making things
Construction looks like the boring half until the constructor has nine arguments, the object is half-built for a moment, or two tests fight over the one instance. These are the patterns for deciding what gets built, by whom, and when.
- 03 · 17 terms
Wiring: injection, containers and lifetimes
Somewhere a decision gets made about which concrete thing your code actually gets, and the whole testability of a codebase turns on where that somewhere is. This is the vocabulary of moving it out of the class and into one place.
- 04 · 14 terms
Wrapping and composing
Four of these patterns are the same shape — an object that holds another object and forwards to it — and they are the four people mix up most. The difference is never the diagram; it is why the wrapper exists.
- 05 · 19 terms
Who calls whom, and when
These are the patterns about the flow of control rather than the shape of the objects: swapping an algorithm, reacting to a change, turning a request into a thing you can queue, undo or log.
- 06 · 16 terms
Objects and the database between them
Objects have identity, references and behaviour; rows have keys, foreign keys and no behaviour at all. Every pattern here is a different position on how much of that gap to hide, and what each choice costs you later.
- 07 · 16 terms
Modelling the domain
The words a team uses when it stops arguing about frameworks and starts arguing about what an order actually is. These are the pieces a domain model is built from and the failure it decays into.
- 08 · 19 terms
The shape of the whole application
Zoomed all the way out, an application is a small number of regions and a rule about which way the arrows between them may point. These are the named shapes, and the differences between the ones people use interchangeably.
- 09 · 25 terms
Functional ideas that went mainstream
Most of these arrived in ordinary object-oriented codebases without the theory attached, and they are now said in reviews by people who have never written a line of Haskell. This is what they mean when they are.
- 10 · 27 terms
The named ways it goes wrong
A pattern gives a good arrangement a name so it can be asked for. An anti-pattern gives a bad one a name so it can be pointed at without the argument starting from scratch, which is most of what these are for.