5 exercises on technical terms that developers and engineers often use interchangeably — even though they have distinct meanings. Getting these right signals technical fluency.
The most confused technical word pairs in IT English
parameter (defined in signature) vs argument (passed at call)
method (belongs to object) vs function (standalone)
compile-time (caught by compiler) vs runtime (occurs while running)
scalability (handles more load) vs performance (fast at current load)
latency (delay) vs throughput (rate) vs bandwidth (capacity)
0 / 5 completed
1 / 5
A code reviewer comments: "You're passing the wrong ___ — the function expects a string, but you're sending an integer." Which word belongs in the blank?
Argument — the actual value you pass when calling a function:
This is one of the most common confused word pairs in programming English. The distinction is precise:
Parameter (also: formal parameter)
The variable name declared in the function definition
It is a placeholder — it exists in the code structure, not yet associated with a value
"function greet(name)" — name is a parameter"
Argument (also: actual argument, actual parameter)
The actual value you supply when you call the function
It is data — it flows into the parameter at call time
"greet("Alice")" — "Alice" is an argument
Memory aid: "You define parameters, you pass arguments." The action verb matters:
✅ "The function takes two parameters."
✅ "Call the function with these arguments."
✅ "Pass a string argument to the first parameter."
In practice: Many developers use these words interchangeably in casual speech, and you will hear "pass a parameter" often. In a technical code review or documentation, using them precisely signals attention to detail.
Related terms:
default parameter — a parameter with a fallback value if no argument is provided
named argument (Python, Kotlin) — an argument explicitly addressed to a parameter by name
variadic parameter — a parameter that accepts any number of arguments (*args, ...rest)
type annotation / type hint — declaring what type an argument must be
2 / 5
During an OOP design discussion, a senior engineer asks: "Should calculateTax() be a standalone function or a class method?" What is the core difference?
Method vs. Function — the OOP distinction:
Function
A standalone block of reusable code
Defined outside any class (or inside, depending on language)
Operates purely on its inputs: calculateTax(price, rate)
Has no implicit access to object state
Languages: all procedural/functional languages; also exists in OOP languages
Method
A function that belongs to an object or class
Has implicit access to the object's own data via this / self
cart.calculateTax() — knows about this.items, this.discountCode, etc.
Can read and modify object state (instance method) or class state (class/static method)
Types of methods:
instance method — operates on one specific object (self/this)
class method / static method — belongs to the class, not a specific instance; no self/this access to instance data
getter / setter — methods for reading/writing object properties
Language notes:
Python: def greet(self): — the explicit self makes it a method
JavaScript: a function defined on an object literal or class body is a method
Java/C#: everything must be inside a class — "function" is rarely used; "method" is the standard
Go: uses "method" only for functions with a receiver type; other functions are just "functions"
In conversation: "We should make this a static method — it doesn't need instance data." / "This logic should be a standalone utility function, not tied to the class."
3 / 5
A developer files a bug report: "App crashes on startup with NullPointerException." At which stage does this type of error occur?
Runtime error — happens while the program is running:
Understanding when an error occurs is fundamental to diagnosing and fixing it.
Compile-time — errors caught by the compiler before the program runs
Logic error — the code runs without crashing but produces wrong results
No exception is thrown; the output is simply incorrect
Hardest to detect — requires tests and code review
Key vocabulary:
"The compiler rejects / flags this at compile-time."
"This exception is thrown at runtime."
"Static analysis catches compile-time errors before execution."
"Add runtime validation to guard against null inputs."
4 / 5
A CTO reviews an architecture proposal: "Our current system handles 1,000 requests/second well, but can it handle 100,000?" This question is primarily about which concept?
Scalability vs. Performance — two related but distinct concepts:
Performance
How fast / efficiently a system operates at its current load
Measured by: response time, latency, throughput at a specific concurrency level
"Our API responds in 50ms for 1,000 concurrent users." — that is performance
The ability to maintain acceptable performance as load increases — by adding resources
A scalable system can handle 10× or 100× the load if you add hardware/instances
Two types: — Horizontal scaling (scale out): add more servers/instances — Vertical scaling (scale up): add more CPU/RAM to existing servers
Key test: "If we add 10 more servers, does throughput increase proportionally?"
Why the distinction matters:
A system can be fast (good performance) but not scalable — works fine with 100 users, collapses at 10,000
A system can be scalable but slow — you can add pages of servers, but each request is 2 seconds
In conversation:
"We need to improve performance" → optimise existing code, reduce latency
"We need to improve scalability" → redesign for horizontal growth, add load balancers, use microservices, introduce queues
"Does this design scale?" → will it still work under 100× the current load?
5 / 5
A product manager asks: "Why does our video streaming service feel slow even though our servers have plenty of unused bandwidth?" Which metric best explains this user experience issue?
Latency, Throughput, and Bandwidth — the three must-know network terms:
These three concepts are constantly confused even by experienced engineers. The streaming example is perfect for illustrating the differences.
Latency
The time delay for a single piece of data to travel from source to destination
Measured in milliseconds (ms)
High latency = things feel slow and unresponsive, even if the connection is "fast"
Examples: round-trip time (RTT), ping time, time-to-first-byte (TTFB)
"Our CDN reduced latency from 300ms to 30ms for Asian users."
Streaming issue: high latency causes buffering, delayed start, out-of-sync audio
Throughput
The actual amount of data (or operations) successfully transferred per unit of time
Measured in MB/s, requests/second, transactions/second
"The pipeline processes 500 messages/second." — throughput
Related to latency: high latency reduces throughput (you're waiting for each response)
Bandwidth
The maximum possible data transfer rate — the capacity of the channel
Measured in Mbps, Gbps
"We have a 1Gbps link to the data center." — bandwidth
Bandwidth is the ceiling; throughput is the actual rate; latency is the delay
You can have high bandwidth but also high latency (a fast but long pipe)
The classic analogy:
Imagine a water pipe: bandwidth = pipe diameter (how much can flow), throughput = actual flow rate now, latency = how long it takes for water to travel from one end to the other
In the streaming scenario: The servers have high bandwidth (big pipe) but latency between the user and server is high — each video segment takes too long to start delivering, causing buffering.