Intermediate
Debugging Language
#bug-reports
#communication
Describing the Problem
6 exercises — write specific, actionable bug descriptions using Expected vs. Actual, numbered steps to reproduce, impact statements, and environment details.
0 / 37 completed
1 / 37
A developer writes this bug report:
"The login is broken."
What is missing from a useful bug description?
Expected / Actual / Steps to Reproduce / Environment — the four components of a useful bug report.
A complete bug description:
Why each section matters:
• Expected: establishes the correct behavior; without this, it's unclear if the reporter understands the feature
• Actual: the specific symptoms, exact error message, observable behavior
• Steps to reproduce: enables the next developer to reproduce the bug on their machine
• Environment: narrows down whether it's a browser/OS issue, or environment-specific (staging vs. prod)
One-sentence bug reports (like "login is broken") force the investigating developer to ask follow-up questions, doubling the time to resolution.
A complete bug description:
**Expected:** Clicking "Log in" with valid credentials navigates to the dashboard. **Actual:** The button shows a spinner for 5 seconds, then displays: "TypeError: Cannot read properties of undefined (reading 'token')" **Steps to reproduce:** 1. Go to https://app.example.com/login 2. Enter user: test@example.com, password: Test1234! 3. Click "Log in" **Environment:** Chrome 122, macOS 14.3, staging environment (not prod)
Why each section matters:
• Expected: establishes the correct behavior; without this, it's unclear if the reporter understands the feature
• Actual: the specific symptoms, exact error message, observable behavior
• Steps to reproduce: enables the next developer to reproduce the bug on their machine
• Environment: narrows down whether it's a browser/OS issue, or environment-specific (staging vs. prod)
One-sentence bug reports (like "login is broken") force the investigating developer to ask follow-up questions, doubling the time to resolution.
2 / 37
Which problem description is clearest and most actionable?
Option C — a specific, measurable, actionable problem statement.
What makes it good:
1. Specific endpoint: GET /api/search (not just "the API")
2. Quantified actual: 2.3s average (not "slow" or "sometimes slow")
3. Measurement method: "over 100 requests" — statistically meaningful
4. Specific expected: <500ms per SLA — references the service level agreement
5. Full environment: OS, Node version, infrastructure, database — all reproduction-critical
How to improve vague bug reports:
• "slow" → "X ms average, Y ms at P99 (99th percentile)"
• "sometimes" → "reproducible when [condition]" or "occurs ~30% of requests in load test"
• "the API" → "GET /api/endpoint?param=value"
• "doesn't work" → specific error message or behavior
• "in production" → specific production configuration, region, or affected users
Rule: if you cannot state the Expected and Actual in concrete, measurable terms, you do not yet have enough information to file an actionable bug report.
What makes it good:
1. Specific endpoint: GET /api/search (not just "the API")
2. Quantified actual: 2.3s average (not "slow" or "sometimes slow")
3. Measurement method: "over 100 requests" — statistically meaningful
4. Specific expected: <500ms per SLA — references the service level agreement
5. Full environment: OS, Node version, infrastructure, database — all reproduction-critical
How to improve vague bug reports:
• "slow" → "X ms average, Y ms at P99 (99th percentile)"
• "sometimes" → "reproducible when [condition]" or "occurs ~30% of requests in load test"
• "the API" → "GET /api/endpoint?param=value"
• "doesn't work" → specific error message or behavior
• "in production" → specific production configuration, region, or affected users
Rule: if you cannot state the Expected and Actual in concrete, measurable terms, you do not yet have enough information to file an actionable bug report.
3 / 37
You are writing a bug report and want to include the steps to reproduce. Which is correct?
Option B — complete, numbered steps to reproduce with a clear expected/actual pair at the end.
Steps to Reproduce (STR) format:
1. Numbered list — one discrete action per step
2. Specific: use exact values ("50 characters", not "a long string")
3. Start from a known state (navigate to /settings/profile, not "go to the settings")
4. Include the expected result after the final step
5. Include the actual result (what actually happened)
Good STR principles:
• Reproducible on a fresh browser session (no assumed state from previous steps)
• Another developer can follow them without asking for clarification
• Include any required setup: "Requires an account with the 'admin' role" or "Reproduce only in Firefox"
• If intermittent: "Reproducible ~70% of the time; refresh and retry if it works first time"
The goal is: the developer receiving the bug report should be able to reproduce the issue in under 5 minutes following only the STR.
Steps to Reproduce (STR) format:
1. Numbered list — one discrete action per step
2. Specific: use exact values ("50 characters", not "a long string")
3. Start from a known state (navigate to /settings/profile, not "go to the settings")
4. Include the expected result after the final step
5. Include the actual result (what actually happened)
Good STR principles:
• Reproducible on a fresh browser session (no assumed state from previous steps)
• Another developer can follow them without asking for clarification
• Include any required setup: "Requires an account with the 'admin' role" or "Reproduce only in Firefox"
• If intermittent: "Reproducible ~70% of the time; refresh and retry if it works first time"
The goal is: the developer receiving the bug report should be able to reproduce the issue in under 5 minutes following only the STR.
4 / 37
What does the phrase "intermittent bug" mean, and how should you describe one?
Intermittent bug — a bug that does not consistently reproduce. It requires different documentation than a deterministic bug.
How to describe intermittent bugs:
Key phrases for intermittent bugs:
• "Reproduces approximately X% of the time"
• "Observed when [condition] — not observed without it"
• "We believe it is timing-related / load-related / environment-specific"
• "We have a screen recording of one occurrence"
• "Logs captured from the occurrence at [timestamp]"
An intermittent bug without logs or a reproduction rate is the hardest type to investigate. If you cannot reproduce it, capturing logs and metrics when it does occur is the most valuable contribution you can make.
How to describe intermittent bugs:
**Frequency:** ~1 in 10 attempts **Pattern observed:** More likely under load (>5 concurrent users in staging); not observed with single user **When it occurred:** Steps 1–4 above; sometimes step 3 completes but step 4 fails **Logs available:** Yes — see attached log snippet, timestamp 14:32:08 UTC **Screen recording:** [link] Note: if unable to reproduce immediately, reload the page and retry.
Key phrases for intermittent bugs:
• "Reproduces approximately X% of the time"
• "Observed when [condition] — not observed without it"
• "We believe it is timing-related / load-related / environment-specific"
• "We have a screen recording of one occurrence"
• "Logs captured from the occurrence at [timestamp]"
An intermittent bug without logs or a reproduction rate is the hardest type to investigate. If you cannot reproduce it, capturing logs and metrics when it does occur is the most valuable contribution you can make.
5 / 37
You need to describe where a bug was isolated. Which phrase is most precise?
Option C — isolated to a specific function and the specific edge case that triggers it.
Phrases for isolating a bug's location:
• "isolated to" — narrowed down to a specific component/function/line
• "reproduces only when" — the specific triggering condition
• "I ruled out X and Y — the issue is in Z" — shows reasoning
• "occurs at line 87 in src/billing/tax.js" — exact file + line reference
• "the edge case where" — describes the boundary condition
• "limited to" — affects only a subset of cases
Describing scope of impact:
• "Affects all users with discount codes > 50%"
• "Affects only the checkout flow, not the cart preview"
• "Observed in Chrome 122 only — not Safari or Firefox"
• "Occurs only with items in the 'clearance' category"
Precise isolation language saves an investigating developer from re-doing work you already did and enables them to jump directly to the relevant code.
Phrases for isolating a bug's location:
• "isolated to" — narrowed down to a specific component/function/line
• "reproduces only when" — the specific triggering condition
• "I ruled out X and Y — the issue is in Z" — shows reasoning
• "occurs at line 87 in src/billing/tax.js" — exact file + line reference
• "the edge case where" — describes the boundary condition
• "limited to" — affects only a subset of cases
Describing scope of impact:
• "Affects all users with discount codes > 50%"
• "Affects only the checkout flow, not the cart preview"
• "Observed in Chrome 122 only — not Safari or Firefox"
• "Occurs only with items in the 'clearance' category"
Precise isolation language saves an investigating developer from re-doing work you already did and enables them to jump directly to the relevant code.
6 / 37
A colleague asks "what's the impact?" about a bug. Which response is most useful?
Option C — a specific impact statement with affected users, timeline, quantified business impact, and data safety confirmation.
Impact statement template:
• WHO: "all EU users" / "users with role 'admin'" / "users who signed up before 2024"
• WHAT: "attempting checkout" / "viewing the dashboard" / "exporting reports"
• SINCE WHEN: specific timestamp — "since 09:15 UTC" — enables root cause timeline analysis
• SCALE: "~340 failed transactions" — quantified, even if approximate
• BUSINESS IMPACT: "~£4,200" — translates technical failure into business terms
• DATA SAFETY: "No data loss" / "Orders may have duplicate charge" — critical for severity triage
Why "it's pretty bad" is insufficient:
• Stakeholders cannot make prioritisation decisions without numbers
• Engineers cannot scope the fix without knowing impact boundaries
• "Bad" is subjective — one engineer's "bad" is another's "critical P0"
Quantifying impact is a key professional skill that distinguishes senior from junior communication in incidents and bug reports.
Impact statement template:
• WHO: "all EU users" / "users with role 'admin'" / "users who signed up before 2024"
• WHAT: "attempting checkout" / "viewing the dashboard" / "exporting reports"
• SINCE WHEN: specific timestamp — "since 09:15 UTC" — enables root cause timeline analysis
• SCALE: "~340 failed transactions" — quantified, even if approximate
• BUSINESS IMPACT: "~£4,200" — translates technical failure into business terms
• DATA SAFETY: "No data loss" / "Orders may have duplicate charge" — critical for severity triage
Why "it's pretty bad" is insufficient:
• Stakeholders cannot make prioritisation decisions without numbers
• Engineers cannot scope the fix without knowing impact boundaries
• "Bad" is subjective — one engineer's "bad" is another's "critical P0"
Quantifying impact is a key professional skill that distinguishes senior from junior communication in incidents and bug reports.
7 / 37
Sarah writes this comment on a pull request:
"The API call to /users/{userId} is returning a 500 error. I've tried restarting the server and it still happens."
Which of these responses would be most helpful for David, the senior developer, to understand the problem and guide the debugging process?
This response is too vague because it lacks crucial information needed for effective debugging.
Sarah's comment doesn't mention what data she's sending to the /users/{userId} endpoint (the request payload), nor does it include the full error message from the API, which would provide valuable context. A more descriptive response would allow David to quickly investigate potential issues with the request format or server-side logic. Simply restarting the server is a common first step, but without knowing *what* caused the initial failure, it's unlikely to resolve the problem.8 / 37
David: "Hey Maria, this new feature is failing. Can you take a look?"
Maria responds with:
A: "Okay, I'll check it out." B: "I'm seeing a 500 error in the logs when accessing the new endpoint. The user is experiencing a blank page after submitting the form. I've checked the database connection and it seems to be stable."
C: "It looks like there's an issue with the frontend." D: "I'll add a ticket for this."
The correct response, B, provides specific details about the problem – a 500 error, a blank page, and the affected endpoint. This immediately gives David valuable information to start troubleshooting. Options A and D are too vague; they don't describe the issue itself. Option C is incorrect because the problem originates from the backend API call.
9 / 37
David asks Maria to investigate a failing new feature. Maria responds with one of the following options. Which response is MOST helpful for David to understand the problem and guide debugging?
David: "Hey Maria, this new feature is failing. Can you take a look?"
Option B provides the most valuable information. It specifically identifies the error code (500), describes the user-facing symptom (blank page), and details Maria's initial investigation into the database connection. This allows David to immediately focus on server-side issues related to the API endpoint. Options A, C, and D are too vague and don't offer actionable steps for debugging.
10 / 37
Sarah writes this comment on a pull request:
"The API call to /users/{userId} is returning a 500 error. I've tried restarting the server and it still happens."
Which of these responses would be most helpful for David, the senior developer, to understand the problem and guide the debugging process?
This response is too vague because it lacks crucial information needed for effective debugging.
Sarah's comment doesn't mention what data she's sending to the /users/{userId} endpoint (the request payload), nor does it include the full error message from the API, which would provide valuable context. A more descriptive response would allow David to quickly investigate potential issues with the request format or server-side logic. Simply restarting the server is a common first step, but without knowing *what* caused the initial failure, it's unlikely to resolve the problem.11 / 37
David: "Hey Maria, this new feature is failing. Can you take a look?"
Maria responds with:
A: "Okay, I'll check it out." B: "I'm seeing a 500 error in the logs when accessing the new endpoint. The user is experiencing a blank page after submitting the form. I've checked the database connection and it seems to be stable."
C: "It looks like there's an issue with the frontend." D: "I'll add a ticket for this."
The correct response, B, provides specific details about the problem – a 500 error, a blank page, and the affected endpoint. This immediately gives David valuable information to start troubleshooting. Options A and D are too vague; they don't describe the issue itself. Option C is incorrect because the problem originates from the backend API call.
12 / 37
David asks Maria to investigate a failing new feature. Maria responds with one of the following options. Which response is MOST helpful for David to understand the problem and guide debugging?
David: "Hey Maria, this new feature is failing. Can you take a look?"
Option B provides the most valuable information. It specifically identifies the error code (500), describes the user-facing symptom (blank page), and details Maria's initial investigation into the database connection. This allows David to immediately focus on server-side issues related to the API endpoint. Options A, C, and D are too vague and don't offer actionable steps for debugging.
13 / 37
Sarah writes this comment on a pull request:
"The API call to /users/{userId} is returning a 500 error. I've tried restarting the server and it still happens."
Which of these responses would be most helpful for David, the senior developer, to understand the problem and guide the debugging process?
This response is too vague because it lacks crucial information needed for effective debugging.
Sarah's comment doesn't mention what data she's sending to the /users/{userId} endpoint (the request payload), nor does it include the full error message from the API, which would provide valuable context. A more descriptive response would allow David to quickly investigate potential issues with the request format or server-side logic. Simply restarting the server is a common first step, but without knowing *what* caused the initial failure, it's unlikely to resolve the problem.14 / 37
David: "Hey Maria, this new feature is failing. Can you take a look?"
Maria responds with:
A: "Okay, I'll check it out." B: "I'm seeing a 500 error in the logs when accessing the new endpoint. The user is experiencing a blank page after submitting the form. I've checked the database connection and it seems to be stable."
C: "It looks like there's an issue with the frontend." D: "I'll add a ticket for this."
The correct response, B, provides specific details about the problem – a 500 error, a blank page, and the affected endpoint. This immediately gives David valuable information to start troubleshooting. Options A and D are too vague; they don't describe the issue itself. Option C is incorrect because the problem originates from the backend API call.
15 / 37
David asks Maria to investigate a failing new feature. Maria responds with one of the following options. Which response is MOST helpful for David to understand the problem and guide debugging?
David: "Hey Maria, this new feature is failing. Can you take a look?"
Option B provides the most valuable information. It specifically identifies the error code (500), describes the user-facing symptom (blank page), and details Maria's initial investigation into the database connection. This allows David to immediately focus on server-side issues related to the API endpoint. Options A, C, and D are too vague and don't offer actionable steps for debugging.
16 / 37
Sarah writes this comment on a pull request:
"The API call to /users/{userId} is returning a 500 error. I've tried restarting the server and it still happens."
Which of these responses would be most helpful for David, the senior developer, to understand the problem and guide the debugging process?
This response is too vague because it lacks crucial information needed for effective debugging.
Sarah's comment doesn't mention what data she's sending to the /users/{userId} endpoint (the request payload), nor does it include the full error message from the API, which would provide valuable context. A more descriptive response would allow David to quickly investigate potential issues with the request format or server-side logic. Simply restarting the server is a common first step, but without knowing *what* caused the initial failure, it's unlikely to resolve the problem.17 / 37
David: "Hey Maria, this new feature is failing. Can you take a look?"
Maria responds with:
A: "Okay, I'll check it out." B: "I'm seeing a 500 error in the logs when accessing the new endpoint. The user is experiencing a blank page after submitting the form. I've checked the database connection and it seems to be stable."
C: "It looks like there's an issue with the frontend." D: "I'll add a ticket for this."
The correct response, B, provides specific details about the problem – a 500 error, a blank page, and the affected endpoint. This immediately gives David valuable information to start troubleshooting. Options A and D are too vague; they don't describe the issue itself. Option C is incorrect because the problem originates from the backend API call.
18 / 37
David asks Maria to investigate a failing new feature. Maria responds with one of the following options. Which response is MOST helpful for David to understand the problem and guide debugging?
David: "Hey Maria, this new feature is failing. Can you take a look?"
Option B provides the most valuable information. It specifically identifies the error code (500), describes the user-facing symptom (blank page), and details Maria's initial investigation into the database connection. This allows David to immediately focus on server-side issues related to the API endpoint. Options A, C, and D are too vague and don't offer actionable steps for debugging.
19 / 37
You're reviewing a pull request for a new user authentication service. Alex comments: "The API endpoint
/users/{userId} is returning a 404 error when attempting to retrieve users with an ID of 123. I've checked the database and the record exists." Which phrase best describes the *root cause* suggested by this comment?This comment indicates a potential routing issue. Alex states the record exists in the database but the API isn't returning it. This suggests that the API code isn't correctly directing the request to the correct resource – a common cause of 404 errors. The other options represent alternative explanations, such as data format issues or server overload, which are less directly supported by the comment.
20 / 37
Maria sends this Slack message: "I'm seeing a lot of 'TimeoutException' errors in the application logs when processing large batch jobs. The jobs complete successfully, but the logs show the timeouts." Which action should you *immediately* suggest to Maria based on this information?
The Slack message clearly points to a timing issue – timeouts. Network connectivity problems are frequently the root cause of timeout errors when transferring data between services. While other options are relevant for longer-term investigation, addressing potential network issues is the most immediate and likely solution given the described symptoms. Increasing the timeout might mask the underlying problem.
21 / 37
You're writing a PR description for a bug fix: "Fixed a race condition in the order processing service that caused intermittent failures when multiple users attempted to place orders simultaneously. The fix ensures exclusive access to shared resources." Which phrase best summarizes the *technical* nature of the change?
The description explicitly states that the bug was a 'race condition.' A race condition occurs when multiple processes access and modify shared resources concurrently, leading to unpredictable results. Therefore, 'Resolved a data integrity issue' accurately reflects the core problem addressed by the fix – ensuring consistency in concurrent operations. The other options represent different types of optimization or improvements.
22 / 37
David reports: "The new payment processing module is failing with a 'PaymentGatewayException' when attempting to process transactions. The error message indicates 'Invalid API Key'." What's the *most important* first step you should advise David to take?
The error message explicitly states 'Invalid API Key'. This strongly suggests a problem with the configuration. Verifying the API key is the quickest and most direct way to confirm or correct this specific issue. While other steps are important for debugging, confirming the key is accurate is the highest priority based on the provided information.
23 / 37
David says to Maria: "The user registration service is failing. We're getting a 'DuplicateKeyException' when trying to create new accounts with the same email address." Maria responds with:
A: "Okay, I'll check the database schema."
B: "I'm investigating – the logs show the exception occurring consistently when attempting registration for
john.doe@example.com."
C: "Let me run a full system reboot to see if that resolves it."
D: "I've added logging around the account creation code, but haven't seen anything yet." Option B is the most helpful because it identifies a specific user (
john.doe@example.com) triggering the error. This immediately focuses the investigation on potential duplicate email addresses and provides a starting point for further analysis. Options A, C, and D are less useful as they don't pinpoint the source of the problem.24 / 37
Sarah sends this Slack message to her team:
"Just noticed a weird spike in latency for API calls to our product catalog service. It's consistently around 500ms, which is significantly higher than the usual 100ms. The system metrics show no obvious overload."
Which of these responses would be MOST effective for Liam (a fellow developer) to understand and begin troubleshooting?
A: "Sounds like a network issue; try pinging the service."
B: "Let's check the application logs around the time of the latency spikes – we might see some slow database queries."
C: "Did you try restarting the service? Sometimes that fixes temporary glitches."
D: "It's probably just a normal fluctuation in traffic; don't worry about it."
Sarah's message includes key details: latency measurement (500ms), comparison to normal performance (100ms), and lack of obvious overload. Option B is best as it suggests examining application logs for slow queries—a common cause of high latency in services. The other options are less targeted or dismissive.
25 / 37
During a standup meeting, Ben reports: "The reporting dashboard is intermittently failing to load data for the last month. Users report seeing blank tables and occasional '500 Internal Server Error' messages." He adds, 'I've checked the server logs briefly, but haven't found anything obvious.'
Which of the following requests from team lead, Alice, would be MOST appropriate to follow up on?
A: "Can you send me a screenshot of the error message?"
B: "Let's focus on the recent code changes related to data aggregation – perhaps there's an issue with the SQL queries."
C: "Just try refreshing the page again; it might be a temporary glitch."
D: "I'll investigate the server logs more thoroughly; you should just wait for it to resolve itself."
Alice's question focuses on recent code changes—Ben's own admission indicates a potential source. This is a standard debugging approach: start with what's been changed recently. Options A and C are less helpful as they don't address the root cause; Option D avoids taking action.
26 / 37
You're reviewing a PR description:
"Fixed a null pointer exception in the payment processing service that occurred when handling refunds. The fix involved adding null checks before accessing the refund object." Mark comments: "Can you elaborate on why this was happening?"
What is the MOST appropriate response to Mark?
A: "I added the null checks as part of the bug fix – it's a standard defensive programming practice."
B: "The original code didn't handle cases where the refund object could be null, leading to the exception. The null checks prevent this."
C: "I just fixed it; don't ask any more questions!"
D: "It was a simple fix, no need for further explanation."
Mark is asking for *why* the null check was added. Option B explains that the original code didn't handle null values, which caused the exception. This provides valuable context and demonstrates understanding of the problem and solution.
27 / 37
David says to Maria: "The new API endpoint for fetching customer profiles is returning a '403 Forbidden' error. Users with valid authentication tokens are still receiving this error." What's the FIRST thing you should investigate?
A: The user's browser's Javascript console, looking for errors.
B: The API key in the user's request headers.
C: Whether the endpoint is rate-limited.
D: The server logs to see if there are any error messages or unusual activity related to that endpoint."
A '403 Forbidden' error almost always points to an authorization problem. Checking the API key and server logs are the most direct ways to determine if access has been denied due to incorrect credentials, permissions, or rate limiting.
28 / 37
David says to Maria: "The user registration service is failing. We're getting a 'DuplicateKeyException' when trying to create new accounts with the same email address." Maria responds with:
A: "Okay, I'll check the database schema."
B: "I'm investigating – the logs show the exception occurring consistently when attempting registration for
john.doe@example.com."
C: "Let me run a full system reboot to see if that resolves it."
D: "I've added logging around the account creation code, but haven't seen anything yet." Option B is the most helpful because it identifies a specific user (
john.doe@example.com) triggering the error. This immediately focuses the investigation on potential duplicate email addresses and provides a starting point for further analysis. Options A, C, and D are less useful as they don't pinpoint the source of the problem.29 / 37
Sarah sends this Slack message to her team:
"Just noticed a weird spike in latency for API calls to our product catalog service. It's consistently around 500ms, which is significantly higher than the usual 100ms. The system metrics show no obvious overload."
Which of these responses would be MOST effective for Liam (a fellow developer) to understand and begin troubleshooting?
A: "Sounds like a network issue; try pinging the service."
B: "Let's check the application logs around the time of the latency spikes – we might see some slow database queries."
C: "Did you try restarting the service? Sometimes that fixes temporary glitches."
D: "It's probably just a normal fluctuation in traffic; don't worry about it."
Sarah's message includes key details: latency measurement (500ms), comparison to normal performance (100ms), and lack of obvious overload. Option B is best as it suggests examining application logs for slow queries—a common cause of high latency in services. The other options are less targeted or dismissive.
30 / 37
During a standup meeting, Ben reports: "The reporting dashboard is intermittently failing to load data for the last month. Users report seeing blank tables and occasional '500 Internal Server Error' messages." He adds, 'I've checked the server logs briefly, but haven't found anything obvious.'
Which of the following requests from team lead, Alice, would be MOST appropriate to follow up on?
A: "Can you send me a screenshot of the error message?"
B: "Let's focus on the recent code changes related to data aggregation – perhaps there's an issue with the SQL queries."
C: "Just try refreshing the page again; it might be a temporary glitch."
D: "I'll investigate the server logs more thoroughly; you should just wait for it to resolve itself."
Alice's question focuses on recent code changes—Ben's own admission indicates a potential source. This is a standard debugging approach: start with what's been changed recently. Options A and C are less helpful as they don't address the root cause; Option D avoids taking action.
31 / 37
You're reviewing a PR description:
"Fixed a null pointer exception in the payment processing service that occurred when handling refunds. The fix involved adding null checks before accessing the refund object." Mark comments: "Can you elaborate on why this was happening?"
What is the MOST appropriate response to Mark?
A: "I added the null checks as part of the bug fix – it's a standard defensive programming practice."
B: "The original code didn't handle cases where the refund object could be null, leading to the exception. The null checks prevent this."
C: "I just fixed it; don't ask any more questions!"
D: "It was a simple fix, no need for further explanation."
Mark is asking for *why* the null check was added. Option B explains that the original code didn't handle null values, which caused the exception. This provides valuable context and demonstrates understanding of the problem and solution.
32 / 37
David says to Maria: "The new API endpoint for fetching customer profiles is returning a '403 Forbidden' error. Users with valid authentication tokens are still receiving this error." What's the FIRST thing you should investigate?
A: The user's browser's Javascript console, looking for errors.
B: The API key in the user's request headers.
C: Whether the endpoint is rate-limited.
D: The server logs to see if there are any error messages or unusual activity related to that endpoint."
A '403 Forbidden' error almost always points to an authorization problem. Checking the API key and server logs are the most direct ways to determine if access has been denied due to incorrect credentials, permissions, or rate limiting.
33 / 37
David says to Maria: "The user registration service is failing. We're getting a 'DuplicateKeyException' when trying to create new accounts with the same email address." Maria responds with:
A: "Okay, I'll check the database schema."
B: "I'm investigating – the logs show the exception occurring consistently when attempting registration for
john.doe@example.com."
C: "Let me run a full system reboot to see if that resolves it."
D: "I've added logging around the account creation code, but haven't seen anything yet." Option B is the most helpful because it identifies a specific user (
john.doe@example.com) triggering the error. This immediately focuses the investigation on potential duplicate email addresses and provides a starting point for further analysis. Options A, C, and D are less useful as they don't pinpoint the source of the problem.34 / 37
Sarah sends this Slack message to her team:
"Just noticed a weird spike in latency for API calls to our product catalog service. It's consistently around 500ms, which is significantly higher than the usual 100ms. The system metrics show no obvious overload."
Which of these responses would be MOST effective for Liam (a fellow developer) to understand and begin troubleshooting?
A: "Sounds like a network issue; try pinging the service."
B: "Let's check the application logs around the time of the latency spikes – we might see some slow database queries."
C: "Did you try restarting the service? Sometimes that fixes temporary glitches."
D: "It's probably just a normal fluctuation in traffic; don't worry about it."
Sarah's message includes key details: latency measurement (500ms), comparison to normal performance (100ms), and lack of obvious overload. Option B is best as it suggests examining application logs for slow queries—a common cause of high latency in services. The other options are less targeted or dismissive.
35 / 37
During a standup meeting, Ben reports: "The reporting dashboard is intermittently failing to load data for the last month. Users report seeing blank tables and occasional '500 Internal Server Error' messages." He adds, 'I've checked the server logs briefly, but haven't found anything obvious.'
Which of the following requests from team lead, Alice, would be MOST appropriate to follow up on?
A: "Can you send me a screenshot of the error message?"
B: "Let's focus on the recent code changes related to data aggregation – perhaps there's an issue with the SQL queries."
C: "Just try refreshing the page again; it might be a temporary glitch."
D: "I'll investigate the server logs more thoroughly; you should just wait for it to resolve itself."
Alice's question focuses on recent code changes—Ben's own admission indicates a potential source. This is a standard debugging approach: start with what's been changed recently. Options A and C are less helpful as they don't address the root cause; Option D avoids taking action.
36 / 37
You're reviewing a PR description:
"Fixed a null pointer exception in the payment processing service that occurred when handling refunds. The fix involved adding null checks before accessing the refund object." Mark comments: "Can you elaborate on why this was happening?"
What is the MOST appropriate response to Mark?
A: "I added the null checks as part of the bug fix – it's a standard defensive programming practice."
B: "The original code didn't handle cases where the refund object could be null, leading to the exception. The null checks prevent this."
C: "I just fixed it; don't ask any more questions!"
D: "It was a simple fix, no need for further explanation."
Mark is asking for *why* the null check was added. Option B explains that the original code didn't handle null values, which caused the exception. This provides valuable context and demonstrates understanding of the problem and solution.
37 / 37
David says to Maria: "The new API endpoint for fetching customer profiles is returning a '403 Forbidden' error. Users with valid authentication tokens are still receiving this error." What's the FIRST thing you should investigate?
A: The user's browser's Javascript console, looking for errors.
B: The API key in the user's request headers.
C: Whether the endpoint is rate-limited.
D: The server logs to see if there are any error messages or unusual activity related to that endpoint."
A '403 Forbidden' error almost always points to an authorization problem. Checking the API key and server logs are the most direct ways to determine if access has been denied due to incorrect credentials, permissions, or rate limiting.
Frequently Asked Questions
What does the "Describing the Problem" exercise practise?
Write specific bug reports using Expected vs. Actual, steps to reproduce, impact statements, and environment details. Intermediate exercises.
How many questions are in this exercise?
This exercise has 37 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Debugging Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Describing the Problem" part of a larger series?
Yes — it's one exercise in the Debugging Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Debugging Language category page for related exercises, or browse the main Exercises hub for other IT English topics.