Rhymium

Four steps, in order

01. Start where you actually are

The first track assumes you can write code and nothing else. If you already know what a quorum read costs, skip to track four — every module lists what it expects you to know.

02. Read a little, then argue

Concepts are introduced briefly, because reading about consistency is not what makes it stick. The drill at the end of the module is where the learning is.

03. Work the case studies out loud

Six systems, worked end to end. Do them narrating, at a whiteboard, against a clock. That is the format you will be tested in, so it is the format to practise.

04. Run the loop

Question bank, mock rounds with the community, and a tracker that remembers what each company asked. The last track is about the forty-five minutes themselves.

What a module looks like

The same four parts every time, across all 41 of them.

A short read

Enough to name the thing and say what it costs. Not a textbook chapter — reading about consistency is not what makes it stick.

A worked example

The same idea inside a system that already exists, with the numbers written out.

A drill

Where you choose, and where the choice costs you something. Every module ends in one.

A link forwards

To the module that depends on this one. The order is a dependency graph, not a list.

The last track

The interview is a performance with a shape

Knowing the material and passing the round are two different skills, so the eighth track is about the forty-five minutes themselves rather than about any system.

Scope it

Eight minutes of questions that narrow an intentionally vague prompt into something buildable.

Draw it

Data flow first, then boxes, then the API. Narrated the whole way, because silence reads as not knowing.

How this works

Four steps, in order

What a module looks like

The interview is a performance with a shape

Frequently asked questions

Track one assumes nothing but that you can write code.