5 fill-in-the-blank exercises. Read each realistic sentence from a code review, sprint planning, or postmortem — then choose the technical term that fits the blank.
Terms practised in this set
Regression — a test type that checks nothing existing was broken by a change
Feature flag — a toggle to enable/disable a feature without redeploying
Idempotent — same result whether called once or many times
Refactor — restructure code without changing its behaviour
Scalable — able to handle increasing load without degrading
0 / 5 completed
1 / 5
Choose the word that best completes the sentence:
"After merging the hotfix branch, we need to run the _____ tests to make sure the new patch didn't break any existing functionality."
Regression tests verify that previously working features still work after a change (a bug fix, a refactor, a new feature). The name comes from "software regression" — when a fix accidentally re-introduces an old bug or breaks something else.
The other options in context: • Smoke tests — fast, shallow checks that the application starts and the most critical paths work. Run first, before deeper tests. "Does the app boot? Does login work?" • Unit tests — test a single function or class in isolation. Fast and focused, but don't test component interaction. • Integration tests — test how multiple components work together (e.g., API + database). Slower and broader than unit tests.
How they fit in a CI pipeline: commit → unit tests (fast) → integration tests (slower) → regression tests → deploy
Common usage: "The regression suite caught a broken session timeout that wasn't covered by the unit tests." "We don't have enough regression coverage — every hotfix risks breaking the login flow."
2 / 5
Choose the term that best completes the sentence:
"We'll ship the dark mode feature behind a _____ and enable it only for internal employees first, before rolling it out to all users."
Feature flag (also called a feature toggle or feature switch) — a configuration variable that enables or disables a feature at runtime without redeploying code. The code ships, but the feature is "off" for most users until explicitly enabled.
Common use cases: • Canary releases — enable the feature for 1–5% of users to monitor for errors before full rollout • Internal testing — enable for employees only first ("dogfooding") • A/B testing — show feature A to 50% of users and feature B to the other 50%; measure which performs better • Kill switch — if a released feature causes a spike in errors, disable it instantly without a rollback deployment • Gradual rollout — enable for 10%, then 25%, then 50%, then 100%
The other options: • Rate limiter — restricts how many requests a user/IP can make per second/minute • Circuit breaker — stops calling a failing downstream service to prevent cascading failures • Load balancer — distributes incoming traffic across multiple server instances
3 / 5
Choose the term that best completes the sentence:
"The payment service's endpoint is not _____ — if a client retries a timed-out request, it creates a duplicate charge."
Idempotent (adjective) — producing the same result whether you perform the operation once or many times. From mathematics: f(f(x)) = f(x).
In APIs and distributed systems, idempotency is critical because networks fail and clients retry requests. A retry in a non-idempotent endpoint can have unintended consequences (duplicate charges, double emails, duplicate database records).
HTTP method idempotency: • GET — idempotent and safe (no side effects) • PUT — idempotent (setting a resource to a value twice gives the same result) • DELETE — idempotent (deleting what's already deleted returns the same state) • POST — NOT idempotent by default (each call creates a new resource) • PATCH — may or may not be idempotent, depending on implementation
Solution for non-idempotent operations: use an idempotency key — a unique ID the client sends with the request. The server stores the key and, if it sees the same key again, returns the original response instead of processing again. Stripe, Braintree, and most payment APIs require this.
Example header:Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
4 / 5
Choose the term that best completes the sentence:
"The codebase has grown organically over five years. Before we add OAuth 2.0 support, we need to _____ the authentication module — it's a tangled mess of global variables and if-else chains."
Refactor (verb) — to restructure existing code without changing its external behaviour. The goal is to improve readability, maintainability, and structure — not to add features or fix bugs. Named after "factoring" in mathematics: rearranging an expression into a cleaner form.
Key point: refactoring preserves behaviour. If you change what the code does, it's not a refactor — it's a modification.
Common refactoring operations: • Extract function — pull repeated code into a named function • Rename variable — give a variable a clearer name (x → userSessionToken) • Replace conditional with polymorphism — replace nested if-else chains with object-oriented design patterns • Remove duplication — DRY (Don't Repeat Yourself) • Split large function — a 300-line function becomes five 60-line functions
Refactoring and technical debt: technical debt accumulates when developers take shortcuts ("we'll clean it up later"). Refactoring pays down that debt. The quote in the exercise is a classic description of technical debt — "tangled mess of global variables."
The other options: • Deprecate — mark something as outdated and scheduled for removal, but keep it temporarily so existing users can migrate • Document — write documentation; doesn't restructure the code • Compile — translate source code to machine code; a build-time operation
5 / 5
Choose the term that best completes the sentence:
"The app had 2 million active users, but our infrastructure was not _____ — when traffic doubled during the product launch, the API servers fell over and we had 45 minutes of downtime."
Scalable (adjective) — capable of handling increasing load (more users, more data, more requests) without degrading in performance or availability. Scalability is one of the most important non-functional requirements in software engineering.
Two types of scaling: • Vertical scaling (scaling up) — add more resources to a single server: more CPU, more RAM, faster storage. Simple, but has a physical upper limit and creates a single point of failure. • Horizontal scaling (scaling out) — add more servers and distribute the load between them. More complex (requires load balancing, stateless design, distributed data), but theoretically unlimited. Preferred for modern cloud architectures.
Why "not scalable" causes outages: If servers are stateful (store user sessions locally), you can't just add more servers — sessions break. If the database is a single node, it becomes the bottleneck. If the application can't run in multiple parallel instances, horizontal scaling is impossible.
Related terms: • Load balancer — distributes traffic across multiple instances • Autoscaling — cloud infrastructure that automatically adds/removes servers based on traffic • Stateless design — each request is self-contained; sessions stored in Redis/JWT, not in server memory — required for horizontal scaling • Elasticity — ability to scale both up (more load) and back down (less load) dynamically