4 exercises — writing compelling abstracts, professional speaker bios, outcome-driven slide titles, and handling hostile Q&A at the end of your talk.
0 / 4 completed
1 / 4
You're submitting a talk abstract for a developer conference. The topic is "Reducing cold start latency in serverless functions". Which 150-word abstract is strongest?
Option C demonstrates the conference abstract formula:
1. Opens with the cost: "300–3,000ms on every first invocation" — programme committees and attendees both need to know immediately why this matters 2. Specificity of content: Lists exactly what will be covered (JVM, Node, Python; percentile tracking; 3 named techniques) — shows deep preparation 3. Concrete takeaways: "diagnostic checklist" and "working optimisation strategy" — tells attendees what they'll leave with, not just "learn about X" 4. Target audience: "backend engineers already running serverless in production who want sub-100ms P99" — precise audience targeting helps programme committees place the talk correctly
Why A fails: Uses weak future-tense patterns ("I will explain", "I will talk about") without specifics — this reads as a first draft
Why B and D fail: Generic framing ("great way to build", "I've worked with serverless for years") — every session at the conference could say these things
Abstract formula: [The specific cost/problem] → [Exactly what you cover] → [What attendees leave with] → [Target audience]
2 / 4
The conference asks for a 80-word, third-person speaker bio for the programme. You are "Alex Kovacs, Senior Platform Engineer at CloudBase, creator of the open-source tool latency-watch." Which bio is best?
Option B is a professional conference bio because it follows the role → scale → proof → history formula:
1. Role with concrete scale: "40M+ monthly active users" — not just "senior engineer" but engineer at scale 2. Credibility proof: "1,800 GitHub stars" — measurable community recognition; not "popular open-source tool" 3. Tool description: "real-time serverless cold start monitoring" — tells readers what latency-watch actually does 4. Track record: "reduced P99 latency by 62%" — a specific result, not a vague claim 5. Third person throughout: professional speaker bios always use third person
Why A fails: "Likes solving hard problems", "passionate about performance" — these phrases are in half of all conference bios and say nothing differentiating
Why C fails: Description adds no credibility and repeats that he'll give a talk — the programme already tells people that
Why D fails: "A lot of experience" and "very passionate" are superlatives without evidence
Bio formula: Role + company + one concrete scale signal → open-source/achievement with a number → one prior measurable result
3 / 4
You're creating a presentation slide about improving deployment frequency. Which slide title is strongest?
Option D uses an outcome-based, action slide title:
Three title types (worst to best): 1. Topic title (A): "Deployment Frequency" — tells you nothing about what happened or what you'll learn 2. Activity title (B): "Improving Deployment Frequency" — describes a process, not an outcome 3. Story title (C): "How We Improved Deployment Frequency" — better, but still vague on what actually changed 4. Outcome title (D): "From 2 Deployments/Week to 20: How We Eliminated Manual Approval Gates" — tells the complete story in the headline
Why outcome titles win: • The audience knows immediately if the slide is relevant to them • "From X to Y" format makes the improvement concrete and comparable • Identifies the specific cause: "manual approval gates" — not just "better process" • Works as a summary even if someone skips the slide body
Outcome title formula: "From [before state] to [after state]: How We [Specific action that caused the change]"
Or for non-transformation slides: "[Claim or finding]: [Evidence or mechanism]"
4 / 4
During a conference talk Q&A, an audience member asks aggressively: "Isn't everything you just described just marketing? There's no way those latency numbers are real in a production system." How do you respond?
Option B demonstrates the defusing a hostile question technique:
1. Acknowledge the underlying legitimacy: "production conditions are messy" — validates that scepticism about headline numbers is reasonable; doesn't treat the challenge as purely hostile 2. Lead with methodology, not claims: "three regions, p99, 90 days" — shows you know the difference between a cherry-picked number and a robust measurement 3. Offer verifiable evidence: "share the Grafana dashboard link" — turns a verbal claim into something the audience can inspect 4. Invite their counter-evidence: "I'd genuinely like to understand the configuration" — flips the dynamic from confrontation to technical collaboration; signals confidence
Why A fails: "I measured them myself" is an appeal to your own authority, not to evidence. It escalates the confrontation
Why C fails: "I can assure you" is another authority appeal — exactly the pattern a sceptical engineer will push back against
Why D fails: Commenting on the tone in a conference Q&A creates an adversarial moment in front of the entire room and ends the technical dialogue
Hostile question formula: Validate underlying concern → Lead with methodology → Offer verifiable evidence → Invite their data