Preparing for an interview on an Engineering Podcast

How does an engineer prepare for an interview on a podcast?

Most interview experience for engineers probably comes from applying for a job. So it's understandable if an invitation to talk about your work leaves you wondering how much preparation is enough.

Should you write a script? Prepare a presentation? Have the technical details of every project ready?

Start somewhere else. What should a listener understand by the time the conversation ends?

That question gives the rest of your preparation a purpose.

Find out who you're talking to

Ask the host who normally listens. Students, working engineers and people outside the profession will need different amounts of context.

A control systems engineer might recognise SCADA immediately. Someone listening because they're curious about engineering may need a plain-English explanation first.

Also confirm the format. Is the conversation live or edited? Audio only or video? How long is it likely to run? Are you discussing a specific project or your broader career?

You aren't trying to control every question. You're finding out what kind of conversation you've agreed to have.

Pick three things worth remembering

Write down three ideas you would be happy for someone to take away.

For example: engineering careers can cross industries; asking better questions changes the problem you solve; and communication matters when a design involves several teams.

These should be ideas you can explain through experience, rather than three claims about how impressive you are.

If you get nervous or the conversation wanders, they give you somewhere useful to return. You don't have to force all three into every answer.

Prepare stories, not a speech

Choose a few examples that make those ideas real.

For each, note the situation, the problem, what you did and what you learned. Include the part that was uncertain. That's often more useful than a polished account where everything went to plan.

Keep your own contribution clear. If a team delivered the project, explain your part without accidentally taking credit for everyone else's work.

And check what you're allowed to share. You can explain a lesson without naming a client, revealing system details or describing confidential incidents. Decide those boundaries before the microphone is on.

Translate the technical detail

Try explaining one example to someone who doesn't work in your field.

Where do they stop you? Which acronym needs explaining? At what point have you described the equipment but forgotten to explain why the problem mattered?

A useful order is purpose first, then the technical detail needed to understand the decision.

For instance, “The system had to keep operating while we made the change” gives a listener something to care about before you discuss redundancy or migration.

You can go deeper when the host asks. You don't need to unload the whole drawing set in the first answer.

Rehearse the beginning and the ending

Practise a short introduction: who you are, the kind of engineering you do and why the topic interests you.

Then practise answering a question out loud. Speaking exposes long sentences and missing connections that look perfectly reasonable in your notes.

Use a few prompts during recording rather than reading a full script. It should still sound like a conversation.

Prepare a simple closing too. If listeners want to learn more, where should they go? Give the host the correct link and a short biography beforehand, so nobody has to reconstruct your details afterwards.

Make the recording easy to listen to

Use a quiet room, wear headphones and check the recording setup with the host. A short test can catch the wrong microphone, echo or distracting background noise.

Silence notifications and keep water nearby. If the host records separate local tracks, follow their instructions and leave any files in place until they've confirmed the upload.

During the conversation, it's fine to pause. You can ask for a question to be clarified or say that a detail needs checking. Accuracy matters more than sounding instantly certain.

Aim to be useful

The best preparation leaves you ready to explain, rather than determined to deliver a rehearsed performance.

Know the audience, choose a few worthwhile ideas and bring examples that help people understand them.

An engineering podcast gives listeners a chance to hear how engineers think. That includes uncertainty, teamwork and the lessons behind the finished result.

If you'd like to hear how I approach those conversations, explore the Engineering IRL podcast. And if the harder part is asking a more experienced engineer a question yourself, that is a skill you can practise too.