📣 Developer Advocate Vocabulary
0 / 22 completed
1 / 22
"The company is hiring a Developer Advocate" — what is the primary purpose of this role?
Option A is correct. Developer Advocates sit at the intersection of community and product.
DevRel role comparison:
Key vocabulary: developer advocate, internal feedback loop, developer experience (DX), DevRel
DevRel role comparison:
| Role | Primary focus |
|---|---|
| Developer Advocate | Community trust, honest feedback loops, external developer success |
| DX Engineer | Tooling, SDKs, docs, onboarding flow improvements |
| Technical Evangelist | Outward marketing, brand positioning via technical content |
Key vocabulary: developer advocate, internal feedback loop, developer experience (DX), DevRel
2 / 22
"The DevRel team is measuring developer experience (DX)" — what does DX measure?
Option D is correct. DX measures the entire developer journey, not just usage volume.
DX metrics:
Key vocabulary: developer experience, time-to-first-value, pit of success, SDK ergonomics
DX metrics:
| Metric | What it measures |
|---|---|
| Time-to-first-value (TTFV) | Minutes from signup to first successful API call |
| Pit of success | Does the easiest path lead to correct usage? |
| Support ticket volume | Proxy for friction — high volume = poor docs/DX |
| SDK ergonomics score | How natural is it to use the SDK correctly? |
Key vocabulary: developer experience, time-to-first-value, pit of success, SDK ergonomics
3 / 22
"The advocate must give honest feedback even when critical" — what does this tension reveal about the DevRel role?
Option B is correct. The DevRel trust triangle is the core tension of the role.
DevRel trust triangle:
Advocates who are purely promotional quickly lose community credibility — the core value of the role disappears.
Key vocabulary: authentic advocacy, community trust, internal product feedback
DevRel trust triangle:
| Relationship | Expectation | Risk if broken |
|---|---|---|
| Community trust | Honest content — acknowledges limitations | Seen as marketing, not advocacy |
| Company relationship | Represent the brand professionally | Role eliminated or scope reduced |
Advocates who are purely promotional quickly lose community credibility — the core value of the role disappears.
Key vocabulary: authentic advocacy, community trust, internal product feedback
4 / 22
"We're running a hackathon to build community around our API" — what makes it effective?
Option C is correct. Great hackathons are about low friction and creative problem-solving.
Hackathon design checklist:
Key vocabulary: hackathon design, low barrier to entry, problem statement quality, developer onboarding event
Hackathon design checklist:
| Element | Why it matters |
|---|---|
| Clear problem statement | Participants need focus — "build anything" leads to confusion |
| No-approval API access | Every sign-up step lost = fewer participants |
| Live support channels | Blocked developers quit; instant help = projects ship |
| Creative solution recognition | Recognition matters as much as prize money |
Key vocabulary: hackathon design, low barrier to entry, problem statement quality, developer onboarding event
5 / 22
"The DevRel strategy needs internal vs. external DevRel distinction" — what is the difference?
Option B is correct. Both require the same skills — the audience is different.
Internal vs. external DevRel:
Key vocabulary: internal DevRel, platform advocacy, developer productivity
Internal vs. external DevRel:
| Dimension | External DevRel | Internal DevRel |
|---|---|---|
| Audience | External developer community | Internal engineers / teams |
| Activities | Talks, blog posts, OSS, events, tutorials | Internal docs, platform advocacy, DX improvements |
| Goal | Community growth, product adoption | Developer productivity, platform usage |
Key vocabulary: internal DevRel, platform advocacy, developer productivity
6 / 22
PR Description
Subject: Refactor: Improved Error Handling in User Authentication Service
Body:
```
This PR addresses a critical issue identified during recent testing. The previous implementation lacked robust error handling, leading to intermittent failures and a poor developer experience. We've added comprehensive logging and implemented a standardized response format for all authentication errors.
The team lead, Sarah, comments: 'While the code is cleaner now, I'm still unclear on *why* this was happening in the first place – could you add more context to the PR description?'The correct answer emphasizes summarizing the problem's impact and the changes made. A developer advocate needs to clearly communicate complex technical details to various stakeholders – in this case, the team lead – without getting bogged down in overly-technical specifics. The goal is to provide enough information for understanding but not overwhelm the reader with unnecessary jargon or a deep dive into the original problem's root cause, which should be documented elsewhere. Option 1 is too technical; option 3 reflects effective communication; and options 1 & 4 are not needed here.
7 / 22
Sarah, the team lead, is asking for more context in the PR description. She specifically wants to understand *why* the previous error handling was inadequate. Which of the following options best reflects the information she's requesting and demonstrates a strong understanding of the developer advocate's role during code reviews?
Option A: 'We added logging.' Option B: 'The code was refactored to improve performance.' Option C: 'We implemented a standardized response format for all authentication errors, addressing a previously undocumented issue with intermittent failures.' Option D: 'This PR fixes bugs.'
The team lead is not simply looking for a description of the changes made; she's probing for the root cause. Option C correctly identifies that Sarah wants to know *why* the previous handling was insufficient—specifically referencing the 'intermittent failures' and 'undocumented issue.' Options A and B are too superficial, while option D is just stating the outcome of the PR, not addressing the underlying problem. Understanding the 'why' demonstrates a DevRel advocate's ability to translate technical changes into actionable insights for the development team.
8 / 22
The team lead, Sarah, comments: 'While the code is cleaner now, I'm still unclear on *why* this was happening in the first place – could you add more context to the PR description?' Which of the following options best reflects the information she's requesting and demonstrates a strong understanding of the developer advocate's role during code reviews?
Understanding the root cause of issues is crucial for effective remediation and preventing future problems.Sarah isn't just interested in the technical changes; she wants to understand *why* the initial problem occurred. Option C correctly identifies that the PR addresses an 'undocumented issue' and its root cause – intermittent failures. This demonstrates a DevRel understanding of not only fixing code but also uncovering and addressing underlying problems that impact developer experience, which is central to the role.
9 / 22
PR Description
Subject: Refactor: Improved Error Handling in User Authentication Service
Body:
```
This PR addresses a critical issue identified during recent testing. The previous implementation lacked robust error handling, leading to intermittent failures and a poor developer experience. We've added comprehensive logging and implemented a standardized response format for all authentication errors.
The team lead, Sarah, comments: 'While the code is cleaner now, I'm still unclear on *why* this was happening in the first place – could you add more context to the PR description?'The correct answer emphasizes summarizing the problem's impact and the changes made. A developer advocate needs to clearly communicate complex technical details to various stakeholders – in this case, the team lead – without getting bogged down in overly-technical specifics. The goal is to provide enough information for understanding but not overwhelm the reader with unnecessary jargon or a deep dive into the original problem's root cause, which should be documented elsewhere. Option 1 is too technical; option 3 reflects effective communication; and options 1 & 4 are not needed here.
10 / 22
Sarah, the team lead, is asking for more context in the PR description. She specifically wants to understand *why* the previous error handling was inadequate. Which of the following options best reflects the information she's requesting and demonstrates a strong understanding of the developer advocate's role during code reviews?
Option A: 'We added logging.' Option B: 'The code was refactored to improve performance.' Option C: 'We implemented a standardized response format for all authentication errors, addressing a previously undocumented issue with intermittent failures.' Option D: 'This PR fixes bugs.'
The team lead is not simply looking for a description of the changes made; she's probing for the root cause. Option C correctly identifies that Sarah wants to know *why* the previous handling was insufficient—specifically referencing the 'intermittent failures' and 'undocumented issue.' Options A and B are too superficial, while option D is just stating the outcome of the PR, not addressing the underlying problem. Understanding the 'why' demonstrates a DevRel advocate's ability to translate technical changes into actionable insights for the development team.
11 / 22
The team lead, Sarah, comments: 'While the code is cleaner now, I'm still unclear on *why* this was happening in the first place – could you add more context to the PR description?' Which of the following options best reflects the information she's requesting and demonstrates a strong understanding of the developer advocate's role during code reviews?
Understanding the root cause of issues is crucial for effective remediation and preventing future problems.Sarah isn't just interested in the technical changes; she wants to understand *why* the initial problem occurred. Option C correctly identifies that the PR addresses an 'undocumented issue' and its root cause – intermittent failures. This demonstrates a DevRel understanding of not only fixing code but also uncovering and addressing underlying problems that impact developer experience, which is central to the role.
12 / 22
PR Description
Subject: Refactor: Improved Error Handling in User Authentication Service
Body:
```
This PR addresses a critical issue identified during recent testing. The previous implementation lacked robust error handling, leading to intermittent failures and a poor developer experience. We've added comprehensive logging and implemented a standardized response format for all authentication errors.
The team lead, Sarah, comments: 'While the code is cleaner now, I'm still unclear on *why* this was happening in the first place – could you add more context to the PR description?'The correct answer emphasizes summarizing the problem's impact and the changes made. A developer advocate needs to clearly communicate complex technical details to various stakeholders – in this case, the team lead – without getting bogged down in overly-technical specifics. The goal is to provide enough information for understanding but not overwhelm the reader with unnecessary jargon or a deep dive into the original problem's root cause, which should be documented elsewhere. Option 1 is too technical; option 3 reflects effective communication; and options 1 & 4 are not needed here.
13 / 22
Sarah, the team lead, is asking for more context in the PR description. She specifically wants to understand *why* the previous error handling was inadequate. Which of the following options best reflects the information she's requesting and demonstrates a strong understanding of the developer advocate's role during code reviews?
Option A: 'We added logging.' Option B: 'The code was refactored to improve performance.' Option C: 'We implemented a standardized response format for all authentication errors, addressing a previously undocumented issue with intermittent failures.' Option D: 'This PR fixes bugs.'
The team lead is not simply looking for a description of the changes made; she's probing for the root cause. Option C correctly identifies that Sarah wants to know *why* the previous handling was insufficient—specifically referencing the 'intermittent failures' and 'undocumented issue.' Options A and B are too superficial, while option D is just stating the outcome of the PR, not addressing the underlying problem. Understanding the 'why' demonstrates a DevRel advocate's ability to translate technical changes into actionable insights for the development team.
14 / 22
The team lead, Sarah, comments: 'While the code is cleaner now, I'm still unclear on *why* this was happening in the first place – could you add more context to the PR description?' Which of the following options best reflects the information she's requesting and demonstrates a strong understanding of the developer advocate's role during code reviews?
Understanding the root cause of issues is crucial for effective remediation and preventing future problems.Sarah isn't just interested in the technical changes; she wants to understand *why* the initial problem occurred. Option C correctly identifies that the PR addresses an 'undocumented issue' and its root cause – intermittent failures. This demonstrates a DevRel understanding of not only fixing code but also uncovering and addressing underlying problems that impact developer experience, which is central to the role.
15 / 22
PR Description
Subject: Refactor: Improved Error Handling in User Authentication Service
Body:
```
This PR addresses a critical issue identified during recent testing. The previous implementation lacked robust error handling, leading to intermittent failures and a poor developer experience. We've added comprehensive logging and implemented a standardized response format for all authentication errors.
The team lead, Sarah, comments: 'While the code is cleaner now, I'm still unclear on *why* this was happening in the first place – could you add more context to the PR description?'The correct answer emphasizes summarizing the problem's impact and the changes made. A developer advocate needs to clearly communicate complex technical details to various stakeholders – in this case, the team lead – without getting bogged down in overly-technical specifics. The goal is to provide enough information for understanding but not overwhelm the reader with unnecessary jargon or a deep dive into the original problem's root cause, which should be documented elsewhere. Option 1 is too technical; option 3 reflects effective communication; and options 1 & 4 are not needed here.
16 / 22
Sarah, the team lead, is asking for more context in the PR description. She specifically wants to understand *why* the previous error handling was inadequate. Which of the following options best reflects the information she's requesting and demonstrates a strong understanding of the developer advocate's role during code reviews?
Option A: 'We added logging.' Option B: 'The code was refactored to improve performance.' Option C: 'We implemented a standardized response format for all authentication errors, addressing a previously undocumented issue with intermittent failures.' Option D: 'This PR fixes bugs.'
The team lead is not simply looking for a description of the changes made; she's probing for the root cause. Option C correctly identifies that Sarah wants to know *why* the previous handling was insufficient—specifically referencing the 'intermittent failures' and 'undocumented issue.' Options A and B are too superficial, while option D is just stating the outcome of the PR, not addressing the underlying problem. Understanding the 'why' demonstrates a DevRel advocate's ability to translate technical changes into actionable insights for the development team.
17 / 22
The team lead, Sarah, comments: 'While the code is cleaner now, I'm still unclear on *why* this was happening in the first place – could you add more context to the PR description?' Which of the following options best reflects the information she's requesting and demonstrates a strong understanding of the developer advocate's role during code reviews?
Understanding the root cause of issues is crucial for effective remediation and preventing future problems.Sarah isn't just interested in the technical changes; she wants to understand *why* the initial problem occurred. Option C correctly identifies that the PR addresses an 'undocumented issue' and its root cause – intermittent failures. This demonstrates a DevRel understanding of not only fixing code but also uncovering and addressing underlying problems that impact developer experience, which is central to the role.
18 / 22
A junior developer posts this to Slack: 'Just running `npm install` on the new frontend. Seems fine.' Which best describes the level of detail needed in a DevRel response?
The question tests understanding of DevRel's role in proactively communicating risk. 'Adequate' is correct because `npm install` is a standard process; however, it lacks crucial context about potential vulnerabilities and dependency management – key areas for a DevRel to address.
19 / 22
A developer submits this PR description: 'Fixed a bug.' What additional information would a DevRel *likely* request before approving?
The question tests understanding of a DevRel's role in gathering details. 'A detailed technical explanation...' is the most appropriate request – it's crucial for understanding the impact and preventing future issues. A good DevRel doesn't just accept 'fixed a bug'; they want to know *how*.
20 / 22
Sarah, a DevRel, is reviewing a pull request for a new API endpoint. The code includes extensive comments explaining the design decisions and potential limitations. Which of these best describes her primary goal in this scenario?
The question assesses understanding of a DevRel's role in aligning technical solutions with business goals. 'To verify that the API meets user needs and documentation requirements' is core to a DevRel – they bridge the gap between engineering and the end-user experience.
21 / 22
During a daily standup, a developer says: 'I'm working on implementing feature X.' What kind of follow-up question would a DevRel *most* likely ask?
The question tests understanding of a DevRel's focus on user context. 'Can you describe the user journey that feature X will impact?' is vital – it ensures the developer is considering the broader product strategy and user experience, which is a core DevRel responsibility.
22 / 22
A developer sends this API response to the DevRel: `HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "success",
"data": [ ... ]
}`. What is the *primary* reason the DevRel would want to investigate this response further?
The question tests understanding of DevRel's monitoring role. While format and security are important, 'To verify that the API is performing optimally under load.' is most relevant – it directly relates to performance and stability, crucial areas for a DevRel to monitor and address.
Frequently Asked Questions
What does the "Developer Advocate Vocabulary" exercise practise?
Practice DevRel vocabulary: DX, evangelism vs. advocacy, feedback loop, internal vs. external DevRel.
How many questions are in this exercise?
This exercise has 22 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 Conference & Community 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 "Developer Advocate Vocabulary" part of a larger series?
Yes — it's one exercise in the Conference & Community 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 Conference & Community category page for related exercises, or browse the main Exercises hub for other IT English topics.