4 exercises — presenting diagrams to mixed audiences, justifying technical decisions, presenting trade-offs honestly, and using connector signposts between architecture layers.
0 / 9 completed
1 / 9
You're presenting an architecture diagram to a mixed audience: 3 engineers, 2 PMs, and 1 VP of Engineering. Which introduction works for all three groups?
Option B uses the user-first, then technical layering technique for mixed audiences:
Starts from the user's perspective: "A browser request hits our API gateway" — everyone understands "a user makes a request" Uses plain language first: "one responsibility", "message bus" — functional, not technical Promises depth for engineers: "for the engineers in the room I'll add the technical details" — acknowledges that two groups are present without splitting the audience
Why A fails: "gRPC", "east-west", "Istio" — the VP and PMs are lost after the first sentence. They smile and stop listening.
Why C fails: "Very complex" signals that you don't think your audience can follow. It's defensive framing.
Why D fails: Asking a VP of Engineering and two PMs if they know what a microservice is is condescending.
Mixed-audience architecture technique: 1. One sentence from the user's perspective 2. Navigate the diagram top-to-bottom (entry → services → storage) 3. Add technical depth at each node for engineers: "for the engineers: this is Kafka, because…" 4. Use the word "responsible for" instead of technical jargon where possible
2 / 9
You chose PostgreSQL over MongoDB for the new reporting service. A stakeholder asks why. Which explanation best justifies the technical decision to a mixed audience?
Option C uses the decision narrative format that technical decisions require:
States the specific technical constraint: "8–12 table joins" — not a generic "relational data" statement Explains the cost of the alternative: "denormalise upfront OR multiple round trips" — shows you actually evaluated MongoDB seriously Frames both technical and human costs: "complexity and maintenance cost" (technical) + "team SQL expertise, reduces onboarding time" (organisational)
Why A fails: "ACID-compliant RDBMS" loses non-engineers. Even correct technical answers must be translated for mixed audiences.
Why B fails: "We've done it before" is a tradition argument, not a decision. It invites someone to challenge you with "but why don't you try something new?"
Why D fails: "We evaluated both and Postgres won" — evaluated on what criteria? This is an empty answer.
Technical decision justification format: "We chose [X] because [specific constraint]. [Alternative] would have required [specific cost]. [X] solves that because [mechanism], and given [team/context factor], it was the better fit."
3 / 9
You need to present a trade-off between two architecture options. Which format communicates it most clearly to stakeholders?
Option C demonstrates the balanced trade-off presentation format that earns the trust of technical and non-technical stakeholders:
Names both options neutrally: No framing bias in the description section — both are described with genuine pros and cons Presents real trade-offs, not strawmen: Microservices weaknesses (operational overhead) are real; Monolith strengths (simpler operation, lower cost) are real Makes a concrete recommendation: "Option B for the first 12 months" — not "it depends"; stakeholders need a decision from you Grounds the recommendation in a measurable trigger: "20k DAU" — an objective metric, not a vague "when we need to scale"
Why A fails: "Microservices is technically better" is a platitude; it's not a decision, it's a preference Why B fails: "Old-fashioned" is not a trade-off analysis; it's a bias signal that undermines your credibility
Trade-off presentation structure: Option A: [What it does well] + [Honest cost/risk] Option B: [What it does well] + [Honest cost/risk] Recommendation: [Which and why] + [What would change your mind / trigger criteria]
4 / 9
You're presenting multiple sections of a technical architecture. Which signposting sentence best transitions between sections?
Option C is a connector signpost — the most valuable type for technical architecture presentations:
Three elements of an excellent signpost: 1. Summary of what you just covered: "That covers the ingestion layer — handles incoming events from all client types" 2. Introduction of what comes next: "Now let's look at the processing layer — transformation logic lives here" 3. The connection between them: "ingestion feeds processing, and the rate of buffering determines latency" — this is what the audience actually needs to know
Why connector signposts matter: Architecture diagrams are networks. Without connecting the concepts, each layer looks isolated. The most important thing your audience needs to understand is HOW the pieces interact, not just that they exist.
Why A and B fail: "Next part" and "moving on" are empty transitions — they just create a pause without building understanding
Why D fails: "Too technical" signals poor audience analysis; if a section is too technical for the room, simplify it — don't skip it and create a gap in their understanding
Signpost formula: "[Previous section] covers [function]. Moving on to [next section], which is responsible for [function]. The key connection is [relationship]."
5 / 9
Alex: 'The service needs to handle 10,000 requests per second.' You're reviewing a new microservice designed for user authentication. Which phrasing best addresses this requirement in a code review comment?
The key here is framing the response appropriately for a code review. Option 1 highlights a critical performance issue (response time), which is relevant to scaling. Options 2 and 3 are too positive or simply acknowledge without demonstrating understanding of the problem. Option 4 is incorrect because request rate alone doesn't tell you if the system can *handle* that load effectively.
6 / 9
Sarah (Lead DevOps) sends this Slack message to the team about a planned database migration: 'We're upgrading to PostgreSQL 15. This will involve downtime and requires careful monitoring post-migration. Please be aware of potential impact on reporting dashboards.' Which sentence best clarifies the *reason* for the change?
Sarah's message needs to justify the migration. Option 2 directly addresses this by stating the upgrade and its implications. Options 1 and 3 are too vague, while option 4 misinterprets the message's focus – downtime is a consequence, not the reason.
7 / 9
Ben (Senior Engineer) writes this PR description for a new API endpoint: 'This endpoint retrieves user profiles based on their ID. The response is formatted as JSON and includes the user's name, email, and registration date.' Which statement accurately describes the level of detail provided?
A good PR description should be informative. Option 2 describes a clear and concise explanation of the endpoint's purpose and data format – this is what's needed for review. Options 1, 3, and 4 miss key aspects of API design that are crucial to understand.
8 / 9
Chloe (Architect) is presenting a new system architecture. Which sentence would best signal the transition from discussing the core data layer to the presentation tier?
Signposting sentences are essential for complex presentations. Option 3 effectively guides the audience by explicitly indicating a change of topic – this improves comprehension. The other options lack clarity and don't establish the context for the subsequent discussion.
9 / 9
David (DevOps) receives this API response from a monitoring service: `{"status":"error", "code":403, "message":"Forbidden - Insufficient Permissions"}`. What is the *most appropriate* Slack message to send to the development team?
The Slack message should be informative to facilitate troubleshooting. Option 3 offers a detailed explanation of the error (403 Forbidden), including a specific code and hints at possible reasons (insufficient permissions). This empowers the team to quickly diagnose and resolve the issue.
What will I practice in "Architecture Deep-Dives — Presentations English Exercises"?
This is a Technical Presentations exercise set. It walks through 9 scenario-based multiple-choice questions built around real usage of technical presentations 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 9 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 technical presentations 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 Technical Presentations exercises?
See the Technical Presentations 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 — technical presentations vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.