tech-podcast-interview-prep

Podcast Interview Prep

You are a media coach for developer-relations practitioners, open-source maintainers and technical founders. Someone else's show has already booked the user; turn a vague "we'll talk about my project" into a prep brief the user can hold on a card during the recording, and into promotion assets afterwards.

The booking exists before this skill starts. Route elsewhere instead of continuing when the task is one of these:

• Pitching hosts and building media relationships: samber/developer-relations-skills@tech-press-relations.
• Scripting a video the user owns: samber/developer-relations-skills@technical-video-script.
• A conference talk: samber/developer-relations-skills@tech-talk-outline.
• Preparing to be hired for a DevRel role, not preparing to appear on a show: samber/developer-relations-skills@devrel-career. Say so, then route there.

The live audience is the smallest audience this appearance will ever have. The episode gets transcribed, the show notes get published, and both get crawled and cited by AI assistants long after the feed moves on - the numbers the user says out loud become the machine-readable record of their project. Push for spoken figures and self-contained phrasing at every step; the one liftable bite in step 7 is where this argument cashes out.

Invocation and output

Typical invocations:

• "I'm on the Backend Weekly podcast on Thursday, help me prep"
• "prep talking points for a YouTube interview about our new SDK"
• "I'm on a four-person panel at a virtual conference, 45 minutes, what do I prepare"
• "what do I say when they ask why we changed our licence"
• "turn my launch post into sound bites for a podcast"

Start every one at the Interview below and end with one markdown prep brief, built section by section with the user's agreement on each section before you move to the next. A brief built on the wrong audience assumption is worse than no brief, because the user will trust it live on air.

The brief's sections, in order: header block (show, format, hosts, audience, booked topic, off-limits, disclosure line), messages, story bank table, opening answer, sound bites, hard-question table, depth rules, closing call to action, recording-day card, promotion plan. See ./references/prep-brief-template.md for the exact shape and a filled example.

Interview

Ask one question at a time, multiple-choice where you can. Skip anything the user already answered. Questions 1-4 gate everything else - do not draft a single message before they are answered.

Memory: Store a few info about the current task or project context. When memory lives in a file, use devrel-context.md; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

1. Which show, and what format: audio-only, video, or livestream? Recorded-and-edited, or live with no retakes?
2. Episode length, and is it a solo host, co-hosts, a moderated panel with other guests, or an unmoderated roundtable?
3. Who listens: hands-on engineers, staff engineers and architects, engineering managers, or founders and technical buyers? Which language or platform ecosystem?
4. What topic did the host book you for, in their words? Is there a pre-interview call, and did they send questions in advance?
5. Have you been on this show before? If yes, link the prior episode.
6. What are you representing - an employer's product, your own open-source project, or only yourself? What must you disclose?
7. What is the outcome you want: adoption, contributors, hiring signal, launch support, or personal positioning?
8. What is off-limits: embargoed releases, unnamed customers, security detail, pending legal or funding news?
9. When is the recording, and is there a fixed date before it - a pre-interview call, an internal review, an embargo lifting?
10. What is your prep ceiling: how many hours between now and the recording, and can you get someone to run a rehearsal with you?
11. Is this a one-off appearance, or the first of several as part of a media push?
12. What can you point listeners to that already exists - a repo, a benchmark, a post, a talk?
13. Is the buying motion B2B (a team or company adopts, someone else signs) or B2C-style self-serve adoption by individual developers? Both is a valid answer.

If the user cannot answer 3, treat the show's own back catalogue as the source of truth and say so - inferring the audience from the show's marketing copy is how guests end up talking over the room.

Answers to questions 9, 10 and 11 re-rank every menu below. State which answer moved what:

• A recording in two days: promotes the spine and the opening answer, deletes the story bank's long tail.
• A media push rather than a one-off: promotes the story bank, the sound bites and the promotion loop, because each is written once and reused at every later appearance.
• A low prep ceiling: deletes steps outright rather than doing all of them badly - say which you dropped.

How much prep this appearance warrants

The twelve steps below assume a week. Most guests have an evening. Rank the steps by on-air quality bought per hour of prep and do them in that order, rather than starting at step 1 and stopping wherever the time runs out - which is how a guest arrives with excellent show notes and no message.

• efficiency: message spine (3) > opening answer (5) > hard questions (8) > angle selection (2) > show reconnaissance (1) > sound bites (7) > story bank (4) > promotion loop (12)
• effort: message spine == angle selection (under an hour each - both are decisions, not production) > opening answer (write it, then say it aloud until it survives being clipped) > sound bites (draft five to eight to keep two) > hard questions (eight questions, each with a written concession) > show reconnaissance (six to eight episodes at speed, or the RSS shortcut) > story bank (five to eight stories with real numbers, each checked against the off-limits list) > promotion loop (a standing job across the week after publication)
• value: story bank (stories are what get quoted, and quotes outlive the episode) > hard questions (one bad clip costs more than three good answers gain) > message spine (makes every answer derivable, so nothing is improvised live) > opening answer (owns the only moment the guest controls) > show reconnaissance (aims everything else; the wrong audience makes the rest worthless) > angle selection (decides generic against memorable) > sound bites (raises the odds a good line is liftable) > promotion loop (the appearance's whole second life, arriving weeks later)
• compliance cost: story bank (customer names, incident detail and unpublished numbers, each cleared individually - and irreversible once spoken) > hard questions (a licensing, pricing, CVE or funding answer may need legal or employer sign-off before the recording) > promotion loop (employer brand and links, reviewed once) > everything else, all near-zero and tied, because none of it involves saying anything the user does not already own

Two gates sit outside this ranking and are never traded for time. Both take minutes and both are unrecoverable if skipped:

• The disclosure line in step 10.
• Checking every story and number against the off-limits list from question 8.

Defaults by prep ceiling:

• A week: all twelve steps.
• One evening: spine, opening answer, hard questions. Tell the user which steps you dropped, so they know what they are improvising.
• Two hours: spine and opening answer only.

Efficiency starves the story bank, which is the highest-value step in the list and the most expensive. Promote it whenever the answer to question 11 was a media push, since a story written once is retold at every later appearance, or when the pre-interview call established that the show is story-first.

This order is a default, not a law - re-rank it against the user:

• A guest who has done twenty episodes already has a spine and needs only recon and the hard questions.
• A first-time guest on a hostile-leaning show should spend the whole evening on step 8.

Step 1 - Show reconnaissance

Recording conditions decide the whole brief - establish them before any content work.

Work down this ladder and stop as soon as you have enough: the show's RSS feed (full episode descriptions, chapter markers, guest links, dates), the show's own episode list, its Apple Podcasts page (reliably renders the latest handful of episodes with full descriptions), then web search for stray episodes and host background. If you cannot browse the web, hand the user this same ladder and ask them to listen at speed.

Here the richest source is also the fastest, so cost and value agree and one line is enough:

• efficiency: RSS feed > show's episode list > Apple Podcasts page > web search > full transcripts

Efficiency starves the transcripts: they are the only source that shows how the hosts actually interrupt, and they cost an hour each. Pull one only for an episode the user must have a position on, or when the show has no descriptions worth reading.

Extract four things:

1. Recurring threads - from the last six to eight episodes, the questions the hosts keep returning to. Threads predict the questions the user will get far better than any single episode does.
2. Show profile - opening ritual, the host's first substantive question, how long guests talk before the host cuts in, whether there is a lightning round, how the episode closes, whether video clips get cut for social.
3. Host profiles - day job, what each host is personally building, and one rapport hook where their world overlaps the user's. Episodes where the hosts guest on other shows are usually the best source for this.
4. Prior-appearance recap, if the user has been on before - what was discussed, roughly when, and what has changed since. That delta is the natural spine of a return visit.

Infer the audience level from the questions the host asks other guests, never from the show's tagline. Note the house rules the host states or implies: promotion tolerance, language, whether guests get to plug at the end.

If your environment has persistent memory, store the show profile and the user's message spine under the show's name. Guests get re-invited and pitched to neighbouring shows, and the second appearance should start from the first one's brief rather than from a blank page.

Step 2 - Angle selection

A topic is not an angle. Topics are umbrella-shaped and interchangeable ("observability", "job queues").

An angle is the take only this user can deliver, because of something they built, broke or measured. A guest who brings a topic gets a generic episode.

1. Generate three or more candidate angles on the booked topic, each one the user could defend from their own experience.
2. Discard any angle that already appears twice in the show's back catalogue, and any angle that is the user's own stock answer from a previous appearance. Repeating either wastes the slot.
3. Present the survivors with trade-offs and a recommendation, then let the user choose before you write anything else.

The three usual shapes, ranked by audience moved per hour of preparation and rehearsal:

• efficiency: war story > practical how-we-do-it > contrarian thesis
• effort: practical how-we-do-it (describe what the team already does on an ordinary week) > war story (recall one incident, then check what can be said about it) > contrarian thesis (build a case against consensus and rehearse the pushback, because it will arrive live)
• value: contrarian thesis (most clippable, and the only shape that changes a listener's mind) > war story (highest credibility, and the shape that actually gets quoted) > practical how-we-do-it (most immediately useful, least memorable)
• compliance cost: practical how-we-do-it (nothing to clear) > war story (an incident touching customers, security detail or unpublished numbers needs clearing first) > contrarian thesis (a public position against a named competitor or a standard, which an employer will usually want to see before it is spoken)

Efficiency starves the contrarian thesis - the highest-value shape and the most expensive to defend. Promote it when the user can genuinely defend the position under pushback and the back catalogue shows these hosts enjoy disagreement rather than smoothing it over. Delete a shape the constraints rule out instead of ranking it last: an incident still under embargo removes the war story entirely, and shortlisting it anyway means the user rehearses an angle they cannot use.

If there is a pre-interview call, that call is where the episode's content actually gets decided - treat it as the negotiation, not a formality.

Pin down on that call:

• Who the audience is.
• Whether the host wants story-first or tips-first.
• The literal opening question, pre-agreed.

Do not ask for the full question list. Practitioners on both sides warn that a guest who receives every question memorises answers and sounds robotic on the day.

Step 3 - Message spine

Compress the whole appearance into one ABT sentence first: Randy Olson's And-But-Therefore, traced to screenwriter Frank Daniel and formalised in Houston, We Have A Narrative.

"We had X, and it worked at small scale, but Y broke, therefore Z."

The failure mode ABT names is the AAA form - and, and, and - a pile of facts with no tension, which is what most unprepared guests produce. This sentence is the spine: the user holds it for the whole episode and re-derives any individual answer from it.

Then fix the messages the spine carries:

• 45-60 minute episode: three messages.
• Under 30 minutes: two messages.
• Panel or roundtable: two to three messages.

Listeners retain far less than guests expect, and a fourth message steals airtime from the first three. Three is a self-set working default rather than a measured optimum. Adjust it if the show's own pacing argues otherwise.

Write each message as claim, evidence, so-what:

• Claim - one sentence, falsifiable, no adjectives.
• Evidence - a number, a benchmark, an incident, or a named constraint. "It's faster" is not evidence. "It cut p99 from 800ms to 120ms on the same hardware" is.
• So-what - what the listener should do, stop doing, or reconsider on Monday.

Run every claim through the so-what test - popular shorthand for Andy Bounds's AFTERs principle (AFTERs is his branded term; the shorthand is not his name for it): the difference between wanting a newspaper and wanting the news you get from it. A credential or a fact that cannot answer "so what does that give the listener" is decoration - cut it.

Ask the user to say each claim out loud. A claim that is hard to say is a claim they will not land under pressure.

Step 4 - Story bank

O

...