7 exercises — words that look like your native language equivalent but mean something different in English. These errors are extremely common and easy to fix once you know them.
False cognates covered in this set
actual — means "real/genuine", NOT "current/latest"
realize — means "understand/notice", NOT "implement/build"
sensible — means "reasonable", NOT "sensitive/fragile"
control (verb) — means "manage/regulate", NOT "check/verify"
eventually — means "at some future point", NOT "possibly"
implement (noun) — almost never used as a noun in IT; use "implementation"
perspective vs. prospect — point of view NOW vs. future possibility
0 / 20 completed
1 / 20
A non-native developer writes in a status update: "The actual API version is 2.3 — please update your clients." What is the mistake, and what did they mean?
False friend alert: "actual" ≠ "current" or "latest" In English, actual means real, genuine, or true — often used for emphasis or contrast: "The actual problem is deeper than it looks." "I thought it would take a week, but the actual time was three weeks." It does NOT mean "current" or "up-to-date."
Many languages have a false cognate that means "current": Ukrainian актуальний, Russian актуальный, Spanish actual, German aktuell, French actuel, Italian attuale — all mean "current, up-to-date."
Correct versions: ✅ "The current API version is 2.3" ✅ "The latest version is 2.3" ✅ "As of today, the API is on version 2.3"
The word "actual" can be used naturally: "The actual bug was in the cache layer" (= the true/real bug, not what we thought).
2 / 20
A developer from Germany writes: "We realized the authentication feature last sprint." What did they mean, and what should they have written?
False friend alert: "realize" ≠ "implement/build" In English, realize means to become aware of or understand suddenly: "I realized there was a bug." "She realized the deadline had passed."
The false cognate: German realisieren, French réaliser, Spanish realizar, Italian realizzare — all mean "to implement, build, or carry out." This is a systematic error that affects many European non-native speakers.
Correct alternatives for "we built it": ✅ "We implemented the authentication feature" ✅ "We built / developed / shipped / delivered the feature" ✅ "We completed the authentication work"
You can use "realize" in a different sense: "We realized the potential of the new architecture" (= made potential become actual). But in everyday tech communication, stick to "implement" or "build."
3 / 20
A developer writes in a PR comment: "This is a very sensible approach to the caching problem." Is this correct? What does it mean?
"Sensible" vs. "sensitive" — two similar words with different meanings Sensible = reasonable, practical, showing good judgment: "That's a sensible solution." "A sensible default is to fail loudly." "Sensible architecture decisions make the codebase easier to change."
Sensitive = (1) responsive to slight changes: "sensitive data," "a sensitive configuration parameter"; (2) emotionally affected: "she's sensitive about deadlines"; (3) confidential/private: "sensitive user information."
Common confusions in IT context: ❌ "This data is very sensible" → means it's reasonable, not private ✅ "This data is very sensitive" → correct for private/confidential data
❌ "Use sensible timeout values for the network calls" → this is actually OK! "sensible" = reasonable values ✅ "Sensitive timeout values" → would mean fragile/easily affected values
The PR comment in the question is correct — saying an approach is "sensible" means it's well-reasoned and practical.
4 / 20
A QA engineer writes in a test plan: "Please control the log output after each test case." What went wrong?
False friend: "control" ≠ "check/verify" In English, control as a verb means to regulate, manage, or have authority over something: "Access control", "version control", "control the flow of data." It does NOT mean "check" or "verify."
The false cognate: German kontrollieren, French contrôler, Spanish controlar, and many other European languages all use a "control" equivalent to mean "check" or "inspect." This creates systematic errors from many native speakers.
Correct alternatives: ✅ "Please check the log output after each test case" ✅ "Please verify / review / inspect the log output" ✅ "Please examine the log output"
"Control" in correct usage: "Access controls ensure only authorized users can read the data." "Version control tracks changes to the codebase." "We need to control the rate of API requests."
5 / 20
A team member writes: "Eventually, we can add this feature — it's not critical for the MVP." Is this correct usage of "eventually"?
"Eventually" — correct here, but watch the false friend trap In English, eventually = at some point in the future; after some time; sooner or later. It is correct in the sentence above: "We can add this feature later, at some unspecified future point."
The false friend trap: Spanish/Portuguese eventual / Italian eventuale / French éventuel mean "possible, potential, or contingent." This leads to errors like: ❌ "An eventual error could cause data loss" (meant: "A possible error…") ✅ "A possible / potential error could cause data loss"
Warning for IT context: "eventual consistency" is a valid and common IT term (a consistency model in distributed systems where all replicas eventually converge to the same state). Do NOT confuse this with a false friend usage — "eventual consistency" uses "eventual" correctly in English (= will happen at some point).
Summary: "eventually" (adverb) ✅ correct English. "eventual" (adjective) ✅ exists in English but rare — prefer "possible," "potential," "future," or "eventual consistency" only in its specific technical meaning.
6 / 20
A non-native developer writes in a design doc: "We need a new implement for handling OAuth tokens — something lightweight." What is wrong with this sentence, and what should it say?
"Implement" as a noun — an almost invisible false friend trap.
In everyday English, "implement" can technically be a noun meaning a hand tool or instrument (a farming implement, a kitchen implement). But in modern IT English, this usage is essentially never used.
The error: Non-native speakers (especially from Slavic languages) sometimes use "implement" as if it were a direct translation of the noun form (e.g., Ukrainian імплемент / реалізація, Russian реализация). But native English speakers in IT always use the noun form:
Correct substitutions:
"We need a new implementation for handling OAuth tokens." ✅
"We need a new mechanism / component / library / module." ✅
"We need to implement a new OAuth token handler." ✅ (using implement as a verb)
The verb "implement" is used constantly and is correct:
"We need to implement OAuth." ✅
"I implemented the caching layer." ✅
"The feature has been implemented." ✅
Memory rule: "implement" is almost always a verb in IT English. When you need the noun — use implementation, or a more specific noun (component, module, solution, handler, service).
7 / 20
A developer writes in a project retrospective: "From my perspective, we should adopt Kubernetes. The prospects for our platform growth are excellent if we modernise the infrastructure." Is the use of "perspective" and "prospects" correct here?
Both are used correctly — but these words are frequently confused by non-native speakers.
perspective (noun) = a point of view; the way someone sees or understands something
"From my perspective, this approach has risks." ✅ (= in my opinion / from my point of view)
"From a technical perspective, the solution is sound." ✅
"We need to consider the user's perspective." ✅
Plural: "different perspectives" = different points of view
prospect(s) (noun) = a future possibility; likelihood; potential for something to happen
"The prospects for this project are excellent." ✅ (= future chances of success)
"Career prospects" ✅ = future career opportunities
"There's a prospect of a promotion." ✅ (= a possibility/chance)
The common non-native confusion: In many languages, the word for "perspective" and "prospect/outlook" can overlap or be translated by the same word (e.g., Ukrainian перспектива = both "perspective" and "prospect/outlook"). In English, they are distinct:
perspective = point of view (NOW)
prospect = future possibility (FUTURE)
Common mistakes: ❌ "The perspective for the company is good." → ✅ "The prospects for the company are good." ❌ "From my prospects, this is risky." → ✅ "From my perspective, this is risky."
8 / 20
Sarah: 'The server's response time is consistently high – it's showing a latency of around 300ms. I've checked the network and database connections, but nothing obvious appears to be causing the issue. Let's investigate further.'
Mark (a senior developer) replies: 'That's good you're monitoring it closely. But frankly, that latency is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs).'
What does Mark *really* mean?
Mark isn't dismissing the issue entirely; he's validating that it *meets* the defined SLO. The key here is understanding that 'latency' in this context refers specifically to the time taken for a response – it doesn't automatically imply failure. A common misconception is to equate high latency with a problem needing immediate attention, but if the SLO allows for it, it's functionally acceptable. He's shifting the focus from *detecting* an issue to *confirming* that the observed behavior aligns with pre-established performance standards.
9 / 20
Mark's response, 'That's good you're monitoring it closely. But frankly, that latency is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs),' suggests what about the situation?
A) He's expressing genuine concern about the performance issue and wants a detailed investigation. B) He believes the reported latency meets pre-defined performance standards, indicating it doesn't require immediate action despite the monitoring. This is key to understanding his meaning C) The monitoring system itself is malfunctioning and needs immediate repair. D) The API endpoint is inherently slow and there's nothing he can do to improve it.
Mark isn't necessarily dismissing the issue. His statement that the latency 'is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs)' indicates he's acknowledging the monitoring but confirming that the measured performance falls within an agreed-upon range of tolerance. The common misconception is that a high number always signifies a problem, but SLOs define what's considered 'good enough' for performance; therefore, the response focuses on meeting predefined targets rather than expressing concern about the raw data.
10 / 20
Sarah: 'The server's response time is consistently high – it's showing a latency of around 300ms. I've checked the network and database connections, but nothing obvious appears to be causing the issue. Let's investigate further.'
Mark (a senior developer) replies: 'That's good you're monitoring it closely. But frankly, that latency is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs).'
What does Mark *really* mean?
Mark isn't dismissing the issue entirely; he's validating that it *meets* the defined SLO. The key here is understanding that 'latency' in this context refers specifically to the time taken for a response – it doesn't automatically imply failure. A common misconception is to equate high latency with a problem needing immediate attention, but if the SLO allows for it, it's functionally acceptable. He's shifting the focus from *detecting* an issue to *confirming* that the observed behavior aligns with pre-established performance standards.
11 / 20
Mark's response, 'That's good you're monitoring it closely. But frankly, that latency is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs),' suggests what about the situation?
A) He's expressing genuine concern about the performance issue and wants a detailed investigation. B) He believes the reported latency meets pre-defined performance standards, indicating it doesn't require immediate action despite the monitoring. This is key to understanding his meaning C) The monitoring system itself is malfunctioning and needs immediate repair. D) The API endpoint is inherently slow and there's nothing he can do to improve it.
Mark isn't necessarily dismissing the issue. His statement that the latency 'is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs)' indicates he's acknowledging the monitoring but confirming that the measured performance falls within an agreed-upon range of tolerance. The common misconception is that a high number always signifies a problem, but SLOs define what's considered 'good enough' for performance; therefore, the response focuses on meeting predefined targets rather than expressing concern about the raw data.
12 / 20
Sarah: 'The server's response time is consistently high – it's showing a latency of around 300ms. I've checked the network and database connections, but nothing obvious appears to be causing the issue. Let's investigate further.'
Mark (a senior developer) replies: 'That's good you're monitoring it closely. But frankly, that latency is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs).'
What does Mark *really* mean?
Mark isn't dismissing the issue entirely; he's validating that it *meets* the defined SLO. The key here is understanding that 'latency' in this context refers specifically to the time taken for a response – it doesn't automatically imply failure. A common misconception is to equate high latency with a problem needing immediate attention, but if the SLO allows for it, it's functionally acceptable. He's shifting the focus from *detecting* an issue to *confirming* that the observed behavior aligns with pre-established performance standards.
13 / 20
Mark's response, 'That's good you're monitoring it closely. But frankly, that latency is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs),' suggests what about the situation?
A) He's expressing genuine concern about the performance issue and wants a detailed investigation. B) He believes the reported latency meets pre-defined performance standards, indicating it doesn't require immediate action despite the monitoring. This is key to understanding his meaning C) The monitoring system itself is malfunctioning and needs immediate repair. D) The API endpoint is inherently slow and there's nothing he can do to improve it.
Mark isn't necessarily dismissing the issue. His statement that the latency 'is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs)' indicates he's acknowledging the monitoring but confirming that the measured performance falls within an agreed-upon range of tolerance. The common misconception is that a high number always signifies a problem, but SLOs define what's considered 'good enough' for performance; therefore, the response focuses on meeting predefined targets rather than expressing concern about the raw data.
14 / 20
Sarah: 'The server's response time is consistently high – it's showing a latency of around 300ms. I've checked the network and database connections, but nothing obvious appears to be causing the issue. Let's investigate further.'
Mark (a senior developer) replies: 'That's good you're monitoring it closely. But frankly, that latency is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs).'
What does Mark *really* mean?
Mark isn't dismissing the issue entirely; he's validating that it *meets* the defined SLO. The key here is understanding that 'latency' in this context refers specifically to the time taken for a response – it doesn't automatically imply failure. A common misconception is to equate high latency with a problem needing immediate attention, but if the SLO allows for it, it's functionally acceptable. He's shifting the focus from *detecting* an issue to *confirming* that the observed behavior aligns with pre-established performance standards.
15 / 20
Mark's response, 'That's good you're monitoring it closely. But frankly, that latency is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs),' suggests what about the situation?
A) He's expressing genuine concern about the performance issue and wants a detailed investigation. B) He believes the reported latency meets pre-defined performance standards, indicating it doesn't require immediate action despite the monitoring. This is key to understanding his meaning C) The monitoring system itself is malfunctioning and needs immediate repair. D) The API endpoint is inherently slow and there's nothing he can do to improve it.
Mark isn't necessarily dismissing the issue. His statement that the latency 'is perfectly acceptable for our API endpoint – it's within our Service Level Objectives (SLOs)' indicates he's acknowledging the monitoring but confirming that the measured performance falls within an agreed-upon range of tolerance. The common misconception is that a high number always signifies a problem, but SLOs define what's considered 'good enough' for performance; therefore, the response focuses on meeting predefined targets rather than expressing concern about the raw data.
16 / 20
Alex, a junior developer, sent this Slack message: 'Okay, let's just refactor this whole module.' What does Alex *really* mean in this context?
Alex uses 'refactor' to mean improving the internal structure of the code – making it more readable and maintainable – without changing its external behavior. The common misconception is that 'refactor' always implies a complete rewrite. This highlights the importance of clarifying technical jargon in informal communication.
17 / 20
During a standup meeting, Kai said: "We need to implement the API endpoint using RESTful principles." What is Kai's intention?
'RESTful principles' refers to adhering to the design constraints of Representational State Transfer (REST), a widely used architectural style for web services. This involves using HTTP methods like GET, POST, PUT, and DELETE with resources identified by URLs. It's a common misunderstanding that REST is about a specific technology.
18 / 20
Sarah, a senior developer, left this comment on a PR: "This code snippet is perfectly clear and efficient." Is Sarah's statement correct? What does it actually convey?
In this context, 'clear and efficient' is shorthand for saying that the code is easy to understand and performs well. It's a concise way of approving the code without delving into specific technical details. A more detailed explanation would be needed if there were performance issues or security concerns.
19 / 20
A developer, David, wrote in a PR description: "We'll integrate this service eventually. It's not critical for the MVP." What is the *most likely* meaning of 'eventually'?
'Eventually' here signifies a future time – likely after the MVP. It's a common way of indicating that a feature isn't immediately essential but may be added later. The key is understanding the context of 'MVP'.
20 / 20
Mark wrote in a Slack message: "Let's use this library – it's lightweight and easy to integrate." What does Mark mean by 'lightweight'?
In this context, 'lightweight' refers to the library's low resource consumption (memory and CPU) and minimal dependencies. It implies that it won't significantly burden the application or infrastructure – a crucial consideration for performance and scalability.
What does the "False Cognates in IT English — Exercise Set" exercise cover?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 "False Cognates in IT English — Exercise Set"?
This exercise has 20 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 False Friends & Tricky Words exercises?
Browse the full False Friends & Tricky Words 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.