Walk me through how you would choose the first capability to extract from a fifteen-year-old monolith, given that leadership expects visible progress within two quarters.

What the interviewer is testing

Whether you choose from the business and the data, or from the code. Candidates who answer "start with the most tightly coupled part" are describing the hardest possible first move, and candidates who answer "start with something easy" are describing a demo. The good answer holds both: a piece with a genuine business reason to move, a data boundary that actually exists, and a size that fits the timebox.

The clarifying questions that change the answer

• What is the extraction for? Independent deployment, scaling a hot path, isolating a compliance domain, enabling a team to own something, or preparing to sell a business unit. These point at completely different first pieces, and the answer is often unstated.
• Where does the data divide cleanly? The binding constraint is almost never the code. Any capability whose writes must be transactionally consistent with the rest of the monolith is a bad first choice, regardless of how neat its interface looks.
• Who will own it afterwards? An extraction with no owning team produces a distributed monolith with an extra network hop.

A strong answer's arc

1. List candidates from the business capability map, not the package structure. Capabilities with distinct vocabularies, distinct change cadences and distinct stakeholders are the ones with real seams.
2. Score them on three axes: business reason to move (a real one, now), data separability, and blast radius if it goes wrong. Something with a reason but no data separation is a later project; something with clean data and no reason is a way to spend a quarter for nothing.
3. Prefer a read-heavy capability with an append-only or reference-shaped data model for the first extraction: notifications, search, document generation, pricing rules, audit views. The goal of the first extraction is to build the organisation's muscle — deployment, observability across a boundary, on-call, contract testing — not to remove the hardest coupling.
4. Keep the monolith the source of truth initially, with the extracted service reading from an event stream or a replica, so the rollback is deleting a service rather than restoring data. This costs a period of duplicated data and a lag of seconds to minutes, which is the price of a reversible first move.
5. Define completion honestly. An extraction is finished when the monolith's code for that capability is deleted. Anything short of that is two implementations to maintain, and this is where most programmes quietly stop.

Common weak answers

• "Extract authentication first." Frequently proposed, usually a mistake: it is on every critical path, so the blast radius is total, and it is rarely where the business pain is.
• "Whatever the team wants to rewrite." The team's enthusiasm is a real asset and a poor selection criterion; it usually points at the component that is most annoying to work in, not the one whose separation is worth most.

What a strong answer adds

The stated exit condition for the whole programme, agreed with leadership at the start. Most monolith decompositions end halfway, with the worst of both structures, because nobody defined how much decomposition was enough. A good answer names the target — perhaps 4 or 5 services around the capabilities that genuinely need independence, with the remaining monolith kept and maintained deliberately — and says plainly that a permanently retained monolith is a legitimate end state, an argument made publicly by engineering teams reversing partial decompositions since around 2020, which is usually the most useful thing an architect can tell that audience.