Preparing for an interview

If you’re planning to do a FeatherCast interview with me, here’s some of the things you should do to prepare:

Listen to a couple of other podcasts. They are very short. This is not a hardship. Get an idea of what kind of things I ask.

Think about what you’re going to say. Yes, I know, that sounds obvious, but I interview a lot of people who seem surprised that I want them to talk about their project. I generally ask the same kinds of questions. What does your project do? Who uses it? What cool things have you seen done with it? How can newbies get involved?

If your talk is about ApacheCon, tell me what you’re going to talk about, and who should attend. Tell me what someone should know before they come so that they’re not asking all the wrong questions. Don’t give the talk to me on the podcast – this is intended to be advertising to get people to attend.

Get headphones and a decent mic. If you try to record a podcast without headphones, everything either one of us says will echo, and I’ll have to throw it out. Your laptop mic is usually ok, but if you have a standalone USB mic of some kind, please dig it out and use it. Find a quiet place. Put the dog in a different room. Turn on a movie for the kids. Silence your cell phone.

Install necessary plugins. I do the recording on Google Hangouts. Some browsers require that you install plugins to participate. Go to the Hangouts website, create a hangout, and see what plugins it tells you to install. Ensure that they all work. I do not use the video for the FeatherCast podcast, so turn the camera on or off, as you prefer.

Tell me your Google username/email. I will invite you to a Google Hangout, and for this I will need to know the Google username that you prefer to use for this. This is particularly important if we are not already connected on G+, and if you have a fairly common name.

During the Interview:

Here’s some tips for what to do during the interview:

Relax: You sound great, and I’ll be editing afterwards to remove anything where you don’t sound great.

Say it again: If you make an error, tell me that you made an error, take a deep breath, and start again. I’ll edit out the error, and nobody will ever know it was there.

Tell me what I missed: Tell me what you want to say, and I’ll craft the interview to include those things. If we get to the end and I missed something, just tell me, and we’ll edit it back into where it should go.

What I’m going to ask you

If the interview is about a project, say, Apache Foo, here’s what I will ask:

  • What does Apache Foo do?
  • Who would use it, and what for?
  • Tell me about a company/organization that is using Apache Foo to make the world a better place.
  • What’s coming in the near future from this project
  • How do I learn more about Apache Foo, and get involved in the project?

If you cannot answer these questions about your project, then you have some work to do. Every project should be able, at a bare minimum, to answer these questions. New projects get a pass on case studies, but everything else is a must, even before you do your first release.

Other possible questions include:

  1. What (commercial?) products/projects are in the same space, and what makes your project better/different?
  2. What other (Apache?) projects do you depend on and/or integrate with?
  3. I want to get involved. What should I work on?<

What I do afterwards

After the interview, I will do everything I can to make the interview sound good. At a minimum, this means removing the ums, ahs, y’knows, and so on, that make the interviewee sound less certain of themselves. And I will often rearrange questions and answers to make them flow better, and remove questions that you didn’t have a good answer to. My goal, as yours, is to promote your project.

The voice of The Apache Software Foundation

%d bloggers like this: