5 exercises — technical concepts that non-native speakers frequently confuse because they sound similar or are used interchangeably in casual speech, but have precise distinct meanings.
Word pairs covered in this set
Library vs. Framework — who calls whom (inversion of control)
Authentication vs. Authorization — identity vs. access rights
Parameter vs. Argument — definition placeholder vs. actual value
Latency vs. Throughput — time per op vs. ops per second
Compile-time vs. Runtime — when the error occurs
0 / 5 completed
1 / 5
A candidate in a tech interview is asked: "What is the difference between a library and a framework?" Which answer is most accurate?
Library vs. Framework — Inversion of Control This is one of the most commonly mixed-up pairs in IT English, and the distinction matters in interviews and documentation.
Library: A collection of reusable code that you call. You are in control of when and how to use it. Examples: requests (Python), lodash (JavaScript), Spring Data (Java). You call the library functions; the library does not call your code.
Framework: A structure that defines the architecture and calls your code. You fill in the blanks (hooks, controllers, event handlers); the framework invokes them. Examples: Django, React, Spring MVC, Rails. The classic definition: "Don't call us, we'll call you" — this is called the Hollywood Principle or Inversion of Control.
In a sentence: "We used Vue.js as our frontend framework and Axios as an HTTP library."
2 / 5
A security engineer writes in a report: "The endpoint failed to verify authentication, allowing unauthorized data access." Is this the correct term?
Authentication (AuthN) vs. Authorization (AuthZ) These two are the most commonly confused security terms in IT English. Mixing them up in a security report, code review, or interview is a red flag.
Authentication (AuthN): WHY ARE YOU? Verifying the identity of a user or system. "Are you who you claim to be?" Mechanisms: passwords, MFA, biometrics, JWT tokens, OAuth login. If this fails: you can't log in at all. Error code: 401 Unauthorized (confusingly named — it actually means "unauthenticated").
Authorization (AuthZ): WHAT CAN YOU DO? Determining what an authenticated identity is allowed to do. "You are logged in — but do you have permission to see this data?" Mechanisms: RBAC, ACLs, IAM policies, scopes. If this fails: you're logged in but can't access the resource. Error code: 403 Forbidden.
In the question: the user was logged in (authentication passed) but accessed data they shouldn't have (authorization failed). The correct term is authorization.
A developer says: "The function takes two arguments: the base URL and the timeout." Later a colleague says the correct word is "parameters". Who is right?
Parameter vs. Argument — a subtle but real distinction Both words appear constantly in tech documentation and interviews. Many developers use them interchangeably in conversation, but the precise technical meanings differ:
Parameter: The variable defined in the function signature (definition). It's a placeholder. Example: function fetchData(url, timeout) — here url and timeout are parameters.
Argument: The actual value passed when calling the function. Example: fetchData("https://api.example.com", 5000) — here "https://api.example.com" and 5000 are arguments.
Memory trick: Parameter = Placeholder (lives in the definition). Argument = Actual value (lives in the call).
In practice: both the developer and the colleague are making reasonable points — strict precision favors "parameters" for the function definition, but "arguments" when talking about what to pass. The correct answer acknowledges this is a nuanced distinction, not a black-and-white error. The developer saying "two arguments" is informally acceptable; in strict documentation, "two parameters" is more precise for the function definition.
4 / 5
A backend engineer reports: "After the optimization, the system now handles 10,000 requests per second with sub-100ms latency." Are they using these metrics correctly?
Latency vs. Throughput — two orthogonal performance dimensions These two are the most important IT performance metrics — and they are often confused or conflated.
Latency: The time it takes to complete one operation — from request to response. Measured in milliseconds (ms), microseconds (µs), or seconds. "Sub-100ms latency" means each individual request is answered in under 100ms. Also appears as: P50/P95/P99 latency (percentile latency), round-trip time (RTT), response time.
Throughput: The number of operations completed per unit of time. Measured in requests per second (RPS), transactions per second (TPS), queries per second (QPS), or bytes per second (Bps). "10,000 RPS" = the system can process 10,000 requests every second.
They are related but orthogonal: you can have high throughput with high latency (a pipeline processes many items but each takes a long time), or low throughput with low latency (each item is fast but only one is processed at a time).
The engineer's sentence is correct: both metrics are reported together because they describe different dimensions of system performance.
5 / 5
A developer writes: "We get a NullPointerException — that's a compile-time error." Is this correct?
Compile-time vs. Runtime errors — a fundamental distinction Understanding and using these terms correctly matters for debugging, code review, and technical interviews.
Compile-time errors: Detected during compilation, before the program runs. The code fails to build. Examples: syntax errors, type mismatches in statically-typed languages, missing imports, undeclared variables. "The code does not compile."
Runtime errors: Occur during execution, after the program has compiled and started running. Examples: NullPointerException (Java, accessing a null reference), IndexError (Python, list index out of range), SegFault (C/C++, illegal memory access), division by zero. "The code compiled but crashed when it ran."
NullPointerException specifically: This is always a runtime error. The compiler cannot always know at compile time that a reference will be null — that depends on the program's execution state. (Note: modern tools like Kotlin's null safety and TypeScript's strict mode can catch some potential null problems at compile time — but the exception itself is runtime.)
Also know: "logic errors" — code compiles and runs but produces wrong results. These are the hardest to catch.