Drive a Monolith-to-Services Migration Across 8 Teams (TPM)
The long-horizon technical program case. Tests strangler-fig strategy, sequencing, traffic-based progress metrics, and finishing the last 10%.
Interview prompt
Your company wants to migrate a large monolith to services. Eight teams are involved and it will take multiple quarters. How do you structure and drive the program?
What interviewers evaluate
Do you anchor the migration in measurable business outcomes rather than 'microservices' as a goal?
Do you choose incremental strangler-fig over a big-bang rewrite, and measure progress in traffic?
Do you sequence extractions and build the paved road before teams migrate?
Do you protect ongoing business delivery (capacity allocation, not feature freeze)?
Do you manage the data-migration risk and define exit criteria for the last 10%?
A framework to structure your answer
Anchor the why - concrete outcomes with baselines (deploy frequency, blast radius, scaling constraints); this keeps the program funded in quarter 3.
Strategy - strangler fig behind a routing layer, never big-bang; unit of progress = % of production traffic served by services.
Sequence - extract high-value, low-coupling domains first; save the tangled core for when the pattern is proven.
Paved road first - a platform workstream ships service templates, CI/CD, observability, and on-call before teams migrate, or you get 8 snowflakes.
Program structure - teams own their domains end-to-end; TPM owns the dependency map, shared milestones, and data-cutover risks; steering reviews track traffic %, deploys, incidents.
Protect delivery & finish - capacity allocation instead of feature freeze; explicit exit criteria and monolith decommissioning as the celebrated milestone.
Strong sample answer
Try structuring your own answer first, then reveal a strong worked example.
Common variants
Drive a cloud migration (data center to AWS) across many teams.
Migrate the company off a deprecated database everyone depends on.
Roll out a breaking API version across dozens of internal consumers.
Pitfalls to avoid
Framing 'microservices' as the goal instead of measurable business outcomes.
Big-bang rewrite - or measuring progress in code written instead of traffic shifted.
Letting teams migrate before the paved road exists, producing 8 inconsistent stacks.
Declaring a feature freeze, which turns every product team against the program.
Stopping at 90% and running two architectures indefinitely - the costliest outcome of all.
Likely follow-ups
In quarter 3, leadership questions the program's value. What do you show them?
One of the 8 teams simply refuses to prioritize their extraction. What do you do?
How do you handle the shared database that six domains all write to?