5 exercises on grammar errors frequently made by non-native English speakers in IT contexts — uncountable nouns, wrong prepositions, and incorrect verb patterns.
Grammar patterns behind these errors
"research / information / feedback / advice" — uncountable, no plural, no article
"suggest" — followed by -ing or that-clause, NOT infinitive
"according to" — for sources/third parties, NOT for your own views
"provide" — collocates with nouns directly: "provide information", not "provide informations"
0 / 18 completed
1 / 18
A non-native speaker writes: "I have made a research about microservice patterns." What is the error and what is the correct version?
"Make research" — the uncountable noun trap:
The rules:
"Research" (when meaning investigation/study) is uncountable in standard English — no article, no plural: "I did research" (not "a research" or "researches")
The standard verb collocation is do research or conduct research — not "make research"
Correct forms:
"I did research on microservice patterns."
"I conducted research into distributed systems."
"I carried out a study on microservice patterns."
Note: "A research" with an article does occur in formal academic writing in some specific contexts ("a piece of research", "a study"), but "make a research" is always an error.
Other uncountable nouns that trip up developers:
"advice" (not "an advice") → give advice
"feedback" (not "a feedback") → provide feedback
"information" (not "informations") → share information
"work" (usually uncountable) → do some work, not "make a work"
2 / 18
In a Slack message, a developer writes: "Can we discuss about the deployment strategy in the next sync?" What is wrong and how do you fix it?
"Discuss about" — the extra preposition error:
"Discuss" is a transitive verb — it takes a direct object directly, without needing a preposition. This is different from "talk" (which uses "about") or "speak" (which uses "about" or "on").
Correct:
"Can we discuss the deployment strategy?"
"We discussed the timeline in the meeting."
"I need to discuss something with you."
Common confusion: Many languages have a preposition here (Spanish: "hablar sobre", French: "parler de"), and "talk about" is also correct in English — but "discuss about" is always wrong.
Similar verbs that do NOT need "about":
"discuss" ✓ → "discuss the issue" (NOT "discuss about the issue")
"mention" ✓ → "mention the deadline" (NOT "mention about the deadline")
"consider" ✓ → "consider the options" (NOT "consider about the options")
Correct alternatives:
"Can we talk about the deployment strategy?" ✓
"Can we discuss the deployment strategy?" ✓
"Can we go over the deployment strategy?" ✓
3 / 18
A senior engineer replies in a team meeting: "I suggest to run a canary deployment first." What is the grammatical error?
"Suggest to do" — the infinitive trap:
This is one of the most common grammar errors by non-native English speakers — using "suggest + to-infinitive" by analogy with other verbs like "want to," "decide to," "plan to."
"Suggest" does NOT take a to-infinitive. It takes:
A gerund (-ing): "I suggest reviewing the logs first."
A that-clause: "I suggest that we review the logs first."
A noun: "I suggest a canary deployment."
More examples:
✗ "I suggest to use Docker." → ✓ "I suggest using Docker."
✗ "They suggested to add more tests." → ✓ "They suggested adding more tests."
Compare with verbs that DO take infinitives:
"I recommend running tests first." (also: recommend that + clause)
"I want to merge tonight."
"I plan to refactor this."
4 / 18
A developer writes in a design review comment: "According to me, the current architecture will not scale." What is the problem with "according to me"?
"According to me" — the attribution error:
"According to" is used to cite a source외 — a document, a person other than yourself, a standard, a report. It means "as stated by" or "as reported by."
How "according to" is correctly used:
"According to the RFC specification, headers must be case-insensitive."
"According to the CTO, we need to scale to 10M users."
"According to Google Lighthouse, the page scores 62."
You cannot be a source for your own opinion — "according to me" is saying "as stated by me," which is redundant and incorrect.
Correct alternatives for personal opinions:
"In my opinion, the current architecture will not scale." — formal
"I think the current architecture won't scale." — neutral
"I believe this approach will have scaling issues." — slightly more formal
"From my perspective, this won't scale." — professional
"In my view, we should consider a different approach." — formal
5 / 18
A developer describes a function: "This function provides informations about the current user session." How many errors are in this sentence?
"Informations" — the uncountable noun rule:
"Information" is an uncountable (mass) noun in English — it has no plural form. You cannot say "informations," "an information," or "two informations."
How to talk about multiple items of information:
"information" (unspecified amount) → "this provides information about…"
"a piece of information" (one item) → "I have a useful piece of information"
"pieces of information" (multiple items) → "here are three pieces of information"
"details" (countable, often used instead) → "the function returns session details"
The verb "provide" is correct here: "provide information about" is a standard formal collocation. Note the preposition: "provide information about" or "provide information on" — both are fine. "Provide information of" is generally incorrect.
Other commonly incorrectly pluralised uncountable nouns in tech writing:
✗ "feedbacks" → ✓ "feedback" or "pieces of feedback"
✗ "knowledges" → ✓ "knowledge"
✗ "advices" → ✓ "advice" or "pieces of advice"
✗ "equipments" → ✓ "equipment"
✗ "softwares" → ✓ "software" or "software applications"
6 / 18
Sarah: 'The API response is showing a 500 error. I've checked the logs and it seems like there's an issue with the database connection.'
Mark (code reviewer) replies: 'Okay, can you *debug* this further?'
The key here is understanding that technical discussions in code reviews require precise language. While 'debug' is a common term, it can be interpreted differently by non-native speakers. Mark isn't asking Sarah to *perform* debugging, but rather to investigate the problem further using available tools and information – which is perfectly acceptable and professional. The other options misinterpret the request for more details as requiring immediate action or using an overly casual phrase.
7 / 18
Liam writes in a Pull Request description: 'I've implemented the new feature. It's fully functional and ready for merge.' Mark, his senior colleague, replies with: 'Great! Can you add some tests to cover the edge cases?' What is the most appropriate response Liam should give?
Liam's original statement is overly assertive and doesn't acknowledge the feedback. While he *could* prioritize testing later, responding positively to Mark's suggestion demonstrates collaboration and a willingness to improve the code quality. Option B shows acceptance of advice – a key skill in professional development environments – while options A and C are dismissive and potentially problematic. Option D is incorrect; thorough testing is always beneficial.
8 / 18
Sarah: 'The API response is showing a 500 error. I've checked the logs and it seems like there's an issue with the database connection.'
Mark (code reviewer) replies: 'Okay, can you *debug* this further?'
The key here is understanding that technical discussions in code reviews require precise language. While 'debug' is a common term, it can be interpreted differently by non-native speakers. Mark isn't asking Sarah to *perform* debugging, but rather to investigate the problem further using available tools and information – which is perfectly acceptable and professional. The other options misinterpret the request for more details as requiring immediate action or using an overly casual phrase.
9 / 18
Liam writes in a Pull Request description: 'I've implemented the new feature. It's fully functional and ready for merge.' Mark, his senior colleague, replies with: 'Great! Can you add some tests to cover the edge cases?' What is the most appropriate response Liam should give?
Liam's original statement is overly assertive and doesn't acknowledge the feedback. While he *could* prioritize testing later, responding positively to Mark's suggestion demonstrates collaboration and a willingness to improve the code quality. Option B shows acceptance of advice – a key skill in professional development environments – while options A and C are dismissive and potentially problematic. Option D is incorrect; thorough testing is always beneficial.
10 / 18
Sarah: 'The API response is showing a 500 error. I've checked the logs and it seems like there's an issue with the database connection.'
Mark (code reviewer) replies: 'Okay, can you *debug* this further?'
The key here is understanding that technical discussions in code reviews require precise language. While 'debug' is a common term, it can be interpreted differently by non-native speakers. Mark isn't asking Sarah to *perform* debugging, but rather to investigate the problem further using available tools and information – which is perfectly acceptable and professional. The other options misinterpret the request for more details as requiring immediate action or using an overly casual phrase.
11 / 18
Liam writes in a Pull Request description: 'I've implemented the new feature. It's fully functional and ready for merge.' Mark, his senior colleague, replies with: 'Great! Can you add some tests to cover the edge cases?' What is the most appropriate response Liam should give?
Liam's original statement is overly assertive and doesn't acknowledge the feedback. While he *could* prioritize testing later, responding positively to Mark's suggestion demonstrates collaboration and a willingness to improve the code quality. Option B shows acceptance of advice – a key skill in professional development environments – while options A and C are dismissive and potentially problematic. Option D is incorrect; thorough testing is always beneficial.
12 / 18
Sarah: 'The API response is showing a 500 error. I've checked the logs and it seems like there's an issue with the database connection.'
Mark (code reviewer) replies: 'Okay, can you *debug* this further?'
The key here is understanding that technical discussions in code reviews require precise language. While 'debug' is a common term, it can be interpreted differently by non-native speakers. Mark isn't asking Sarah to *perform* debugging, but rather to investigate the problem further using available tools and information – which is perfectly acceptable and professional. The other options misinterpret the request for more details as requiring immediate action or using an overly casual phrase.
13 / 18
Liam writes in a Pull Request description: 'I've implemented the new feature. It's fully functional and ready for merge.' Mark, his senior colleague, replies with: 'Great! Can you add some tests to cover the edge cases?' What is the most appropriate response Liam should give?
Liam's original statement is overly assertive and doesn't acknowledge the feedback. While he *could* prioritize testing later, responding positively to Mark's suggestion demonstrates collaboration and a willingness to improve the code quality. Option B shows acceptance of advice – a key skill in professional development environments – while options A and C are dismissive and potentially problematic. Option D is incorrect; thorough testing is always beneficial.
14 / 18
David writes in a Slack message: 'The server is down. We need to investigate the root cause.' What's the most professional way to respond?
The original message is overly urgent and lacks specifics. Asking for symptom description allows for more targeted investigation. 'Checking monitoring dashboards' demonstrates proactive problem-solving, while the other options are either too casual or demand immediate action without understanding the situation. Focusing on gathering information is key in technical communication.
15 / 18
Mark writes in a Pull Request description: 'This PR addresses the high latency issue.' What's wrong with this statement?
While the statement identifies a problem (latency), it lacks specifics. Developers need concrete details about the solution to assess its effectiveness and potential impact. 'High' is subjective; providing metrics (e.g., 'reduced latency by 30ms') would be much more informative and professional.
16 / 18
Elena says to her team during a standup: 'I've been working on the data model for the new API. It's pretty complex.' What is the best way to refine this statement?
Elena's original statement is vague and doesn't convey the core issue – complexity. Describing it as 'intricate' provides a more technical and useful description for her team to understand the scope of her work. The other options are either too informal or focus on secondary aspects (performance, effort).
17 / 18
Ben writes in a code review comment: 'This function doesn't handle edge cases.' What is the most helpful way to suggest improvement?
Ben's comment is a general observation. Suggesting 'consider what happens when the input is null or invalid' provides specific guidance on how to address the issue – identifying and handling potential edge cases. The other options are too vague or critical in tone.
18 / 18
Olivia writes: 'The API returns a status code of 404 when I try to access the resource.' What is the most appropriate response?
A 404 status code indicates a resource isn't found. The best response is to investigate whether the resource exists and if the URL is correctly formatted – this is a standard troubleshooting step for API errors. Simply stating 'the API is broken' or contacting support without investigation is inefficient.
What does the "Common Learner Mistakes — IT English" 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 "Common Learner Mistakes — IT English"?
This exercise has 18 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.