Evaluate a high-risk full rewrite

WHAT THIS TESTS The interviewer is probing for hard-won judgment: full rewrites have a notorious failure rate, and an 18-month feature freeze is a strategic gamble. They want you to contribute evidence and a safer alternative, not just a verdict.

A GOOD ANSWER COVERS Start by de-risking the unknowns. Build focused proof-of-concepts that stress the unproven stack against the requirements most likely to fail: peak scale, the hardest domain workflow, and operational maturity like observability and hiring pool. Assess the strategic risk honestly: an 18-month freeze ships no customer value while competitors advance, and big-bang rewrites suffer the second-system effect, scope creep, and a painful long cutover. Then propose the incremental alternative: the Strangler Fig pattern, where you route traffic through a facade and replace one capability at a time on the new stack, retiring the old system gradually. This delivers value continuously, validates the new stack under real load early, and is reversible if it falters. Quantify the opportunity cost of the freeze against the displacement approach so leadership decides with numbers.

COMMON WRONG ANSWERS Enthusiastically backing the rewrite for the shiny stack, or rejecting it outright. Accepting the long freeze without proposing incremental displacement. Ignoring operational and hiring realities of an unproven technology.

LIKELY FOLLOW-UPS What is the Strangler Fig pattern and how does the facade work? How do you keep two systems consistent during a long migration? When is a full rewrite actually justified?

ONE CONCRETE EXAMPLE Instead of an 18-month freeze, you POC the new stack on the highest-risk service, then place a routing facade in front of the monolith. Over several quarters you migrate checkout, then search, then accounts onto the new stack one at a time, shipping features throughout. If the new stack underdelivers on service two, you stop with limited loss, something a big-bang rewrite would never allow.