Practice technical debt reduction vocabulary: debt sprints, capacity allocation, debt blocking features, debt paydown outcomes, and backlog estimation.
0 / 10 completed
1 / 10
'We're allocating 20% of _____ to debt.' What resource is being divided between features and debt work?
'Capacity' is the engineering team's available work bandwidth. Allocating 20% to debt is a common sustainable approach to preventing debt accumulation while continuing feature delivery.
2 / 10
'The debt item is _____ feature X.' What relationship makes this debt item urgent?
When a debt item is 'blocking' a feature, it becomes a higher priority than general debt work because it is directly preventing business value from being delivered.
3 / 10
'We paid down the debt — the build time dropped by _____.' What improved?
'Dropped by 40%' is the specific outcome quoted. Measuring build time before and after debt paydown demonstrates the concrete value of the work to the team and stakeholders.
4 / 10
'The debt is now in the _____ with a size estimate.' Where is debt tracked as work items?
Placing debt items in the backlog with size estimates treats them like any other work item — making them visible, prioritizable, and schedulable alongside feature work.
5 / 10
A 'debt reduction sprint' is best described as:
A debt reduction sprint allocates focused time (either a whole sprint or a fixed capacity fraction) specifically for paying down technical debt, separate from normal feature development.
6 / 10
Sarah from the QA team just left a comment on your PR: 'This refactoring introduced some technical debt – specifically around the legacy database interaction. It's not immediately blocking, but we'll need to address this soon before it impacts performance and maintainability.' What does Sarah primarily highlight about the code change?
Sarah is focusing on the *potential* negative consequences of the change. Technical debt isn't always about immediate failures; it's about accumulating risks that can worsen over time. Options A and D are too extreme – a broken code doesn't necessarily equate to technical debt, and strategic advantages aren't typically associated with creating future problems. Option B is incorrect as it frames the issue positively.
7 / 10
You're drafting a PR description for a refactoring task aimed at reducing technical debt in a core API endpoint. Which of the following statements BEST captures the purpose of this work?
The core goal of technical debt reduction isn't adding shiny new features or fixing bugs. Instead, it's about proactively addressing areas of code that are complex, inefficient, or difficult to maintain – directly impacting performance and long-term maintenance costs. Options A and D misrepresent the purpose; Option B accurately describes the focus on stability and future improvements.
8 / 10
During a standup meeting, your team lead asks: 'What's blocking you on the Phoenix project?' You respond: 'I'm spending about 30% of my time investigating and addressing accumulated technical debt in the authentication module. It's preventing me from moving forward with the new user onboarding flow.' What does this primarily indicate?
This response highlights the *time* being consumed by addressing technical debt. It suggests that existing code – in this case, the authentication module – has become complex and difficult to work with, directly impacting progress on other tasks. Options A and D are distractions; Option B is a potential symptom, not the core issue being described.
9 / 10
You've identified a significant piece of technical debt within a legacy microservice called Hydra. The team decides to track this debt as an item in your project's Jira board. Which of the following descriptions would be MOST appropriate for this Jira ticket?
The most accurate description clearly identifies the nature of the work: refactoring to address *technical debt*. Using a descriptive title like 'Hydra authentication module – High Technical Debt' immediately communicates the issue's priority and scope. Options A, C, and D are misinterpretations of what technical debt reduction involves.
10 / 10
Your manager asks: 'How do we best manage the ongoing risk associated with this legacy system?' You respond that reducing technical debt is a continuous process. Which of the following approaches would be MOST aligned with this statement?
Technical debt reduction isn't about massive, infrequent overhauls. It requires a consistent, ongoing effort – dedicating a portion of each sprint to addressing smaller issues and preventing future accumulation. Prioritizing only critical bugs (Option B) is insufficient, while Option A represents an overly ambitious approach and Option D advocates for negligence.
What will I practice in "Technical Debt Reduction Vocabulary"?
This is a Refactoring Language exercise set. It walks through 10 scenario-based multiple-choice questions built around real usage of refactoring language terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 10 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the refactoring language vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Refactoring Language exercises?
See the Refactoring Language exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — refactoring language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.