You want to replace a twelve-year-old monolith one capability at a time. The organisation releases that monolith once every six weeks on a Thursday evening, behind a change advisory board that meets fortnightly. Tell me what you would do first and why.

What the interviewer is testing

Whether you notice that incremental modernisation has a delivery-cadence prerequisite, and whether you can argue it in the organisation's language rather than by complaining about the change advisory board. The candidates who jump straight to "extract the first service" have not done the multiplication.

Do it now. A migration of 40 capability slices, each needing a release to move traffic, at one release every six weeks, is 240 weeks — roughly four and a half years before any slippage. At one release a day the same 40 slices fit inside a quarter. The cadence, not the architecture, sets the programme's duration, and no amount of good decomposition recovers it.

The clarifying questions that change the answer

1. Is the six weeks a technical limit or a governance one? Manual regression and a shared pre-production environment give one answer; a fortnightly board gives a completely different one.
2. Can the routing decision be deployed independently of the monolith? This is the question the whole answer turns on.
3. What is the current change failure rate, and how long does recovery take? Without it, any argument about cadence is an assertion.
4. Does rollback require a release? If undoing a slice takes six weeks, every slice is a six-week bet.

A strong answer's arc

The first move is not extracting a service. It is making the route switch independently deployable — a facade or flag whose configuration changes outside the release train, so directing a capability to the new implementation and back is a minutes-long operation rather than a release. That single change decouples migration risk from release risk and makes every subsequent slice reversible.

Then take the cadence itself, with evidence rather than ideology. Etsy's published engineering practice from 2011 onward, including the release of StatsD, made the argument that has since become standard: frequent small deploys are a safety property, not a speed one, because a change of 20 lines has an obvious suspect when something breaks and a change of six weeks' accumulated work does not. Bring the organisation's own numbers: measure change failure rate per release and time to restore, and show that the six-week batch is what makes both bad.

Common weak answers

• "Fix the deployment pipeline first, then migrate." An eighteen-month platform programme with no migration in it is how modernisation dies in the funding round. Scope the cadence work to what the migration needs: independent deployment of the routing layer and of the new services, and nothing else.
• "Work around the board with an exemption." Exemptions are personal and expire with the person who granted them. The board is a control, and a control is replaced by a better control.
• "Start with the hardest capability to prove it works." The first slice proves the mechanism — routing, observability, rollback, reconciliation. Pick something with low blast radius and real traffic.

What a strong answer adds

Treat the change advisory board as a stakeholder with a legitimate requirement rather than an obstacle. It exists to bound blast radius. Offer it a better instrument: per-slice automated verification, a stated blast radius, and a reversal that takes minutes, in exchange for approving a class of changes rather than each one. The board's real objection is usually that it cannot see the risk, and a reversible switch with a named owner is a more convincing answer than a slide.

Finish with the cost of not doing it: at six-week cadence the coexistence period runs for years, and coexistence is the most expensive state a modernisation can be in, because both systems are staffed, both are changing, and the reconciliation between them is permanent.