What do you learn by asking a peer engineer to walk one merged change all the way to users?

## The ask Phrase it as a trace of one concrete change, not as a request for a process description: 'Say a change of mine was just approved this morning. Walk me through what happens between then and a user seeing it.' The concreteness matters. Asked abstractly, people describe the process they wish they had; asked as a trace, they narrate the last time it happened, including the parts that annoyed them. ## Why this question is the highest-yield one in a peer round Almost everything a candidate wants to know about daily life is downstream of this path: - **Autonomy** shows up as who is permitted to press deploy. - **Feedback speed** shows up as the elapsed time from merge to production. - **Ownership** shows up in whether the author watches their own change land or hands it to a separate group. - **Blast radius and fear** show up in how a change is taken back out, and in how much ceremony sits in front of shipping. - **Team boundaries** show up as every hand-off to a team the peer does not sit on. You get all of that from one question, from a person who has no incentive to embellish, and the follow-ups write themselves. ## Two sketches, same question For illustration, imagine two platform teams. Both answer the same prompt. **Team A.** Merge triggers automated checks. The change lands in a shared pre-production environment behind a flag. Releases are cut once a week, and a separate group owns the final promotion step. Last week the team merged around 11 changes and cut one release. The author is not the person who promotes it. **Team B.** Merge triggers checks; if they pass, the change promotes itself. The author watches the dashboards for their own change and can take it back out alone. Last week 14 deploys went out, spread across the team. Nothing in either answer is a scandal, and Team A's shape is common and often deliberate — regulated environments and shared infrastructure both produce it. But if you join Team A, the gap between finishing work and learning whether it was right is measured in days, and your name is not on the button. That is a concrete thing to weigh, and you only have it because you asked for the trace instead of asking whether the team has good engineering practices. ## What to listen for **Count the manual steps.** Every human approval is a place your change can wait behind someone else's calendar. **Count the teams.** A path that crosses two other teams means your delivery speed is partly outside your control, which also tells you something about how much of the job is coordination. **Listen for the exception path.** 'And what happens if it turns out to be wrong?' is the other half of the walkthrough. A team that answers instantly with a specific mechanism has practised it; a pause before the answer usually means it is rare, manual, or someone else's job. **Listen for what the peer volunteers.** People add complaints to a walkthrough unprompted. The step they sigh about is the step that hurts. ## Good follow-ups, in order 1. 'How long did that take for your last change?' — turns the map into elapsed time. 2. 'Who can trigger that step?' — turns it into autonomy. 3. 'How often does a change get stuck at one of these steps?' — turns it into a frequency rather than a possibility. 4. 'Which step would you delete if you could?' — the peer's own diagnosis, freely given, and a good note to compare against the hiring manager's answer later. ## Common misreads More automation is not automatically better; a mature manual gate can be a considered response to real risk, and a fully automatic path with no observability is worse than a slow one with good rollback. Read the shape, not the score. Equally, do not treat one peer's account as the team's truth — ask a second interviewer the same question, and treat any disagreement between them as the interesting result rather than a contradiction to resolve on the spot. ## Why it lands well The walkthrough is also the question that makes you sound like someone who has shipped things. It is specific, it is about the work, and it invites the peer to talk about something they know intimately, which usually turns the last minutes of the round into an actual conversation rather than a formality.