The Rewrite Nobody Asked For

“Your team's Android codebase is 6 years old. You want to rewrite it. Your manager wants to ship features. Who wins?”

The Situation

You're a Staff Android engineer at a mid-size fintech startup. The core payment flow was built in 2018 on a deprecated MVC architecture with zero unit test coverage. Every new feature takes 3× longer than it should due to tight coupling and lifecycle bugs. You've scoped a 4-month full rewrite to Kotlin + MVVM + clean architecture.

Context

The next quarter's roadmap includes 4 features that all touch the payment flow
Two junior engineers have spent weeks debugging obscure lifecycle bugs in the existing code
Your manager's OKR includes shipping 3 of those features this quarter
Engineering leadership has informally said 'no big rewrites' after a previous failed rewrite attempt
You have data: the payment module takes 3× longer to change than any other module

The Question

“Tell me about a time you had to make a major technical decision that stakeholders initially disagreed with.”

Response Options

One of these is the strongest response. The others reflect common approaches with real trade-offs.

I pushed hard for the full rewrite, wrote a detailed technical proposal, and escalated to the VP when my manager didn't approve it immediately.

I proposed a strangler fig migration — rewriting one module per feature alongside the feature work. I framed it as a risk reduction strategy for the roadmap, not a rewrite, and got sign-off by showing the before/after cycle time data from the first module.

I documented the technical debt thoroughly, added it to the backlog, and flagged it to my manager for consideration in a future planning cycle.

I rewrote the core payment module during a hackathon weekend and presented the working code as a fait accompli to convince the team.

The Debrief

Why the Best Response Works

Answer B works because it eliminates the core objection — 'we can't stop shipping' — before it's raised. By proposing module-by-module improvement alongside feature delivery and leading with cycle-time data, it transforms a technical argument into a delivery risk argument. That's how Staff+ engineers create organizational change: they remove blockers before asking for permission.

What to Avoid

The most common mistake at Staff level is leading with technical correctness ('MVVM is the right architecture') instead of business impact ('this is slowing our roadmap by X%'). Managers and stakeholders don't fund rewrites — they fund delivery improvements.

What the Interviewer Is Probing

The interviewer is probing for strategic influence: can you drive significant technical change without having direct authority? Can you translate engineering judgment into business language? The answer reveals whether you operate as a Staff engineer or a Senior engineer with a big idea.

SOAR Structure

**Situation:** 6-year-old payment module with zero tests, 3× slower feature velocity. **Obstacle:** Manager's OKR depended on shipping features this quarter; 'no rewrites' policy in place. **Action:** Proposed strangler fig migration; built first module proof-of-concept alongside a feature; measured and shared the cycle-time delta. **Result:** Got sign-off on gradual migration; payment module now ships features in 1/3 the time.

The Learning Arc

"This taught me that technical proposals fail when they ask stakeholders to take on risk. The strangler fig framing worked because it didn't ask anyone to bet on the future — it just showed them the present. I now apply this on every large technical change: find the smallest demonstrable unit of improvement, build it, measure it, and let the data make the ask."

IC Level Calibration

senior

Identify the problem, propose the rewrite with a concrete plan, and advocate for it through proper channels. Getting manager alignment is the goal.

staff · Primary Target

Reframe the proposal in terms of delivery risk (not technical purity), propose an incremental path that doesn't block the roadmap, and use a small proof-of-concept to generate buy-in before asking for full investment.

principal

Architect the migration strategy to be adopted org-wide as a pattern. Build executive sponsorship by connecting technical debt cost to business metric impact. Make the migration the default approach for other teams facing similar debt.

Company Calibration

Amazon

LP: Think Big + Have Backbone; Disagree and Commit