How to give a talk

Ulle Endriss — created: 7 December 2010 — last updated: 27 October 2017

Below I'm offering a few opinions about how to give a good talk. This is about scientific or scholarly talks presented in an academic setting. The typical talk I have in mind is a contribution of, say, 20-30 minutes at a conference, but much of what I have to say also applies to longer talks, e.g., the kind of talk you might deliver at a departmental seminar. My own field is AI and my suggestions apply, in particular, to talks in AI that combine contributions of a conceptual and a mathematical nature. But from what I have seen, things are not all that different in many other disciplines.

These notes have grown out of a set of guidelines originally written for the students in my course on computational social choice in 2010.

There's lots of information out there, with many other people also offering their opinions about how to give a talk. You should have a look at all of that stuff as well, particularly by people who work in a similar field as yourself. For any of the guidelines I formulate here, feel free to not follow them. All I ask for is that you think about these issues and, for any particular piece of advice, make a conscious decision about whether or not to follow it. This will make attending talks a lot more enjoyable and productive for all of us.

Types of Talks

There are different types of talks. You might use slides (common in Computer Science), give a blackboard presentation (common in Mathematics, at least for longer talks), use a handout (common in Linguistics), or read out a carefully crafted paper (common in parts of Philosophy). I'm only going to talk about the first option here, as it is the only one I know how to do well myself.

I think using slides is an excellent way of giving a talk. It's main—maybe even only—disadvantage with respect to all the other types of talks mentioned above is that it allows the speaker to move at a much faster pace than the audience ever could. As long as you are aware of this pitfall and try to avoid it, you can safely work with slides.

The Objective of the Talk

Think about why you want to give your talk before you start preparing for it. If you are giving a short talk at a conference about your own research, then your objective should be to convince the audience that the problems you are working on are important and interesting, and that the paper with your latest results is worth reading. You don't have to list all your results and you should not be under the illusion that it will be feasible to fully explain your results in the time available. Instead, by carefully choosing bits and pieces that you can explain in the context of the talk, you should try to convince the audience that you are serious and that your judgment on what is significant and what is technically correct can be trusted.

For a longer talk, such as a seminar talk given in front of a small audience of—mostly—specialists, your objectives may be somewhat different and you may really want to, say, go through a proof in some detail. But even then, your main goal should be to get people interested in the topic and to read your paper.

The Structure of the Talk

A good talk will have a beginning, a middle, and an end. Yes, really. So, don't forget about the beginning, i.e., don't just jump right into the technical contribution of your research without having motivated it first. Also don't forget about the middle part either, i.e., don't talk only about motivation or background material or related work, but make sure you use most of the time you have to talk about the real thing: your contribution. Finally, don't forget the end, i.e., don't just stop after you have stated your final result, but spend some time on a proper conclusion in which you make sure your take-home message really does hit home.

Here is a suggestion for a set-up that will work well in most cases:

Make sure you use your final slide to (once more) get across your main message. A good conclusion of the kind sketched above, presented on a single slide, will do the job. Thus, your final slide should most definitely not just be saying "Thank you!" or "Questions?", it should not show a cartoon (however funny it may be) or a picture of your favourite pet or child (however cute they may be), and it also should not be a list of all the references you cited earlier on in the talk. Why? Due to the question period, your last slide will typically be visible for much longer than any of the other slides. That's an opportunity not to be missed! So make sure it optimally serves your objective. A well-done final slide also helps the audience to ask relevant questions.

Preparing the Slides

Here are some basic issues to keep in mind as you are preparing your slides:

Delivering the Talk

Next, a few tips regarding things to keep in mind as you are delivering your talk. If you know that you usually tend to get a couple of them wrong, particularly when you are nervous about presenting in front of people, make it a habit to remind yourself of those things directly before your talk (for me, this is: "speak slowly!").

Questions

Getting questions. Don't be afraid of questions. The worst that can happen to you as a speaker is when nobody has any questions. If they ask questions that are on topic, you surely will have something to say. If it's a difficult technical question, nobody expects to get a perfect answer right away. And if it is about related work you are not familiar with, it's fine to just say so and to thank the person who asked for the pointer.

Asking questions. As a member of the audience, do your part and contribute to scientific progress by asking good questions. During the talk itself, if it is a relatively short talk with strict time constraints, it's usually best to avoid questions or to restrict them to very short clarification questions that you feel really need an answer, right now and not just for your own sake. For longer talks, on the other hand, a few questions throughout the talk make the whole thing more interesting and fruitful for everyone involved. After the talk, the audience is expected to come up with at least a couple of questions for the speaker. If you are chairing the session, you must ask something if nobody else does.

Besides questions, other types of feedback can also be useful. But make sure you are not coming across as lecturing the speaker. And always resist temptation to talk too much about your own work.

If the speaker is a relatively junior member of your research community, and maybe their senior coauthor or supervisor is also present, when asking your question or giving your comment, resist temptation to address that more senior person you are trying to impress rather than the speaker standing in front of you. (And if you are that senior coauthor or supervisor, just sit tight and don't talk during any of this.)

Conventions

Before your talk, familiarise yourself with the conventions of the research community you are talking to (and possibly also the conventions associated with the specific event where you are presenting).

For example, in my own community (in AI), there will be someone chairing the session. You are expected to introduce yourself to them a few minutes before the talk. They are expected to introduce you to the audience before your talk. They will usually mention your name and the title of your paper. If you have coauthors, you are expected to mention them at the start of your presentation. If any of them are also present, it is nice if you point this out explicitly. At the end of your talk, people are supposed to clap, and then the chair will invite the audience to ask questions. So don't invite the audience to ask questions yourself. First, that would be (a little) rude towards the chair. And second, it will confuse the audience, as they won't know anymore when to clap. During the question period, the chair also gets to point out who is next to ask their question and the chair decides when the question period needs to end. Of course, every now and then you will run into a chair who hasn't read the Big Book of Rules themselves, and you may simply have to take over some of their tasks.