As promised, here is the post on what I expect from your presentations. At the end of the post, I’ll give a structure I expect you all to follow but before that I’ll throw up other advice which should be useful to you in the future whenever you give talks. (There are tons of great advice on the web on how to give good talks and how to manage your academic/research career in general. Here are some of them: Terry Tao‘s post, Lance Fortnow‘s post and Michael Ernst‘s page. They also have great career advice pages.)

**Two Warnings:**

- I’ll focus on theory talks. While many of the points below will be valid for almost any talk, some of the points below are tailored to CS theory talks.
- All of these are my personal opinions. As with any opinion, they need not be universally applicable: please use your judgement in picking the ones you think makes sense and/or work for you. The opinions have their basis in my personal experience, which might or might not be applicable in your personal case.

Comments are more than welcome. Please use the comments section and/or email me.

First, let me begin with some high level comments about talks. I’ll try to substantiate my comments with my personal experience wherever possible.

- (
**Treat every talk as your job talk**) Some fresh graduate students tend to think that producing good research results is the only important thing. While producing good results is very important, you should not neglect the importance of giving good talks. A good job talk will not guarantee you a job but a bad one will definitely not get you one. Second, you might think that you have to really work hard*only*on your important talks like the job talk. First, any external talk is important because when people hear a good talk they remember the speaker. This can only help you later on. Second, even an “internal” talk like a class presentation should not be taken lightly. Giving good talks is hard (see #24 below) and one cannot become a good speaker overnight. The good habits come about over time and with practice, so whenever you are giving a talk, treat it like a job talk! - (
**Purpose of your talk**) The aim of your talk it not to wow your audience with lots of math symbols and/ or very complicated math wizardry. Instead your goal is to wow your audience without them realizing it: your talk should be so understandable that your audience thinks whatever you are saying is very natural. Your job is to make your audience feel good about the fact that they understood your talk. - (
**Whose fault is it?**) A common misconception with new graduate students (and this was true for me) is that they tend to think that it is their fault that they cannot understand a talk as they do not have the necessary background etc. While there might be some truth to this assumption, it is mostly the fault of the speaker! As a corollary, when you are giving the talk do not assume that your audience has the necessary background. Paraphrasing a quote from a James Bond movie (I think),**assumption is the mother of all screwups**. It is worthwhile spending some extra giving an overview of the background. In almost all cases there is only one expert on the topic in the room: you. Even if there is another expert 99% of the time, they will be grateful for a quick brush-up of the basic concepts. - (
**Cut to the chase**) As a rule of thumb, you should have told your audience why they should not zone out for the rest of your talk. This means two things: (a) You have to motivate why your problem is interesting and (b) You have to tell them what your result is. A rule of thumb:**you are not doing a favor to the audience**by giving the talk rather they are doing you a favor by attending. - (
**Decide what you want to tell them**) A common mistake in talks is to try and tell your audience as many of your main results as possible. This is a mistake. I have done it many times, especially as a younger graduate student. You don’t realize how bad this practise is unless you attend a similar talk by someone else and then you come out of the talk with the feeling that you did not understand anything. You should**pick****one result**(or maybe two in the worst case) and focus in it. As good rule of thumb on how to pick on that one result: think of which one result you want your audience to know most about and pick that one. - (
**Treat your audience as if they have the attention span of a fly**) OK, the sentence is a bit too harsh :-) However the spirit of the statement is not: do not assume that you audience is paying full attention to your talk. (E.g. see this blog post by Luis von Ahn.) Most of them will zone out at some point or the other. Given them an opportunity to get back into the flow by making your talk non-linear. That is, either start something new or repeat the overall picture and where you currently a few times in your talk. - (
**Top-down approach**) One way to implement hooking back your audience is to follow the top down approach. In other words, you should present the same idea at different levels of detail throughout your talk. For example, if you are presenting a proof, first give a high level idea of how the proof works. Then present the statements of the main lemmas and use them to prove the main theorem. Then move on to proving the lemmas. Another advantage of this modular approach is that if you are running over time, you will end up not covering the most detailed part of the proof but that is OK since your audience at least has some idea of how the proof works. (Contrast this with the approach of stating the lemmas one by and one and proving them and then finally proving the theorem. If you run out of time while proving one of the intermediate lemmas then your audience goes away without having any idea as to why your theorem is true.) - (
**A figure is worth a thousand math symbols**) Instead of proving a theorem as you would in a paper, try to prove it by using as many figures as possible and as few math symbols as possible. Humans tend to understand pictures better than text and most of the time, figures are enough to present the main idea(s) in the proof. Don’t try to fill in all the details– if your audience is interested in them they can talk to you offline and/or read the paper. This suggestion was first made to me by David Zuckerman when I was a first year grad student. Then I thought it was all baloney but over the years I have come to appreciate the soundness of the advice. (Again attending talks which have lines after lines of math text and you come out without any understanding of the result helps you appreciate this advice.) - (
**Prove weaker statements**) Try to prove a weaker version (or a special case) of your main theorem that captures the essence of the theorem in terms of the main ideas/concepts. (This again is another Zuckerman mantra that at first seemed very odd to me.) Doing so helps you get your ideas across better without getting bogged down in the details. Again, if the audience is interested in the exact form of the theorem they can read up the paper. As a corollary,**use as few definitions as possible**. Some people can keep more than 3-4 definitions in their heads during your talk but I have come across maybe one or two people who can do it well. If you have to use many definitions, it is always a good idea to remind your audience about a definition a few times. Using figures can sometimes help you do away with some of the definitions. - (
**Choose carefully what you prove**) There are gazillions of interesting statements that you can prove. However, you have limited time to prove things. Hence, pick carefully what you want to prove. Your aim should be to give your audience a taste of the most interesting technical/conceptual part of what you are presenting. Not presenting routine calculations is a good first step. If the calculations have something interesting in them, you are still better off giving a gist of what is interesting about the calculations without going into too much detail. - (
**Slides vs. the board**) Giving a talk on slides vs presenting it on the board has its advantages and disadvantages. As a rule of thumb, doing a proof on the board is better (as you go over it slowly) and slides are good for background stuff. Slides are better for short talks (e.g. 20 minutes conference talks) when you have a strict time constraint. However, for say an hour long talk, it might be worthwhile to give a talk on the blackboard– a talk based on slides typically goes much faster than one on the board. Ideally, using a mix is the best but you might not have the choice to do so. - (
**Math needs its own color**) Use different color for text and math in your slides. This is especially useful if you are giving a talk in a long room: the folks at the end of the room will thank you, or at least I will if I’m attending your talk :-) I don’t know why this works well: maybe we are trained to not read all of the text in front of us so different color helps the audience refocus on the math (English language is an error-correcting code while math language is not). Some of my personal favorite color schemes for math: magenta for math and black for text on white background or yellow for math and white for text on black background. - (
**Choose your colors carefully**) Be careful when you pick different colors in your slides. Something that looks good when you’re a feet or two away from the screen does not look that good from afar. When deciding on a color, try different options and walk back 10 feet or so to see what works best. One of my personal findings: light green (esp. curves on a plot) with white background does not work well. Sometimes projectors mess up your colors even more, so avoid close by colors when you’re using them to signify different things (e.g. dark blue and black curves in a plot can be hard to distinguish). - (
**Use a plain background**) Use slides whose background is just one color. Having designs in your background is distracting– it’s harder to read what is on the slide with a background image. - (
**Powerpoint vs. Beamer**) Slides in LaTeX (via programs like beamer) typeset math beautifully. Powerpoint has add ons that allow you to use LaTeX in the slides but the output is definitely inferior. On the other hand, making figures (and animation– more on the latter in the next point) is much easier on powerpoint. Given this, I prefer powerpoint (see #8 above). The fact that it is hard to write too much math in powerpoint forces me to use figures and/or plain english, which is always easier for the audience to follow. - (
**Animation is a double-edged sword**) It is easy to get carried away with animation and have things flying in and out of your slides. In fact, a few years ago these bells and whistles were the rage. Thankfully this “trend” has died down. Animations are good but only if you use them wisely. In general I find them useful in the following two contexts (a) When you are talking about an object that changes over time, e.g. how an input graph changes when you apply your algorithm on it or (b) When you going through the steps of a proof. - (
**Use at most 10 words per slide**) This is a hard rule to follow so try to approximate it as much as possible. People have not come to your talk to see if you can construct complete grammatically correct sentences. Write incomplete sentences.**Use big fonts**: this is especially crucial when you’re giving a talk in a big room and people at the back will not be able to follow smaller fonts. Do**not use sentences that take up more than one line**. - (
**Pseudocode of an algorithm is a no no**) A common mistake: flashing up the pseudocode of an algorithm. It does not help your audience especially if the pseudocode is the first thing they see about your algorithm. First try to explain your algorithm through figures if possible (see #7) . If not, use English to explain your algorithm. - (
**How much should you control your slides**) As far as I can tell there are two camps wrt to how folks want to see proofs: the first camp likes the speaker to put up the entire slide so that they can understand what is going on on their own. The second camp wants the speaker to explain to them what is going on (and hence, only show what is necessary). My advisor is in the first camp while I am in the second. This is one of the few things we disagree on :-) - (
**Know your audience**) The level of detail you can go into depends on the composition of your audience. If it all experts then you can give more details and spend less time on the background. However, a**conference talk audience is not an all expert audience**. Sure, there will be some experts in your talk (after all they should be the ones who are interested in the talk). However, some (most?) of your audience will have a passing interest in your talk and you should make sure that you do not alienate those folks by tailoring your talk to the few experts in the audience. - (
**Jokes**) Cracking a good joke in the middle/beginning of a talk is a good tactic to get your audience’s attention (and sometimes to give them a break after an especially technical part of your talk). However, use jokes that are (at least) somewhat relevant to your talk. Also use jokes somewhat sparingly: after all you are not doing a stand up. (Though some people can pull off the latter.) At the end of the talk, your audience should remember the results/technical part of your talk and not just the jokes :-) - (
**Practice makes a human perfect**) No matter how much time you have spent preparing for your talk,**your first talk is going to be bad**. Hence, it is in your best interest to make sure that your first talk is a practice talk and not the final thing. Ideally, you should get people to come to your practice talks and give comments.**This is a must for your job talk**(in fact for job talks you should get folks from*outside*your area). These are important because many a time what you think is clear in your talk will not be so to your audience. In most cases you would have dealt with the material for much much longer than your audience and something that is “obvious” for you will not be so for your audience. Even if you cannot give a practice talk to other folks, it is still useful to give a dry run in an empty room: at the very least you will notice things that disrupt the flow and this will minimize the awkward um, ah type jerkiness in your actual talk. - (
**Go over your slides/notes just before your talk**) This way all the stuff will be current in your brain and the familiarity helps in giving a smooth talk. - (
**Giving a good talk is hard work**) You have to put in a lot of effort to make your talk understandable. Speakers tend to take the easy way out and just club together a talk but it never works well for anybody. If giving good talks were easy everyone would give great talks! Hence, start as early as possible. If you have not given many talks before, you should start working on your talk at least 2-3 weeks before your actual talk (for job talks it should a minimum of a month). As you get more experienced you can afford to cut it closer to the actual date but more time is always better. - (
**Improvement will not happen overnight**) It is not reasonable to expect that one can acquire all the good speaking qualities at the flip of a switch. Improving your speaking skills takes time. This is more the reason to try and improve all the time. The best way to do this is to try to follow as many good practices as possible in*all*your talks, irrespective of its “importance.”

Finally, here is the structure I expect from your paper presentations in May:

- (
**Motivation**) You have to motivate why the paper/problem/question you are talking about is interesting. Not motivating your talk is as good as not giving the talk at all. - (
**Connect your talk to the course**) Tell us why the material you are presenting is related to the course. This generally should be an easy and quick thing to do but this is essentially more motivation for your audience to listen to your talk. - (
**Connect to related work**) The results in the paper have not been obtained in vacuum. However, you can spend all your time talking about related work. Thus, pick the closest couple of related work and mention them. As a rule of thumb, you should not be spending more than a couple of minutes on related work. - (
**Focus on one result**) You will probably have multiple interesting results. Pick the one that you find most interesting and focus your talk on it. If you have other interesting results, you can mention them at the end of the talk but do not spend much time on them. Think of it this way: if you were allowed to pick just one result from the paper and then the rest of the paper will be wiped off from the consciousness of mankind, which result will you choose? - (
**Use top/down approach**) See #7 above. - (
**Present at least one non-trivial proof**) You will have 50 minutes for your talk, which means you will have time to present at least one proof. (Also see #10 above.) Since this is a class presentation, in most cases, your audience will have some required background. This should allow you with ample time to present a proof. - (
**Give multiple versions of the proof**) This is an incarnation of the top/down approach: first present a very high level view of the proof. Then present the main steps of the proof and who they interact with each other. Finally, fill in the details of the proof. - (
**Repeat the high level picture**) Repeat your motivation/motivating question a few times in the talk so that the audience remembers them.

Finally, it is your choice of whether you use slides or the white board for your talk: Bell 242 has both options available.

**Epilogue.** As JD, pointed out in the comments section, I don’t always necessarily follow all the advice above in my lectures. It is certainly my fault. (I try to follow all my advice but sometime bad habits creep back in, which is why feedback is very useful. Thanks JD!) Actually, this is more of a reason for you guys to follow the stuff above– you have seen how bad it gets when I did not follow the advice above!

Great advice on preparing the talks! Mostly applies to math too!

By:

Academic Career Linkson April 5, 2009at 7:29 pm

[…] Posted in presentations, spr09 by atri on April 6th, 2009 I wrote down a guidelines/advice post for the presentations in my coding theory course. Please follow the guidelines while preparing for […]

By:

Presentation guidelines « Expanders, Property Testing and the PCP theoremon April 6, 2009at 11:39 am

So, how much of a paper do we actually have to make? Do we hand anything in?

On a side note, I would have loved some more of that “(A figure is worth a thousand math symbols)” in class…

By:

JD Hedeon April 11, 2009at 1:11 pm

So, how much of a paper do we actually have to make?I don’t really understand the question: What you mean by “making” a paper? If you meant how much of the paper you should present, it is up to you. As long you present one proof that says something non-trivial, I’ll be happy.

Do we hand anything in?No, no report is need: just give the talk. (Unless you’re doing a Wikipedia entry on the same topic in which you of course should hand in the wikipedia entry.)

On a side note, I would have loved some more of that “(A figure is worth a thousand math symbols)” in class…Touche! I do try to use as many figures as possible during lectures and I’m always trying to improve this aspect of my teaching. However, sometimes the proofs are just calculations in which case figures can’t help much. In a class, there is more time so it makes sense to go through the calculations. In a presentation there is severe time limitations and hence, one is better off doing little (if any) calculations.

By:

atrion April 11, 2009at 2:48 pm

can you send me some sample paper presentions on my email id please

By:

SANTOSH PANDEYon August 17, 2009at 9:36 am

Santosh,

I unfortunately do not have paper presentations that I can email. However, I’ll try to illustrate some of the points above with sample slides over time.

By:

atrion August 17, 2009at 12:01 pm

can u please send pattren of paperpresentation !!!!

By:

adityaon August 26, 2009at 7:31 am

Thanks so much! Im actually reporting and not presenting a paper although its pretty much called paper presentation in my college and this post guided me through all the aspects I wished to be clear about!!

Kudos!

By:

Adityaon November 10, 2009at 1:23 am

you’re welcome.

By:

atrion November 10, 2009at 12:45 pm

Nice tips to present a paper

By:

downloadpptson December 15, 2009at 2:28 pm

“Guidelines for paper presentations | Error Correcting Codes: Combinatorics,

Algorithms and Applications” victoria-fan was in

fact a terrific post. However, if it had a lot more pictures this should be perhaps even better.

Thank u ,Shani

By:

Christion February 27, 2013at 11:08 pm

U truly put together several superb points inside your posting, “Guidelines for paper presentations | Error

Correcting Codes: Combinatorics, Algorithms and Applications”

Sliding Panel Tracks . I’ll end up coming back to your web-site soon. Thanks a lot -Cathern

By:

yahoo.Comon March 23, 2013at 6:06 pm