4 exercises — learn to write specific, structured prompts that produce reliable, usable outputs.
0 / 25 completed
1 / 25
You need ChatGPT to write an error message for a failed file upload. Which prompt will produce the most useful result?
Option B is the well-structured prompt. It includes every component of a clear, specific prompt:
• Task — "write a user-facing error message" • Constraint — "max 20 words" • Context — "file upload failure caused by an unsupported file type" • Audience — "non-technical" users • Tone — "friendly" • Data to use — the supported formats list
The prompt anatomy for technical tasks: Role + Task + Context + Constraints + Output format. The more specific the input, the more useful the output. Vague prompts produce vague output that requires many revision iterations, wasting time.
For example, the output from Option B might be: "Oops! We couldn't upload your file. Please use JPG, PNG, PDF, or DOCX." — which is immediately usable.
2 / 25
You want the LLM to act as a code reviewer. Which system prompt will produce the most useful reviewing behaviour?
Option B is the professional system prompt technique. A good system prompt:
• Assigns an expert role — "senior TypeScript engineer with 10 years of experience" (primes domain knowledge) • Defines specific behaviours — the numbered list of what to always do • Specifies output format — "ISSUE / SUGGESTION / PRAISE" makes the response easy to scan • Sets tone — "concise and direct"
System prompts (instructions given at the start of a conversation, before user messages) shape every subsequent response. A strong system prompt eliminates the need to repeat instructions in every message.
System prompt pattern: You are [role]. When [task], always [behaviour 1], [behaviour 2]. Respond in [format].
3 / 25
You want a structured JSON output from an LLM for a list of tech terms. Which prompt is most effective?
Option C is the complete structured-output prompt. Key elements:
• Output type specified — "JSON array" • Quantity specified — "5 programming terms" • Schema defined — each field named with its type and constraints • Constraints per field — "max 15 words" for definition, enum for difficulty • Clean output instruction — "only the JSON, no additional text or markdown code fences" — this prevents the LLM from wrapping the JSON in prose or ```json blocks
For production use, always add: "Return only valid JSON that can be parsed by JSON.parse()."
This technique is commonly used when piping LLM output into application code. Without specifying the exact schema and "no extra text", you will often receive output that needs manual cleanup before parsing.
4 / 25
Your first prompt got a mediocre result. Which iterative prompting strategy is most effective?
Option C demonstrates targeted iterative prompting — the professional way to refine LLM output.
The pattern: 1. Diagnose — what specifically is wrong? (Too formal? Too long? Missing a key point? Wrong tone?) 2. Constrain — add a specific, measurable constraint that fixes the problem 3. Preserve — explicitly say what to keep ("keep all technical terms")
Common refinement phrases: • "The response was too long. Shorten to 3 sentences max." • "The tone is too casual. Rewrite in professional email style." • "You missed [X]. Include it after the second paragraph." • "The code has a bug on line 3. Fix only that line."
Saying "better" or "improve it" gives the model no direction and often results in a different problem. Restarting with the same prompt will give you a similar mediocre result.
5 / 25
John: 'I've used the prompt to generate a Python function for validating email addresses. It works fine for simple cases, but when I input an address with special characters like '@#$%^&*()_+-={}' it throws an exception. The generated code doesn't handle these characters correctly. Can you suggest how I could improve the prompt to get more robust validation?'
The key here isn't just asking for a fix, but guiding the LLM towards a systematic approach. Generating a unit test suite forces the model to consider various scenarios – including edge cases like special characters – and provides concrete examples of what constitutes valid/invalid input. Option A is insufficient as it simply describes the failure without suggesting a solution. While option D's advice is generally sound, it doesn't provide the LLM with enough context or direction for generating truly robust code. Option C directly addresses the issue by requesting explicit handling of formats and regular expressions, leading to a more targeted response.
6 / 25
Mark: 'I'm trying to get the LLM to generate a unit test for this function. The initial output was completely generic – just 'assert True'. I've added more context about the function's purpose and input validation, but it still produces basic tests. What's the best approach to refine my prompt and guide the LLM towards creating more relevant and useful tests?'
The key here is understanding that LLMs don't inherently *know* what constitutes a good unit test. While adding context helps, simply stating 'generate more relevant tests' isn't specific enough. Option 2 correctly identifies that the initial output was acceptable and highlights the need for guiding constraints – explicitly requesting coverage and examples dramatically improves the LLM's understanding of your requirements. Options A and D misinterpret the LLM's capabilities; B oversimplifies the process, and D suggests a fundamental flaw that isn't necessarily present.
7 / 25
Liam: 'I'm reviewing this PR for the payment processing service. The LLM generated a response suggesting we use `try...catch` blocks everywhere – which is fine in principle, but it's *everywhere*! It's massively increasing the complexity of our error handling and making debugging incredibly difficult. I need to guide the LLM towards more targeted solutions, not blanket coverage. How should I phrase my feedback to get a better response?'
Liam correctly identifies a common issue with AI-generated code suggestions: they often lack nuance and can introduce unnecessary complexity. The key here isn't simply stating the suggestion is 'incorrect,' but explaining *why* it's problematic – in this case, the impact on debugging. Providing feedback that steers the LLM towards more targeted solutions is crucial for effective prompting; the goal is to guide, not just reject.
8 / 25
David: 'Okay, I've asked the LLM to generate a SQL query for finding all customers who haven't placed an order in the last six months. The response is incredibly verbose and includes joins to tables I don't need – it's returning 10 columns of data! I just want a simple `SELECT` statement with `customer_id` and `email`. How can I better instruct the LLM to focus on the specific information I require?'
This scenario highlights the importance of being precise and directive in your prompts when requesting structured data from an LLM. The original prompt likely allowed for a broad interpretation, leading to an overly complex query. Explicitly stating what columns are needed (in this case `customer_id` and `email`) will constrain the LLM's response and improve its focus on generating the desired output – demonstrating that clear instructions are key to getting relevant results.
9 / 25
John: 'I've used the prompt to generate a Python function for validating email addresses. It works fine for simple cases, but when I input an address with special characters like '@#$%^&*()_+-={}' it throws an exception. The generated code doesn't handle these characters correctly. Can you suggest how I could improve the prompt to get more robust validation?'
The key here isn't just asking for a fix, but guiding the LLM towards a systematic approach. Generating a unit test suite forces the model to consider various scenarios – including edge cases like special characters – and provides concrete examples of what constitutes valid/invalid input. Option A is insufficient as it simply describes the failure without suggesting a solution. While option D's advice is generally sound, it doesn't provide the LLM with enough context or direction for generating truly robust code. Option C directly addresses the issue by requesting explicit handling of formats and regular expressions, leading to a more targeted response.
10 / 25
Mark: 'I'm trying to get the LLM to generate a unit test for this function. The initial output was completely generic – just 'assert True'. I've added more context about the function's purpose and input validation, but it still produces basic tests. What's the best approach to refine my prompt and guide the LLM towards creating more relevant and useful tests?'
The key here is understanding that LLMs don't inherently *know* what constitutes a good unit test. While adding context helps, simply stating 'generate more relevant tests' isn't specific enough. Option 2 correctly identifies that the initial output was acceptable and highlights the need for guiding constraints – explicitly requesting coverage and examples dramatically improves the LLM's understanding of your requirements. Options A and D misinterpret the LLM's capabilities; B oversimplifies the process, and D suggests a fundamental flaw that isn't necessarily present.
11 / 25
Liam: 'I'm reviewing this PR for the payment processing service. The LLM generated a response suggesting we use `try...catch` blocks everywhere – which is fine in principle, but it's *everywhere*! It's massively increasing the complexity of our error handling and making debugging incredibly difficult. I need to guide the LLM towards more targeted solutions, not blanket coverage. How should I phrase my feedback to get a better response?'
Liam correctly identifies a common issue with AI-generated code suggestions: they often lack nuance and can introduce unnecessary complexity. The key here isn't simply stating the suggestion is 'incorrect,' but explaining *why* it's problematic – in this case, the impact on debugging. Providing feedback that steers the LLM towards more targeted solutions is crucial for effective prompting; the goal is to guide, not just reject.
12 / 25
David: 'Okay, I've asked the LLM to generate a SQL query for finding all customers who haven't placed an order in the last six months. The response is incredibly verbose and includes joins to tables I don't need – it's returning 10 columns of data! I just want a simple `SELECT` statement with `customer_id` and `email`. How can I better instruct the LLM to focus on the specific information I require?'
This scenario highlights the importance of being precise and directive in your prompts when requesting structured data from an LLM. The original prompt likely allowed for a broad interpretation, leading to an overly complex query. Explicitly stating what columns are needed (in this case `customer_id` and `email`) will constrain the LLM's response and improve its focus on generating the desired output – demonstrating that clear instructions are key to getting relevant results.
13 / 25
John: 'I've used the prompt to generate a Python function for validating email addresses. It works fine for simple cases, but when I input an address with special characters like '@#$%^&*()_+-={}' it throws an exception. The generated code doesn't handle these characters correctly. Can you suggest how I could improve the prompt to get more robust validation?'
The key here isn't just asking for a fix, but guiding the LLM towards a systematic approach. Generating a unit test suite forces the model to consider various scenarios – including edge cases like special characters – and provides concrete examples of what constitutes valid/invalid input. Option A is insufficient as it simply describes the failure without suggesting a solution. While option D's advice is generally sound, it doesn't provide the LLM with enough context or direction for generating truly robust code. Option C directly addresses the issue by requesting explicit handling of formats and regular expressions, leading to a more targeted response.
14 / 25
Mark: 'I'm trying to get the LLM to generate a unit test for this function. The initial output was completely generic – just 'assert True'. I've added more context about the function's purpose and input validation, but it still produces basic tests. What's the best approach to refine my prompt and guide the LLM towards creating more relevant and useful tests?'
The key here is understanding that LLMs don't inherently *know* what constitutes a good unit test. While adding context helps, simply stating 'generate more relevant tests' isn't specific enough. Option 2 correctly identifies that the initial output was acceptable and highlights the need for guiding constraints – explicitly requesting coverage and examples dramatically improves the LLM's understanding of your requirements. Options A and D misinterpret the LLM's capabilities; B oversimplifies the process, and D suggests a fundamental flaw that isn't necessarily present.
15 / 25
Liam: 'I'm reviewing this PR for the payment processing service. The LLM generated a response suggesting we use `try...catch` blocks everywhere – which is fine in principle, but it's *everywhere*! It's massively increasing the complexity of our error handling and making debugging incredibly difficult. I need to guide the LLM towards more targeted solutions, not blanket coverage. How should I phrase my feedback to get a better response?'
Liam correctly identifies a common issue with AI-generated code suggestions: they often lack nuance and can introduce unnecessary complexity. The key here isn't simply stating the suggestion is 'incorrect,' but explaining *why* it's problematic – in this case, the impact on debugging. Providing feedback that steers the LLM towards more targeted solutions is crucial for effective prompting; the goal is to guide, not just reject.
16 / 25
David: 'Okay, I've asked the LLM to generate a SQL query for finding all customers who haven't placed an order in the last six months. The response is incredibly verbose and includes joins to tables I don't need – it's returning 10 columns of data! I just want a simple `SELECT` statement with `customer_id` and `email`. How can I better instruct the LLM to focus on the specific information I require?'
This scenario highlights the importance of being precise and directive in your prompts when requesting structured data from an LLM. The original prompt likely allowed for a broad interpretation, leading to an overly complex query. Explicitly stating what columns are needed (in this case `customer_id` and `email`) will constrain the LLM's response and improve its focus on generating the desired output – demonstrating that clear instructions are key to getting relevant results.
17 / 25
John: 'I've used the prompt to generate a Python function for validating email addresses. It works fine for simple cases, but when I input an address with special characters like '@#$%^&*()_+-={}' it throws an exception. The generated code doesn't handle these characters correctly. Can you suggest how I could improve the prompt to get more robust validation?'
The key here isn't just asking for a fix, but guiding the LLM towards a systematic approach. Generating a unit test suite forces the model to consider various scenarios – including edge cases like special characters – and provides concrete examples of what constitutes valid/invalid input. Option A is insufficient as it simply describes the failure without suggesting a solution. While option D's advice is generally sound, it doesn't provide the LLM with enough context or direction for generating truly robust code. Option C directly addresses the issue by requesting explicit handling of formats and regular expressions, leading to a more targeted response.
18 / 25
Mark: 'I'm trying to get the LLM to generate a unit test for this function. The initial output was completely generic – just 'assert True'. I've added more context about the function's purpose and input validation, but it still produces basic tests. What's the best approach to refine my prompt and guide the LLM towards creating more relevant and useful tests?'
The key here is understanding that LLMs don't inherently *know* what constitutes a good unit test. While adding context helps, simply stating 'generate more relevant tests' isn't specific enough. Option 2 correctly identifies that the initial output was acceptable and highlights the need for guiding constraints – explicitly requesting coverage and examples dramatically improves the LLM's understanding of your requirements. Options A and D misinterpret the LLM's capabilities; B oversimplifies the process, and D suggests a fundamental flaw that isn't necessarily present.
19 / 25
Liam: 'I'm reviewing this PR for the payment processing service. The LLM generated a response suggesting we use `try...catch` blocks everywhere – which is fine in principle, but it's *everywhere*! It's massively increasing the complexity of our error handling and making debugging incredibly difficult. I need to guide the LLM towards more targeted solutions, not blanket coverage. How should I phrase my feedback to get a better response?'
Liam correctly identifies a common issue with AI-generated code suggestions: they often lack nuance and can introduce unnecessary complexity. The key here isn't simply stating the suggestion is 'incorrect,' but explaining *why* it's problematic – in this case, the impact on debugging. Providing feedback that steers the LLM towards more targeted solutions is crucial for effective prompting; the goal is to guide, not just reject.
20 / 25
David: 'Okay, I've asked the LLM to generate a SQL query for finding all customers who haven't placed an order in the last six months. The response is incredibly verbose and includes joins to tables I don't need – it's returning 10 columns of data! I just want a simple `SELECT` statement with `customer_id` and `email`. How can I better instruct the LLM to focus on the specific information I require?'
This scenario highlights the importance of being precise and directive in your prompts when requesting structured data from an LLM. The original prompt likely allowed for a broad interpretation, leading to an overly complex query. Explicitly stating what columns are needed (in this case `customer_id` and `email`) will constrain the LLM's response and improve its focus on generating the desired output – demonstrating that clear instructions are key to getting relevant results.
21 / 25
During a Slack discussion about a newly generated API response from an AI, Sarah comments: 'The documentation is incredibly dense and includes fields we're not using. It's making it hard to quickly understand the data structure.' Which of the following best describes what Sarah is suggesting?
(A) The API response should always return a 200 OK status code.
(B) The AI prompt needs more explicit instructions regarding the desired output format and field selection.
(C) All API calls should be logged for auditing purposes.
(D) The AI tool is fundamentally flawed and should be discarded.
Sarah's comment highlights a problem with the *detail* of the AI-generated response. She's indicating that the prompt needs to be refined to reduce unnecessary complexity – focusing on what information is actually required, not just generating everything possible. Options A and C are irrelevant to the core issue; option D is an overly harsh judgment.
22 / 25
Liam writes in a PR description: 'The LLM generated this code snippet. It's great for quickly prototyping, but I'm concerned about maintainability – it doesn't include any comments or error handling.' What is Liam primarily criticizing about the AI-generated code?
(A) The code violates coding standards.
(B) The code lacks documentation and robustness, making it difficult to understand and debug.
(C) The code uses an outdated version of the programming language.
D) The code is too short to be useful.
Liam's feedback centers on the *quality* of the AI-generated code. While code standards are important, the core issue here is the absence of documentation and error handling – crucial for long-term maintainability and preventing future problems. The other options represent tangential concerns.
23 / 25
During a code review, David notices the LLM generated a SQL query that includes joins to several tables he doesn't need for this specific report. He comments: 'This query is overly complex and inefficient – it's pulling in data we don't actually use.' What does David mean by 'overly complex and inefficient'?
(A) The query uses an unsupported SQL dialect.
(B) The query joins tables that do not logically relate to each other, increasing processing time and potential errors.
(C) The query is too short to be effective.
D) The query returns incorrect results.
David's comment refers to the *performance* and *design* of the SQL query. Joining unrelated tables increases complexity and can significantly slow down execution. The goal is to create queries that are both efficient and focused on retrieving only necessary data – a core principle of good database design.
24 / 25
John is using an AI prompt to generate Python code for validating email addresses. After testing, he finds that the generated function fails when handling emails with special characters like '@#$%^&*()_+-={}'. What's the most likely reason for this failure?
(A) The AI tool is not trained on valid email address formats.
(B) The prompt didn't include sufficient detail about how to handle special characters in email addresses.
(C) The Python interpreter itself has limitations regarding character encoding.
D) The generated code is simply incorrect and needs to be rewritten.
The problem arises because the initial *prompt* likely lacked specific instructions on handling special characters. Email address validation requires robust parsing of these characters – a detail that wasn't explicitly communicated to the AI, leading to an incomplete solution. Simply rewriting the code won't fix this underlying issue.
25 / 25
Mark asks an LLM to generate a unit test for a function that calculates the factorial of a number. The initial output is just 'assert True'. He then adds more context about the function's purpose and input validation. What's Mark primarily trying to do?
(A) Ensure the LLM always generates correct code.
(B) Provide the AI with enough information to understand the *intent* and constraints of the testing scenario, leading to more relevant test cases.
(C) Force the LLM to use a specific testing framework.
D) Simplify the function's logic to make it easier for the AI to generate tests.
Mark's action demonstrates the importance of *context* in prompting an AI. The initial generic 'assert True' indicates a lack of understanding of what constitutes a valid test case. By providing more details—the function's purpose and input validation—he's guiding the AI to generate tests that actually verify the desired behavior.
What will I practice in "Writing Clear Prompts — AI Prompting English Exercise"?
This is an AI Prompting exercise set. It walks through 25 scenario-based multiple-choice questions built around real usage of AI Prompting terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 25 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the AI Prompting vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more AI Prompting exercises?
See the AI Prompting exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — AI Prompting vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.