Your group is standing up a separately regulated subsidiary that must be able to show it can keep operating if the group withdraws support. You have 18 months and the subsidiary has 40 engineers against the group's 600. How do you decide what the subsidiary runs itself and what it keeps consuming from the group? Talk me through it.

What the interviewer is testing

Whether you can turn a governance requirement into a design criterion. The weak version of this answer is an inventory of systems with a column marked "keep or move". The strong version treats separability as a property each dependency either has or does not have, and prices the gap.

The clarifying questions that change the answer

• What does the regulator actually require: operational continuity, or legal separability? Continuity means the subsidiary keeps running through a group failure. Separability means it could be sold or resolved. They produce different designs: continuity needs substitutability, separability needs clean data and contract boundaries.
• What is the stressed exit window? Six months to replace a service and twelve months are different architectures. This single number decides more than any technical fact.
• Which services are "critical or important functions" under the regime? Only those need the full treatment. Applying it to all 200 dependencies is how an 18-month programme becomes a four-year one.
• Is there a shared customer identity, and does the subsidiary's data sit in a group-owned schema? Shared identity is usually the most expensive single item and nobody puts it on the first list.

A strong answer's arc

Classify every group dependency on two axes: how long the subsidiary survives without it, and how long a replacement takes to stand up.

Dependencies where survival time exceeds replacement time need nothing but a documented plan. Payroll, procurement, most internal tooling sit here.

Dependencies where replacement time exceeds survival time are the actual programme. For each one, pick a mechanism and fund it: a second supplier with a tested runbook, a service contract with a notice period longer than the replacement time, or in-housing. A notice period is an architecture decision, because it converts an invisible dependency into a dated obligation you can design against.

Then make the interfaces replaceable rather than merely documented. That means an adapter the subsidiary owns, its own data store for anything it must keep, no reads from group schemas, and a periodic proof: once a year, run the subsidiary against a stubbed group service for a day.

What stays shared should be the things that are costly to duplicate and cheap to substitute: observability backends, CI runners, procurement. What moves should be the things the subsidiary's licence depends on: customer records, transaction processing, the identity store, and anything carrying a regulatory reporting obligation.

Common weak answers

• "We will duplicate everything." 40 engineers cannot run 600 engineers' platform. The duplication itself becomes the continuity risk, because it will be under-staffed and under-patched.
• "The contract covers it." A contract allocates liability. It does not make a replacement exist. Ask what the subsidiary does on day one of the notice period.
• "We will build an abstraction layer over group services." An abstraction with one implementation is a guess. Prove it with a second implementation, even a degraded one.

What a strong answer adds

The run cost and the staffing consequence. Separability is permanently more expensive. European financial firms spent 2024 and 2025 standing up exactly this kind of evidence for operational-resilience obligations, and the recurring overhead of adapters, substitution tests and rehearsals is worth budgeting at something on the order of 10 to 20% on top of the run cost of the separated services. Treat that as a planning range to be replaced by your own figure after the first rehearsal; a 40-engineer subsidiary feels it far more than the group does.

Say the number, put it in the subsidiary's run budget rather than the programme's capital budget, and choose the annual rehearsal as the line that must survive the first cost-cutting round, because a separability design that is never exercised fails at the only moment it is needed and nothing else proves it still works. If the rehearsal cannot be funded, the honest answer is to reduce the number of critical dependencies until it can.