Describe leading a major refactor in a Python codebase — how you managed risk and team buy-in
py-sen-004
Your answer
Answer as you would in a real interview — explain your thinking, not just the conclusion.
Model answer
STAR structure: Situation — a 5-year-old Django monolith with 40k lines had no type annotations, 30% test coverage, and was causing 3+ production incidents per month from unexpected None values. Task — improve stability without halting feature development. Action — proposed a phased refactor: (1) add mypy in warn-only mode (no CI block initially) and annotate the 20 most-called modules. (2) Introduced pyright strict-mode for all new code (enforced in CI). (3) Ran a 'fix Friday' — 2-hour weekly timebox for the team to annotate modules and add tests, tracked on a burndown chart. Used MonkeyType to auto-generate type stubs from runtime data. (4) Negotiated with product: for every 2 weeks of feature work, 1 sprint of refactor time. Result: after 6 months, mypy coverage at 85%, incidents dropped from 3/month to 0.5/month. Lesson: refactors need incremental checkpoints, measurable goals, and stakeholder buy-in — not a 'stop everything' approach.
Follow-up
How do you prevent regression when adding types to a codebase that previously had none — especially for complex generic types?