What a pairing interview looks like

Someone else's code, on a call, with a clock running

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 to "here's PriceCalculator: it works, but a new coupon type needs to slot in without breaking anything that already passes." Nobody asks her to invent an algorithm from nothing. They hand her a working system and watch what she does with it.

# config/routes.rb
resources :invoices, only: [:show]

# app/controllers/invoices_controller.rb
class InvoicesController < ApplicationController
  def show
    @invoice = Invoice.find(params[:id])
    @total = PriceCalculator.calculate_price(@invoice.line_items, @invoice.coupon)
  end
end

What the interviewer is quietly grading

Correctness is table stakes: the tests still have to pass at the end. What separates candidates at this level is how they read code they didn't write and how they organize the change once they understand it. It is also how clearly they communicate a plan before typing, and how they take a hint or a correction without losing the thread. Edge cases matter too: an empty invoice, a coupon that doesn't match any known type, a discount that would push a total below zero. A strong pleno candidate names these out loud before the interviewer has to point them out.

Driver, navigator, and the questions in between

Some interviewers keep you as the sole driver for the whole session. Others swap who's typing halfway through, handing you the navigator seat while they write the next piece themselves. Both formats test the same thing from a different angle: when you're driving, can you narrate a decision before you commit to it. When you're navigating, can you read someone else's half-finished change and suggest the next step without reaching for the keyboard. Either way, expect a running stream of "why" questions. Why a case instead of another elsif, why extract this piece and not that one, why test this edge case first. The question isn't a trap: it's the interviewer checking whether your choice was deliberate or just the first thing that came to mind.

The format varies, the substance stays the same

The actual setup differs company to company: some run the session in a shared, browser-based editor with no local environment at all. Others send you a real repository beforehand and pair over a video call while you both look at your own clone. A shared editor favors speed, since there's nothing to configure. A cloned repo favors realism, since you're working with your own terminal and your own test runner rather than someone else's sandbox. Neither format changes what's being measured underneath it. Whether the code lives in a browser tab or a terminal window, the rules are the same: the same clock, the same tests-green baseline, and the same expectation that you narrate your reasoning.

Two phases: reading, then changing

Most sessions split into a short reading phase and a longer execution phase. In the reading phase you ask questions, run the existing suite once to confirm it's green before you touch anything, and skim the surrounding structure. What calls this method, what tests already exist for it. In the execution phase you work in small steps, keep the suite green between each one, and narrate as you go. A 45-to-90-minute session doesn't leave room for a long silent stretch in either phase. An interviewer who sees you thinking for two full minutes without a word will usually ask what you're weighing.

When the ask changes mid-session

Some interviewers introduce a new requirement partway through ("from now on, the coupon can be a percentage over 100, so cap it at 100"). They want to see whether your design absorbs the change cleanly or forces a rewrite. A codebase that was refactored into small, named pieces absorbs that kind of change in one line. A codebase left as one long tangled method usually doesn't, and the interviewer is watching for that difference.

The theme interviewers keep repeating

Interview debriefs keep coming back to one point. Candidates who make the tests pass but leave the code as tangled as they found it get marked down at pleno level, even when every assertion is green. The bar isn't "did it work". It's "did you leave this in better shape, or at minimum say out loud which seams you'd extract if you had another twenty minutes." You don't have to extract everything in the time given. You do have to name what you'd extract.

Design mini-questions in the same session

Some pairing sessions fold in a smaller design question ("how would you add a notification preference to a user's account?") that tests something slightly different. Can you name the entities involved and decide out loud whether the logic belongs in a model, a service object, or a controller? Can you say what you'd test first and what you'd defer? Lesson 6 in this course is built entirely around that kind of question. For now, just notice that a pairing interview and a design question are close cousins, not separate skills.

Pairing in English, remotely

Camila's interview runs in English by default (most remote roles work that way regardless of where either person lives) and narration matters more here than accent ever will. If you've taken the intern-level "Live coding for beginners" or the junior-level "Live coding and take-home projects," you've already practiced thinking out loud under a clock. This course assumes that habit and spends its time on harder material instead. Asking for thirty seconds of silent reading before you start talking is completely normal, in English or in Portuguese.

Where this course goes

This course builds directly on "Mid-level Rails interview questions," the course before it. It assumes you already reason about trade-offs and can defend an answer, and spends its lessons putting that to work live, with a keyboard in front of you. Lesson 2 covers reading unfamiliar code fast: starting from the route, reading tests as documentation, and writing down the questions you'd ask before changing anything. Lesson 3 covers refactoring with the tests green: characterization tests, small steps, and where extracted logic goes in a real Rails app. Lesson 4 puts both to work on PriceCalculator itself, and carries this course's one coding challenge. Lesson 5 covers explaining trade-offs out loud, lesson 6 covers designing a small feature on the spot, and lesson 7, a full pairing session, puts all of it together.