Live coding: design and refactor sessions
This course works through live coding sessions built around Rails code someone else wrote. It starts with how a mid-level pairing interview is structured, then covers reading unfamiliar code from the route inward, using tests as documentation and grepping for every caller. It moves on to refactoring with characterization tests and small named steps, applied to a tangled PriceCalculator method. Later lessons cover explaining trade-offs out loud, handling pushback and designing a small tax feature with a service object. A final lesson replays one full session.
What you'll learn
- ✓Reading unfamiliar Rails code from the entry point inward
- ✓Writing characterization tests before changing legacy code
- ✓Refactoring in small named steps with the tests green
- ✓Explaining trade-offs and responding to pushback out loud
- ✓Designing a small feature with a service object and a typed Result
What a pairing interview looks like
A pleno-level pairing interview rarely hands you a blank file. Camila, a pleno Rails developer interviewing for a remote role with a company based in Europe, gets a screen share instead. A small invoicing repository, already cloned, its test suite already green. The interviewer says something close…
Read the full lesson free →Curriculum
7 lessonsWhat a pairing interview looks like
How a pairing interview runs: driver and navigator roles, reading and execution phases, and mid-session requirement changes.
Reading unfamiliar code fast
Reading unfamiliar Rails code from the route inward, using tests as documentation, running the suite and grepping callers.
Refactoring with the tests green
Characterization tests, named refactoring moves like guard clauses and extract method, and small steps with commits between green runs.
Refactor to pass the tests
A six-step refactor of a tangled PriceCalculator method, with a coding challenge on discount, clamping, shipping and rounding.
Explaining trade-offs out loud
Framing trade-offs as what a choice buys and costs, knowing when to stop, and answering pushback honestly.
Designing a small feature on the spot
Designing a tax feature on the spot: restating the requirement, naming entities, and placing logic in a service object.
Pairing session: putting it all together
A full 75-minute pairing session replayed phase by phase, from reading the code to flagging open questions.