Build fluency in the vocabulary of representing and composing values not yet available from asynchronous operations.
0 / 5 completed
1 / 5
A teammate describes an object that represents a value not yet available from an asynchronous operation, letting calling code attach a callback to run once that value eventually resolves or rejects. What abstraction is being described?
A future or promise is exactly this: it is a placeholder object representing a value that an asynchronous operation will eventually produce, and calling code attaches a callback, or chains further operations, to run once the value resolves or rejects, rather than blocking or polling for completion. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This attach-a-callback-to-a-not-yet-available-value approach is exactly why futures and promises let asynchronous code be composed without manual polling.
2 / 5
During a design review, the team chains three dependent asynchronous API calls using promises, specifically so each call's result feeds into the next only once it resolves, without ever blocking the calling thread. Which capability does this provide?
Promises here provide non-blocking composition of dependent asynchronous steps, since each promise's resolution triggers the next step without the calling thread ever waiting synchronously. Calling each API synchronously and blocking the thread until each response arrives ties up a thread for the full duration of every network round trip, which is exactly what this chained-promise design avoids. This resolve-then-trigger-next behavior is exactly why futures and promises are favored for composing dependent asynchronous operations.
3 / 5
In a code review, a dev notices a function repeatedly polls a shared boolean flag in a tight loop to detect when a background operation has finished, instead of returning a promise that calling code can attach a completion callback to. What does this represent?
This is a missed futures-and-promises opportunity, since returning a promise would let calling code attach a completion callback instead of burning CPU cycles in a polling loop. A cache eviction policy is an unrelated concept about discarded cache entries. This tight-polling-loop pattern is exactly the kind of wasted CPU a reviewer flags once an asynchronous completion notification is available instead.
4 / 5
An incident report shows CPU usage spiked because dozens of background operations were each tracked with a tight polling loop checking a completion flag, instead of each operation returning a promise that resolved once. What practice would prevent this?
Returning a promise from each background operation lets completion be signaled once via resolution instead of being discovered by continuously polling a flag, eliminating the wasted CPU cycles. Continuing to poll each completion flag in a tight loop regardless of how many background operations are running concurrently is exactly what caused the CPU spike described in this incident. This resolve-once approach is the standard fix once tight polling loops are confirmed to be burning CPU.
5 / 5
During a PR review, a teammate asks why the team reaches for promises instead of plain callback functions passed directly into each asynchronous call, given that callbacks require no extra abstraction. What is the reasoning?
Promises trade a small abstraction cost for composable chaining and centralized error handling across asynchronous steps, while plain callbacks are simpler individually but nest deeply and duplicate error handling as more asynchronous steps are chained together. This is exactly why promises are favored once multiple asynchronous steps must be composed, while a single plain callback remains acceptable for one isolated asynchronous call.
What does the "Futures and Promises Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to futures and promises vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.