How to give an interactive presentation

A presentation

A month ago I gave a talk in the office. The talk was a JavaScript survival guide for java programmers. You can see the slide show below.

I decided to give an interactive presentation: people could interrupt me with questions and I answered them. Also, we could go deep in one topic while we could skim another – whatever the audience wanted. I really like this format because this way I can teach something that’s useful for them.

However, I didn’t do anything like this for the last couple of years. Some things worked out well while others just didn’t. I’d like to share my experiences with you.

What went well

Declaring it interactive

First of all, I declared that this is going to be an interactive talk. Then I asked an open-ended question: what’s wrong with JavaScript? Then we checked whether their answers were on the slides. This little intro warmed us up so people were asking questions whenever they wanted to.

Basically, that’s it: you declare that it’s going to be an interactive session. Then you ask some questions. Finally, you must listen to the audience.


I had a few slides and lots of example code. I prepared at least 3 times as much material as we could cover. I also tried to ask myself tricky questions, then looked for answers. It was really useful: I could talk about anything they wanted me to. This is what you expect from a presenter, right? However, when you teach what you learn and you give an interactive talk, this can be difficult.

You need to prepare for presentations. I guess you already knew that. The point is that you need to prepare a little more for an interactive talk.

Example code

I already mentioned example code. Still, this is worth its own paragraph.

We all know that a live coding is cool. Or not. When you are not an expert of the field then odds are that it’ll be boring. E.g. it’s not that engaging to watch others looking for typos.

I found it worthwhile to write lots of code-chunks days before the presentation. You can put them on the screen any time you want it. Here you can find my example code.

Similarly, if you want to refer to an external tool like QUnit, it’s worth to save the URL in a txt file.

Lessons learned

Unfortunately, some things didn’t go well. Here are the lessons I learned.


It’s obvious that before the presentation you need some time to prepare the environment: checking the projector, etc. The lesson for me is that I need more time than that. Here is a checklist:

  • Are the slides visible?
  • Is the command prompt visible too?
  • Can I handle the smaller screen?

Minimizing distractions

When you give an interactive talk about programming, then you need several things: slides, browser and a text editor. Also, you must go back-and-forth between them. It doesn’t really help when you have several other things open, like an IDE or browsers with work-related tabs.

I gave this talk to my colleagues during office hours. They knew that I was working before the presentation. They also knew that I was going to work after the presentation. Still, I should’ve turned off every unrelated process. At least switching between browser and editor would’ve been easier.

More slides

It’s really, really cool to run code during the presentation. But that’s somehow not that concrete. When you project things to the wall, people will just forget them. It’s important to show some of the real thing on the slides too.

I hade only nine slides or so when I gave the talk. So I had to improvise a lot. Also, I had nothing to publish after the talk. I had to seriously pimp up the slides before uploading them to slideshare.

Ending it

When you give a good talk, you can expect to make people curious. That’s a good thing. However, it isn’t necessarily a good idea to go on with the details right after the presentation. First of all, you might be exhausted. At least, I was. Also, they might ask very deep questions that you just didn’t prepare for.

So giving an interactive presentation doesn’t mean that anything can happen. You can (and should) set clear borders. E.g. you prepared for 30 minutes, so it’s over.

You can also moderate a conversation after the presentation, just make sure everybody understands what’s happening. Otherwise things can become a bit unfocused – and this is not the impression you want to give.


About tamasrev

A software developer, specialized in Java, addressing himself as generalist. A proud daddy.
This entry was posted in programming, soft skills and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s