How should preparation for a staff-level loop differ from preparation for a mid-level loop?

## The allocation rule Preparation should mirror the loop's slot distribution. Write down the round list, weight each slot equally as a first approximation, and spend hours accordingly. This sounds obvious and is very commonly ignored: the default routine — grind problems until the day arrives — is optimal for one level and progressively wrong above it. Using the invented example from earlier, an internal platform group at a national freight carrier runs a five- or six-round day at every rung, with roughly this split: | Rung | Coding | Design / architecture | Past work, influence | Hiring manager | |---|---|---|---|---| | Mid-level | 2 | 1 | 1 | 1 | | Staff (infrastructure) | 1 | 2 | 2 | 1 | At mid-level, two of five slots are coding — spending half your hours drilling is defensible. At staff, one of six is coding and four are scope-shaped. The same routine now spends most of its hours on one-sixth of the day. ## What changes in kind, not just in proportion **Coding.** Shift from sprint to maintenance. One screen still has to go cleanly, and a fumbled staff coding round is a real concern even when it is not decisive, but the marginal return on the fiftieth problem is near zero when the round is a floor check. **Design and architecture.** At mid-level you are preparing to produce a workable design for a bounded system. At staff you are preparing to *compare* designs: name two or three viable approaches, state what each buys and costs, and choose with the constraint you would optimise for said out loud. Breadth matters more than at mid-level — storage choices, failure behaviour, migration paths, operability, cost — because a staff round often drifts to whichever area you seem shakiest on. **Past work.** This is the biggest change and the part candidates most often skip. The preparation is an inventory exercise, not a rehearsal one: list the work of the last two or three years, and for each item write what was ambiguous, what you decided, what you deliberately did not do, who outside your team changed behaviour, and what was true afterwards. Then pull the company's **internal level-ladder document** — many hiring managers will share it if asked, and asking is a good signal — and match each item to a rung's wording. Gaps in the mapping are your real preparation list. **Cross-team influence.** Staff rounds probe how you moved work you did not own. If the inventory produces nothing here, that is worth knowing weeks before the loop rather than in the room. ## The failure mode to avoid The dominant mistake is **running identical preparation at every level**: the same problem sets, the same three rehearsed project summaries, no scope inventory. It produces a specific and recognisable loop — clean coding screen, adequate but prompted design round, and past-work answers that describe implementations rather than decisions — and it maps to the rung below the posting. The candidate then concludes they need more problem practice, and repeats the cycle. A second failure mode is over-correcting: abandoning coding practice entirely because *staff loops are not about coding*. One badly fumbled screen still costs you, and it is cheap to avoid. ## A worked allocation Suppose you have a fixed number of preparation hours before a staff infrastructure loop with one coding screen, two design or architecture rounds, two past-work-and-influence rounds and a hiring-manager conversation. A defensible split is roughly one part coding, two parts design breadth and comparison practice, two parts scope inventory and story mapping against the ladder, and a smaller part on the hiring-manager conversation and your own questions. Compare with the same budget for a mid-level loop with two coding rounds and one design round: coding and design take most of it, and the inventory shrinks to selecting two or three project stories. The headline is not *do less coding*. It is that above mid-level, preparation stops being a skills exercise you can do alone with a problem set and becomes partly an **evidence-assembly** exercise about your own history, which takes calendar time and cannot be crammed. ## Sanity checks before the loop - Can you state, for each round on the list, what evidence that round is trying to collect? - For the top rung you are targeting, can you name two pieces of work whose scope matches the ladder's own words for it? - Can you compare two approaches to a system you have actually built, including what you gave up? - Is your coding warm enough that one screen is uneventful? Four yeses is a well-allocated preparation. Four problem sets is not.