The Necessity of Code Refactoring
Describe a time you inherited code so poor that a full rewrite was necessary. How did you justify the time investment to the business?
Why Interviewers Ask This
Meta evaluates this question to assess a candidate's ability to balance technical debt against business value. They seek evidence that you can make data-driven decisions about when to refactor versus rewrite, rather than blindly rewriting code or ignoring critical issues. The interviewer wants to see if you can justify significant time investments by articulating clear ROI, risk mitigation, and alignment with company goals like scalability and maintainability.
How to Answer This Question
1. Set the context using the STAR method, briefly describing the inherited system's critical flaws, such as technical debt preventing feature delivery or causing frequent outages.
2. Define your diagnostic process: explain how you quantified the problem using metrics like cycle time, bug rates, or deployment frequency to prove a rewrite was necessary over patching.
3. Detail your justification strategy to stakeholders, focusing on long-term cost savings, reduced operational risk, and accelerated future velocity rather than just 'cleaner code.'
4. Describe the execution phase, highlighting how you managed the transition, perhaps using a strangler fig pattern to minimize downtime and keep delivering value incrementally.
5. Conclude with measurable outcomes, citing specific improvements in deployment speed, error reduction, or team morale to demonstrate the tangible business impact of your decision.
Key Points to Cover
- Quantifying technical debt with hard metrics like cycle time or incident rates
- Framing the rewrite as a strategic business investment rather than a technical vanity project
- Demonstrating risk mitigation strategies during the transition period
- Providing concrete before-and-after metrics to prove ROI
- Aligning the solution with organizational values like scalability and speed
Sample Answer
In my previous role at a fintech startup, I inherited a monolithic payment processing service written in PHP that had become unmaintainable. The code lacked unit tests, relied on deprecated libraries, and caused 15% of o…
Common Mistakes to Avoid
- Claiming the previous code was 'bad' without providing specific technical evidence or metrics
- Focusing solely on technical elegance without explaining the business justification for the time spent
- Admitting to a 'big bang' rewrite that caused significant downtime or product delays
- Failing to mention how you communicated the plan to non-technical stakeholders
- Not acknowledging that refactoring might have been an alternative option before choosing a rewrite
Sound confident on this question in 5 minutes
Answer once and get a 30-second AI critique of your structure, content, and delivery. First attempt is free — no signup needed.