Practice the English phrases used for expressing magnitude, scale, and rough approximations in technical conversations: orders of magnitude, rough estimates, and ballpark language.
0 / 21 completed
1 / 21
What does 'ballpark figure' mean in an estimation context?
A ballpark figure is an informal rough estimate. 'Can you give me a ballpark on the effort?' means: give me a rough number, not a precise commitment. It signals that precision is not expected.
2 / 21
What does 'order of magnitude' mean?
Orders of magnitude are used for rough scale comparisons: 1,000 users vs 10,000 users is one order of magnitude. It is faster to say 'this is two orders of magnitude slower' than to list exact numbers.
3 / 21
Which phrase expresses appropriate uncertainty in a rough system design estimate?
Good approximation language gives a range, states the assumption it depends on (traffic), and explains what would be needed for greater precision. This is more useful than refusing to estimate.
4 / 21
What does 'rough order of magnitude' (ROM) estimate mean in project planning?
ROM estimates are early-stage approximations with wide error bars. Stakeholders requesting a ROM understand they will get a range, not a commitment. The accuracy improves as requirements are defined.
5 / 21
How would you communicate scale when describing database storage needs?
Back-of-envelope calculations show your reasoning: data per record × users × growth rate. This lets colleagues check your assumptions and correct them. The final numbers guide infrastructure decisions.
6 / 21
What does 'within an order of magnitude' mean when comparing systems?
Within an order of magnitude means the numbers are in the same ballpark — not 100x or 1000x apart. 'Your solution and mine are within an order of magnitude in cost' means they are comparable, not vastly different.
7 / 21
Which of these is the best approximation phrase for a system design discussion?
Good estimation starts with a stated assumption (100 req/sec as a baseline), explains the reasoning, and acknowledges it will be updated with real data. Stating 'design for infinite scale' is a classic over-engineering anti-pattern.
8 / 21
How do you use 'roughly', 'approximately', 'around', and 'in the region of' correctly?
Register matters: 'roughly' and 'around' work in Slack and meetings; 'approximately' suits documents and presentations. 'In the region of' (British English) is formal and precise-sounding. All are grammatically correct in technical English.
9 / 21
Sarah: "Okay, so for the API endpoint, I'm estimating it will handle 10,000 requests per second. That's a pretty solid number, right?"
Mark (code reviewer): Which of the following responses best reflects Mark's concerns and provides appropriate feedback regarding Sarah's estimate?
Mark is rightly cautious about Sarah's overly confident estimate. Saying 'that's a pretty solid number, right?' without further qualification implies complete certainty. The best response acknowledges the optimism while highlighting the need for more data-driven refinement. A good estimate always includes an acknowledgement of potential future growth or uncertainty; simply stating it's 'solid' is insufficient for a critical system component.
10 / 21
Mark (code reviewer): "Okay, Sarah, that's a good starting point. However, let's talk about the potential for peak loads. We need to consider scenarios where we might see significantly higher traffic—perhaps during a major marketing campaign. 10,000 requests per second is a very optimistic assumption."
Mark's response highlights the importance of considering realistic load variations beyond a simple best-case scenario. While an initial 'ballpark figure' can be useful, it needs to acknowledge potential peaks and incorporate factors like scalability. The incorrect options either focus solely on a single metric (scalability) or accept overly optimistic figures without further questioning—Mark is advocating for a more robust and realistic approach by prompting Sarah to investigate peak load scenarios.
11 / 21
Sarah: "Okay, so for the API endpoint, I'm estimating it will handle 10,000 requests per second. That's a pretty solid number, right?"
Mark (code reviewer): Which of the following responses best reflects Mark's concerns and provides appropriate feedback regarding Sarah's estimate?
Mark is rightly cautious about Sarah's overly confident estimate. Saying 'that's a pretty solid number, right?' without further qualification implies complete certainty. The best response acknowledges the optimism while highlighting the need for more data-driven refinement. A good estimate always includes an acknowledgement of potential future growth or uncertainty; simply stating it's 'solid' is insufficient for a critical system component.
12 / 21
Mark (code reviewer): "Okay, Sarah, that's a good starting point. However, let's talk about the potential for peak loads. We need to consider scenarios where we might see significantly higher traffic—perhaps during a major marketing campaign. 10,000 requests per second is a very optimistic assumption."
Mark's response highlights the importance of considering realistic load variations beyond a simple best-case scenario. While an initial 'ballpark figure' can be useful, it needs to acknowledge potential peaks and incorporate factors like scalability. The incorrect options either focus solely on a single metric (scalability) or accept overly optimistic figures without further questioning—Mark is advocating for a more robust and realistic approach by prompting Sarah to investigate peak load scenarios.
13 / 21
Sarah: "Okay, so for the API endpoint, I'm estimating it will handle 10,000 requests per second. That's a pretty solid number, right?"
Mark (code reviewer): Which of the following responses best reflects Mark's concerns and provides appropriate feedback regarding Sarah's estimate?
Mark is rightly cautious about Sarah's overly confident estimate. Saying 'that's a pretty solid number, right?' without further qualification implies complete certainty. The best response acknowledges the optimism while highlighting the need for more data-driven refinement. A good estimate always includes an acknowledgement of potential future growth or uncertainty; simply stating it's 'solid' is insufficient for a critical system component.
14 / 21
Mark (code reviewer): "Okay, Sarah, that's a good starting point. However, let's talk about the potential for peak loads. We need to consider scenarios where we might see significantly higher traffic—perhaps during a major marketing campaign. 10,000 requests per second is a very optimistic assumption."
Mark's response highlights the importance of considering realistic load variations beyond a simple best-case scenario. While an initial 'ballpark figure' can be useful, it needs to acknowledge potential peaks and incorporate factors like scalability. The incorrect options either focus solely on a single metric (scalability) or accept overly optimistic figures without further questioning—Mark is advocating for a more robust and realistic approach by prompting Sarah to investigate peak load scenarios.
15 / 21
Sarah: "Okay, so for the API endpoint, I'm estimating it will handle 10,000 requests per second. That's a pretty solid number, right?"
Mark (code reviewer): Which of the following responses best reflects Mark's concerns and provides appropriate feedback regarding Sarah's estimate?
Mark is rightly cautious about Sarah's overly confident estimate. Saying 'that's a pretty solid number, right?' without further qualification implies complete certainty. The best response acknowledges the optimism while highlighting the need for more data-driven refinement. A good estimate always includes an acknowledgement of potential future growth or uncertainty; simply stating it's 'solid' is insufficient for a critical system component.
16 / 21
Mark (code reviewer): "Okay, Sarah, that's a good starting point. However, let's talk about the potential for peak loads. We need to consider scenarios where we might see significantly higher traffic—perhaps during a major marketing campaign. 10,000 requests per second is a very optimistic assumption."
Mark's response highlights the importance of considering realistic load variations beyond a simple best-case scenario. While an initial 'ballpark figure' can be useful, it needs to acknowledge potential peaks and incorporate factors like scalability. The incorrect options either focus solely on a single metric (scalability) or accept overly optimistic figures without further questioning—Mark is advocating for a more robust and realistic approach by prompting Sarah to investigate peak load scenarios.
17 / 21
David: 'The new microservice will process approximately 20 million events per day. That's a huge number, but I think our current infrastructure can handle it.'
You are reviewing David's comment. Which of the following phrases best captures the appropriate level of caution and further investigation David needs to undertake?
David's statement is overly confident. 'Approximately' doesn't convey sufficient uncertainty when dealing with potentially volatile data volumes. The best response acknowledges the initial estimate while immediately prompting a deeper dive into peak loads and potential bottlenecks – crucial for system design discussions. Option A is completely inappropriate; options C and D push unrealistic targets.
18 / 21
During a standup meeting, Alex says: 'We're building the new feature, and we're thinking it will take around 3 weeks to implement.'
Which of the following is the MOST effective way to respond to Alex's estimate?
Alex's estimate lacks detail and doesn't account for uncertainty. Asking for elaboration forces a discussion about scope and potential issues – essential when discussing timelines in a development context. Option A is overly enthusiastic; options C and D introduce potentially unrealistic or inappropriate priorities.
19 / 21
In a Slack channel discussing database scaling, Maria writes: 'We need to accommodate approximately 100GB of data growth over the next year.'
Which of the following is the MOST helpful follow-up question to ask Maria?
Maria's statement provides a quantity but lacks context. Understanding the *drivers* of data growth (data types and access patterns) is crucial for making informed decisions about scaling strategies – whether it's increasing storage capacity or optimizing queries. Option A suggests a simplistic solution; options C and D are irrelevant without understanding the problem.
20 / 21
During a code review, John comments on a PR: 'The API endpoint is designed to handle approximately 50 requests per second.'
Which of the following responses from Sarah best demonstrates an understanding of appropriate approximation language in this scenario?
Sarah's response acknowledges the potential for peak loads – a critical consideration when discussing API performance. Simply stating '50 requests per second is reasonable' doesn't account for unpredictable traffic spikes. This demonstrates an awareness of system design principles and the need for headroom. Option A is overly optimistic; options C and D set unrealistic goals.
21 / 21
You're discussing the performance of a new caching layer with your team. David states: 'The cache should reduce latency by roughly 20%.'
Which of the following is the MOST appropriate way to respond?
'Roughly' indicates an approximation. The key question to ask is how that 20% will be measured and under what conditions – this ensures a quantifiable target and avoids relying solely on a subjective estimate. This demonstrates critical thinking about performance metrics and testing strategies.
What does the "Approximation and Scale Language (English)" exercise cover?
Practice the English phrases used for expressing magnitude, scale, and rough approximations in technical conversations: orders of magnitude, rough estimates, and ballpark language.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Approximation and Scale Language (English)"?
This exercise has 21 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Estimation Language exercises?
Browse the full Estimation Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.