4 exercises — presenting both options neutrally, defending a technical decision under pressure, negotiating build vs. buy, and conceding a point professionally.
0 / 9 completed
1 / 9
You need to present a technical trade-off between REST and GraphQL APIs to stakeholders including engineers and the product team. Which presentation is most balanced?
Option C is a complete trade-off presentation because it:
1. Presents both options neutrally in parallel: REST's strengths are described as real strengths (not strawmen), GraphQL's weaknesses are stated honestly 2. Names constraints in technical terms: "over-fetch / under-fetch", "network-layer caching" — uses correct vocabulary but with functional explanations 3. Connects the recommendation to the specific context: "three client types and a small backend team" — not a generic recommendation, but one grounded in this team's situation 4. Invites pushback on a specific point: "I'm open to pushback on the caching concern" — names exactly where the recommendation is weakest, which builds trust
Why A fails: Declares a winner without analysis — stakeholders who care about REST will feel their concerns weren't considered
Why B fails: "Hard to say" is not a trade-off analysis, it's an abdication
Why D fails: "More standard" is an authority argument, not a contextual recommendation
Trade-off formula: Option A (strengths + honest trade-off) → Option B (strengths + honest trade-off) → Recommendation grounded in THIS context → Invite pushback on your weakest point
2 / 9
You're defending a technical decision (using PostgreSQL over MongoDB) and a senior engineer challenges it in a design review. Which response best defends the decision?
Option C is a strong decision defense because it:
1. Acknowledges the challenge as a "good" one: signals confidence, not defensiveness 2. Restates the specific technical reasoning: "8–12 tables", "sub-50ms with that join depth" — precise technical evidence 3. Names the specific cost of the alternative: "denormalization adds maintenance complexity" OR "round trips add latency" — shows you actually evaluated MongoDB 4. Finds a partial concession that's honest: "document data in user profiles is a valid gap" — acknowledges where your decision has a weakness 5. Offers a synthesis: "JSONB columns for that subset" — shows a path that incorporates the challenger's concern without abandoning the decision
Why A fails: "I already explained this" is dismissive and signals the decision wasn't thought through well enough to re-articulate
Why B fails: Immediately yielding to pressure suggests the original decision lacked foundation
Why D fails: "Decision already made" cuts off technical dialogue — in a design review, that's the wrong signal
Decision defense formula: Acknowledge challenge → Restate specific technical reasoning → Name the cost of the alternative → Find the valid gap in your position → Offer synthesis
3 / 9
You recommended building an internal authentication library, but your manager prefers buying a third-party solution. You believe the build option is correct. How do you negotiate this respectfully?
Option C is a collaborative build vs. buy negotiation because it:
1. Acknowledges the validity of the manager's preference: "lower upfront cost and faster to integrate initially" — shows you understand why they prefer it 2. States a specific, concrete concern: "multi-tenant isolation" and "custom RBAC integration" — not "vendor lock-in" (generic) but specific technical requirements 3. Provides research to support the concern: "I checked the three leading vendors" — not just an opinion, but evidence 4. Expresses genuine openness to the alternative: "I'm not opposed to buying — I'd actually prefer it if the fit is right" — removes the adversarial dynamic 5. Proposes a bounded validation step: "3-day evaluation sprint" — a small, low-cost test that either validates the manager's preference or confirms the concern 6. Stakes a personal commitment: "I'll drop my build preference immediately" — shows this is about the best technical outcome, not ego
Why A fails: Repeats the position without new reasoning
Why B fails: Uncovers capitulates without sharing the technical concern — leads to a decision that may fail later
Why D fails: "Vendor lock-in" is a generic concern that doesn't reflect the specific technical requirements
Build vs. buy negotiation: Acknowledge preference → State specific concern + evidence → Express genuine openness → Propose bounded evaluation → Personal commitment to accept the result
4 / 9
You need to concede a technical point during a negotiation. Which is the most professional way to yield on a decision?
Option C is a professional concession that preserves your credibility:
1. Names what changed your mind: "[specific new data/argument]" — shows your original position wasn't wrong given the information you had; you're updating based on new information 2. States exactly what you're conceding: "I'm withdrawing my recommendation for [A] and supporting [B]" — precise, not vague 3. Adds a review condition: "I'd want to add one condition: review in Q3 once we have real traffic data" — acknowledges that decisions under uncertainty deserve checkpoints 4. Links the condition to the original concern: "in case the [specific risk I named] materialises" — shows your original concern was valid even if the recommendation changes
Why A and B fail: "Fine" and "you're right" without context — sounds like capitulation under pressure rather than an update based on evidence
Why D fails: "I disagree but I'll go along" — this is the worst pattern; it implies you're not committed to the decision and sets up an "I told you so" dynamic if things go wrong
Professional concession formula: [What changed your mind] → [Exactly what you're conceding] → [Supporting the new option] → [One review condition linked to your original concern]
5 / 9
Sarah (Lead Frontend Developer) comments on your PR: 'This implementation uses a complex regex to validate user input. While it works, consider the potential performance impact and maintainability issues for future updates. Perhaps a more robust validation library would be a better long-term solution.' Which response best addresses Sarah's concerns while presenting a trade-off?
This question tests recognizing that trade-offs often involve acknowledging valid points while defending a chosen path. Option A dismisses concerns without justification. Option B is overly defensive and ignores potential problems. Option D suggests action but doesn't fully address the core of Sarah's critique – performance and maintainability. Option 3 acknowledges the validity of the concern, frames it as a risk/reward situation, and offers a path forward.
6 / 9
Mark (Product Manager) sends you this Slack message: 'Hey team, we need to prioritize adding support for JSON Web Tokens (JWTs) to our API. It's crucial for user authentication and authorization.' You know that implementing JWTs would require a significant refactor of the existing codebase and introduce new security considerations. Which response best balances Mark's request with your technical assessment?
This scenario focuses on negotiating priorities. Option A is unrealistic given the technical implications. Option B directly addresses the core issue – risk and timeline – framing it as a discussion point. Options C and D avoid acknowledging the potential challenges presented by Mark's request. It's about respectfully pushing back while still showing engagement.
7 / 9
You are writing a PR description for a new feature that involves using Docker containers for deployment. You need to explain why this approach is preferable to the previous method of deploying directly to the production servers. Which statement best captures the trade-off you're presenting?
The key here is to articulate the *why* behind the choice. Option A is superficial. Option B focuses on process but misses the core benefit. Option D is misleading and fails to explain the trade-off. Option 3 clearly identifies the benefits (isolation, consistency) and acknowledges that stability often comes with increased complexity – a realistic trade-off.
8 / 9
Your team is deciding between two database technologies: PostgreSQL and Cassandra. The primary concern raised by the development team is cost. Cassandra offers significantly lower operational costs due to its distributed architecture. However, PostgreSQL provides superior data integrity features. How do you phrase your response to David (Database Architect) during a meeting?
This tests negotiating a complex trade-off. Option A is too simplistic and potentially dangerous. Option B ignores the team's concerns about data integrity. Option D is overly deferential and doesn't engage in critical analysis. Option 3 proposes a collaborative approach to evaluating the situation based on specific needs, acknowledging both advantages.
9 / 9
You've suggested using a microservice architecture for your new application, but your team lead, Emily, is hesitant due to the added operational complexity. She says, 'Microservices increase our monitoring and management overhead.' Which response best demonstrates a willingness to discuss the trade-off?
This focuses on acknowledging the opposing viewpoint and presenting your rationale. Option A is dismissive. Option B directly addresses Emily's concern while highlighting the advantages of microservices – a balanced approach. Options C and D avoid the core issue and represent unproductive responses. It's about showing you've considered their perspective.
This module focuses on Negotiation English — real workplace phrasing you'll use on the job. It contains 9 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 9 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Negotiation English exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around negotiation english — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Negotiation English exercises?
See the Negotiation English hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.