5 exercises on proposing refactors and justifying technical debt paydown. Choose the most natural and professional option.
0 / 5 completed
1 / 5
You want to explain why a codebase needs major cleanup. Which phrasing is most professional?
KEY PHRASE: "This code has accumulated a lot of debt — I'd like to propose a cleanup sprint" "Technical debt" is the neutral, professional metaphor that engineers recognise — debt accumulates through reasonable short-term decisions, not negligence. It doesn't blame individuals. "Cleanup sprint" proposes a concrete delivery format. Real examples: "This module has accumulated significant debt over 3 years — I'd like to address it in Q3"; "The auth layer has accumulated a lot of debt — proposing a 2-week cleanup sprint." Options B and C are reactive and alarmist ("really messy", "bad shape"), escalating anxiety without a plan. Option D explicitly blames people, which damages team relationships and credibility.
2 / 5
You want to convince the team to refactor before adding new features. What's the best argument?
KEY PHRASE: "I'd like to refactor this before adding more features — the current structure will make the new work harder" This is persuasive and practical. It proposes ("I'd like to"), explains the reason (current structure), and directly links the refactor to the upcoming feature work. It's proactive rather than obstructive. Real examples: "I'd like to refactor the data layer before we add the new filters — the current coupling will slow us down"; "Refactoring first makes sense here — the structure isn't designed for what we're about to build." Options A and B sound like blockers without offering a rationale or path forward. Option D is negative and doesn't propose a solution.
3 / 5
You want to explain the consequences of deferring the refactor. Which phrasing is most persuasive?
KEY PHRASE: "The risk of NOT refactoring is that every new feature will take twice as long and introduce more bugs" This is rhetorically strong because it reframes the cost of inaction rather than making a positive case for the work. Naming specific consequences ("twice as long", "more bugs") makes the argument concrete and measurable. Real examples: "The risk of not refactoring is compounding complexity — every sprint gets slower"; "The risk of NOT addressing this now is that the next team to touch it will spend a week just understanding it." Options A, C, and D are vague assertions with no specificity. They sound like warnings without evidence, which engineers (rightly) discount.
4 / 5
You're proposing a gradual approach to avoid a big-bang refactor. Which is clearest?
KEY PHRASE: "We could do it incrementally — starting with X, then working up to Y" "Incrementally" is the key word — it signals a disciplined, low-risk approach that engineering managers and senior engineers recognise and trust. Naming the sequence (data layer first, then API boundary) shows you've thought through the dependency order, not just proposed splitting arbitrarily. Real examples: "We can tackle this incrementally — one module per sprint"; "Incrementally — starting with the models, then controllers, then views"; "Incremental approach: extract the service layer first, then refactor the controllers once the seams are clear." Options A-C are too vague about what "incremental" means in practice.
5 / 5
You're proposing to write tests before touching any existing code. How do you frame it?
KEY PHRASE: "I'll write tests first to pin the behaviour before we touch anything" This is the textbook characterisation test approach — you write tests to capture the current (possibly buggy) behaviour before refactoring, so any change that breaks the output is detected immediately. "Pin the behaviour" is the precise engineering term for this. The first-person ownership ("I'll write") adds credibility and signals a concrete plan. Real examples: "I'll write a characterisation test suite first to pin the behaviour — then we can safely refactor"; "Tests first to pin current output — then we refactor with confidence." Options B-D are vague aspirations ("at some point", "make sure we have", "would be good") — none signal urgency, ownership, or the right framing.