Speaking at Meetups, Conferences, Submitting CFPs
Speaking at events is high-leverage for career and network. The CFP process, talk structure, and how to start at meetups before tackling major conferences.
What you’ll learn
- Write a CFP that gets accepted.
- Structure a technical talk that an audience actually enjoys.
- Build a speaking track from local meetups to major conferences.
Speaking at a conference puts you in a small group. Most engineers, including senior ones, never give a public technical talk. The ones who do reap disproportionate career returns: visibility, network, job offers, freelance leads, book deals.
Scraping has very few specialist speakers. Showing up consistently at any decent conference puts you on the short list of "people known for scraping."
Why speaking matters
- Audience compression: 50 minutes in front of 200 attentive engineers builds more trust than 1000 blog posts.
- Network: speaker dinner, hallway track, organizer relationships, sponsor introductions.
- Authority: "spoke at EuroPython on Scrapy" is a credential a single line of text on LinkedIn can't fake.
- Speaker pipeline: one talk leads to invites; the second is far easier than the first.
- Self-discipline: structuring a talk forces you to know your material deeply.
Start at meetups, not at conferences
The CFP for PyCon US is competitive and the prep cost is high. Local meetups:
- Often accept any reasonable proposal.
- Are 20-30 minute talks (less prep than conference talks).
- Have small forgiving audiences (10-50 people).
- Build your speaking reps cheaply.
- Provide a recording you can submit as proof-of-experience to conferences.
A reasonable trajectory:
- Local Python/PHP meetup.
- Regional conference (PyOhio, SymfonyConCommunity, etc.).
- Larger regional / national (DjangoCon, SymfonyCon, EuroPython).
- Major international (PyCon US, FOSDEM, KubeCon if relevant).
Steps 1-2 typically over 1-2 years. Steps 3-4 over the following 1-3.
The CFP process
Most conferences solicit proposals 3-6 months in advance via a Call For Proposals (CFP):
- Talk title (catchy + descriptive).
- Abstract (150-300 words; what attendees will learn).
- Outline (5-10 bullets; what's covered).
- Bio (your background, why you can give this talk).
Reviewers see hundreds. Yours needs to:
- Be specific, "Beating Cloudflare in 2026" beats "Advanced Web Scraping."
- Promise a concrete outcome, "you'll leave knowing how to..."
- Match the conference's audience level.
- Stand out, what's the unique angle?
CFP example (good)
Title: "TLS Fingerprinting: Why Your Scraper Is Detected Before HTTP"
Abstract:
Modern anti-bot systems detect Python scrapers before parsing any HTTP request. The reason is TLS-level: Python's default ssl module produces a fingerprint that exactly matches "Python script" and exactly mismatches "real browser." This talk explains how TLS fingerprints work, demonstrates detection in action against a live site, and shows three working approaches to evade detection: curl_cffi, JA3 spoofing, and TLS-client.
By the end, attendees will understand the full TLS handshake from a fingerprinter's perspective, and have working code to apply in their own scrapers.
Outline:
- 0-5 min: a live demo: scrape works, then suddenly stops, with TLS as the diagnostic.
- 5-15 min: what TLS handshakes actually expose, JA3, JA4 fingerprints.
- 15-25 min: anti-bot systems consuming these (Cloudflare, Akamai, DataDome).
- 25-35 min: three evasion approaches with code.
- 35-40 min: when this works and when it doesn't.
- 40-45 min: Q&A.
Bio: I run scraping infrastructure for [project/company], focused on anti-bot resilience. Author of [package/blog/articles].
That's a CFP that gets accepted at a decent conference.
Talk structure
A 30-45 minute conference talk:
| Time | Section |
|---|---|
| 0:00-2:00 | Hook, a startling problem, demo, or claim |
| 2:00-5:00 | Why this matters / what attendees will learn |
| 5:00-25:00 | Main content (3-5 sections) |
| 25:00-30:00 | Real-world application / case study |
| 30:00-35:00 | Limits / what doesn't work |
| 35:00-40:00 | Conclusion + Q&A |
The hook in the first 2 minutes determines whether attendees stay engaged. A demo that fails first and then succeeds is reliably engaging.
Slides
Less is more:
- One idea per slide. If you have 5 bullets, that's 5 slides.
- Big text. Visible from the back row.
- Code on slides should be 6-12 lines. Larger blocks lose the audience.
- Live demo > pre-recorded, but with a backup video if it might fail.
- Don't read slides. Audiences read faster than you talk; if slides are full sentences, they'll get ahead of you.
Tools: Keynote, PowerPoint, Google Slides, or revealjs for code-heavy presentations. The tool matters less than the content discipline.
Practicing
For a 40-minute talk, practice:
- 3 times solo with a timer.
- 1-2 times in front of someone for feedback.
- Always slightly under time in practice, Q&A and "stage time dilation" eat 5+ min.
Most speakers go over time at conferences. The audience notices and dislikes it. Cut content if needed; never run over.
Getting paid (or not)
Conference speakers are typically:
- Not paid an honorarium at most tech conferences.
- Reimbursed for travel/hotel at major conferences (PyCon, EuroPython, KubeCon, etc.).
- Paid speaker fee ($1k–$10k) at private corporate events and a handful of paid summits.
Don't go in expecting payment. The career return comes from the audience, network, and recording, not the speaker fee.
Avoiding common mistakes
- Submitting to too many CFPs at once. Pick a couple; tailor each.
- Recycling old talks years later. Same talk twice is fine; the same talk in 2028 that was good in 2026 is suspicious in fast-moving niches.
- Promotional talks. "Here's why my product is great", rejected.
- Vague titles. "Future of scraping" beats nobody.
- Forgetting to record yourself. Recordings let you re-share and submit to bigger CFPs.
Building a speaking pipeline
After your first talk:
- Add it to your blog/site. Title, abstract, link to recording.
- Mention you spoke in your bio for the next CFP.
- Submit to a similar but larger event with slight refinements.
- Network with other speakers, they're often organizers/reviewers elsewhere.
Two talks in a year is solid. Five over five years and you're a "known" speaker in your niche.
What to try
If you've never spoken publicly:
- Find your local Python or PHP meetup.
- Email the organizer: "I'd like to give a 25-minute talk on [specific topic]. Here's my abstract."
- Most meetups will say yes within a week.
- Use the meetup as your first reps.
If you've spoken at meetups already, submit to one regional conference this quarter. Don't aim for prestige; aim for the rep.
The hard part is the first submission. After it, you understand the pattern and the next ones are easier.
Quiz, check your understanding
Pass mark is 70%. Pick the best answer; you’ll see the explanation right after.