## Tips for Giving a Talk

You can find a concise checklist version of this document [here (link)](https://docs.google.com/document/d/1SvIxRxWuPRhUIoe08WUTlWGHqY7eodXDtEvd79wB0YE/edit?usp=sharing).

<!-- ### What to include in your slides

- [W] Motivation: Start broad, why should we care about this problem, what are the prior work -- the kind of things people have studied, and the payoff -- so what if someone solves this?
- [W] Problem statement.
- [W/H] Core Result -- Tell people as soon as possbile what the core results/end goal of your talk are. What will you show.
- [W] Define everything you write down. It's ok (most time good) to be informal, but the essence of the definition should be captured. If possbile, draw a picture even if it is obvious.
- [W] Understand the idea of the paper. What's so innovative there? Challenging goal: What did they do new/innovative that other people in the past missed?
- [W] Assumptions: Tell all the essential assumptions, i.e., that are fundamentally used in the proof.
- (i) Are they reasonable assumptions?
- (ii) Where do they help?
- (iii) Do you need to present each of the assumption or are some assumptions just not important conceptually?
- [W] Your goal is NOT to present everything, nor to show off. Your aim is to make your audience understand/get a feel of a major concept, so you have to decide what to present and what to skip. That said, do not skip simple "sanity checks".

### What to keep in mind when peparing a presentation of a paper

- [H] Have a running example throught your talk. E.g., finding community size in a simple random graph, etc. Show what your theorem/definitions would mean in this particular example.
- [H] Try to workout a claim in a simple example, to help the audience do some sanity check of the claim/theorem.
- [H] Lots of pictures. Picture speaks a thousand words. Have lots of pictures in your proofs, and definitions to show whats going on.
- [H] Do not over-crowd a slide.
- [H] Spend a 1-2 minutes per slide at the least. Give people time to absorb information. Your goal is not only to finish the presentation in time, but also make your audience understand.

- [H] Don't present what you pretend to understand. If you want to present it anyway, just be upfront and say that you don't understand it but the authors claim so and so.

- [H] Present proofs as a story. Need the high-level picture of the proof. Tell the audience the high-level approach of the proof.
- (i) Break proof into parts. Step-by-step thinking
- (ii) Given proof summary both in the beginning and end
- (iii) For complicated proofs, always recall what we did in the previous step and what we are going to do next.
- (iv) Stitch everything together like a "story"

- [H] If possible, try to relate the proofs/techniques with what was done in the class.

- [H] Audience is not comfortable with the things you are presenting. Give them time, give them examples, and give them pictures.
- [H] When showing experiment, get a high-quality image from ArXiV source or zoom in and take a screen shot. Read out loud the plots slowly (and do not forget to label and read out the axes). Tell things like: lower the better, etc. Make your axes visible from distance.
- [H] The audience and questions are friendly. Be kind, and do not be dismissive/defensive. Engage with curiousity with the audience. Don't pretend to know what you don't. When asked a question, try to reason out loud. It's ok if you are wrong, but reason clearly.

[-----Setup-----][-----------------Story-----------------][-Conc-][----Future----]

--- -->

### Subject Matter: What questions should your presentation answer?
You should be able to answer these questions before you even start preparing your slides.

- What is the motivation for your problem?
- Start broad. What's the real-world context for this problem?
- Discuss prior work. What does your paper improve that the prior work lacks?
- Discuss payoff. What's the value gained from answering this question?
- What's the problem statement? Have a clear, simple, and rigorous problem that your paper is trying to solve.
- This can sometimes be subtle. Like "the prior work has an algorithm that's fast, but uses a lot of space. Can we find an algorithm that's not much slower but uses way less space?"
- What's the core result? To what extent does this paper resolve the problem statement?
- This is essential so that the audience knows where the rest of the talk is going to evetually end up. For example, if the goal is to solve a problem in $\log(\log(n))$ space, then the audience knows to pay close attention to space complexity the whole time.
- What's the core idea behind the paper's contribution? Challenging Goal: What clever thing did your paper do that the prior work did not recognize?
- Understand and critique the assumptions in the paper.
- Are the assumptions reasonable in the real world?
- Why do the assumptions help? Know the answer to this both intuitively and formally/mathematically.
- Do you need to present all of the assumptions, or are some of them not conceptually important?
- Many talks show theorem statements that say "XYZ is true if you make some weak assumptions". If these assumptions are not conceptually meaningful, this can be phrasing can be helpful to avoid overwhelming your audience.
- Which topics from the paper are worth presenting?
- Your goal is to make the audience understand the big-picture ideas from the paper.
- Your goal is **not** to present everything in the paper, **nor** to show off that you understand the paper. The goal is to make the audience understand.
- Simple examples or sanity checks are always nice, but sometimes it's not worth presenting 5 major theorems from a paper if the core concept underlying the paper is revealed from just one of those theorems.
- You can always mention the topics not covered in an "other results" header on your final conclusion slide.
- Is anything in the paper worth critiquing? The writers of the paper are human.
- What examples illustrate your answers to each of the above bullet points.
- All of the above points should be understood by your audience during your talk. Using examples can convey your answers quickly and effectively. You might not present an example for each of these at the end of the day, or you might use the same example to answer many of these, but it's important to have concrete examples at the ready.

### Structure of a Presentation: What should your presentation look like?
Once you've answered all of the questions above, you can move onto thinking about your concrete slides. While you are preparing your slides, keep all of the following pointers in mind.

#### The basic structure of what to include:
- Talk about **all** of the points from the "Subject Matter" list above.
- There is a broad structure your talk should follow:
- The first **10 minutes** of your talk should cover the following points. No less than 8 minutes, and no more than 12.
- The motivation for the paper. Start broad, compare to prior work, and discuss the payoff of your result.
- Explain a rigorous problem statment.
- Explain, at least informally, the core result from the paper.
- Then spend about **30 minutes** describing how the paper solves the problem.
- Then spend about **5 minutes** concluding and wrapping up.
- When giving a 20 minute talk, this becomes 5 minutes, then 12 minutes, then 3 minutes.
- It's vital to be able to describe the paper as a story. For instance, lecture 5 (starting from slide 20) is a story about similarity estimation:
- Notice that every bullet point below is a natural follow-up to the preceeding bullet point, and there's an overarching story that progresses how we think about this Shazam problem.
1. It starts with a broad motivation from Shazam.
2. It then describes one way to mathematically formalize this real-world problem.
3. From this formalization, a rigorous _problem statement_ is given by slide 21.
4. That transforms into a rigorous _goal of low-space_ on the top of slide 22.
5. Now, the introduction of Jaccard Similarity on slide 23 feels naturally related to Shazam.
6. Then some time is spent chewing on the meaning of Jacard similarity through examples, so the audience gets used to the definition.
7. We can then introduce the main player of the story (the minhash) with the goal that it preserves Jaccard Similarity.
8. etc ...

$\phantom{.}$

#### It's also important to follow good presentation habbits that make it easier for the audience to keep track of what is happening:
- Define everything your write down.
- Every symbol that appears (like $f$ or $\lambda$ or $\text{Oracle}$) should be defined.
- Sometimes it's better to be a bit informal, but the essence of the definition must be captured. A nice example is from Slide 8 of the Lecture 8 notes, where Chris defines $\alpha$-strongly convex and $\beta$-smooth for a one-dimensional function, and notes that a high-dimensional definition exists.
- Drawing a picture is good. For example, a helpful picture is shown on slide 12 of Lecture 8.
- Be formal at the right times:
- Be mathematically rigorous when **stating the problem** you solve.
- In theoretical CS, people think a lot about edge-cases. By being rigorous here, people know exactly what are the right edge case to consider.
- If someone doesn't understand the problem, they won't understand the solution.
- If you want to avoid giving too
- Give only the **vibes of the proof**.
- If someone wants to understand every mathematical detail, they can read the paper.
- The audience wants to understand the *idea* of how the problem is solved. Vibes only.
- Use examples in your talk, as much as reasonably possible. Ideally:
- Have a running example throughout your talk.
- Show how all of your definitions and theorems relate to your example(s).
- Draw a picture; examples can often be made visual.
- Chris does these all of the time. For instance, look at how Lecture 5 uses basically the same bitstring for all of the minhash analysis, or at the non-convex picture demonstrating the theorem statement at the bottom of slide 20 of Lecture 8.
- To reiterate from the above: use lots of pictures. They each speak a thousand words.
- Spend *at least* a minute or two per slide. Give people time to absorb the information on screen. Your goal is not really to finish a presentation, but instead to make your audience understand a cool idea.
- Do not overcrowd a slides. The audience will want to read every word on every slide, so make sure it's easy to read everything while listening to the speaker talk.
- Do not use **any** screenshots of the paper
- Figures from the paper are OK
- No text or theorems are allowed
- Rewrite it yourself, with your own notation, and make sure the audience can easily read the slides at a glance.
- Do not present what you pretend to understand. If you want to discuss it anyways, be upfront about it. Say that you don't understand it, but that the authors make this claim.
- Present proofs as a story. Start by giving the audience a high-level outline of the proof. Ideally:
1. Break the proof into easier-to-reason-about parts. Step-by-step thinking.
2. Give a summary of the proof both before and after going into the details of the proof.
3. For proofs with many steps, always recall what we did in the previous step and note what we are going to do next.
4. Stitch it all into a story
- Going back to Lecture 5, we can see a story around the Chris analyzes minhash for locality sensitive hashing:
1. We first prove that an LSH table has the probability of two bitstrings landing in the same bucket be roughly proportional to the Jacard similarity of those bitstrings (slide 43).
2. But it has bad false negative rates, which is an issue because that means we don't actually find nearest neigbhors.
3. So we can create more tables, which will decrease false negative rates.
4. But this will actually boost fast positive rates, which is an issue because that means we spend too long looking in our buckets to find an neigbhor actually close to our query vector.
5. So we can create more bands, which will decrease false positive rates.
6. By controlling these two parameters (bands and tables), we can control both the false positive and false negative rates, resolving our concerns!
7. This ends the story of the analysis of minhash for LSH. The lecture moves on to other considerations and other ideas related to LSH.
- If possible, relate the proof or techniques to material from lecture.
- But, in general, assume that your audience is not comfortable with what you are presenting. They have never seen this topic before, and that's who you need to target your explanaitions towards.
- Give the audience time to digest ideas. Give them examples and pictures too.
- When showing experimental data, especially plots, use a high-quality image. On arXiv, you can go download the source LaTeX code of a PDF under the "Other Formats" butten, and extract a figure from there. Or, you can zoom into the PDF and take a giant screenshot. Whatever works.
- When showing experimental data, especially plots, read plots out loud.
- Describe what the axes are, including if they are linearly or logarithmically scaled.
- Tell us if "up is good" (eg accuracy) or if "down is good" (eg runtime) on the plot.
- Make your axes visible from a distance. You are presenting in a conference room with lots of people at the opposite end of the room. They need to be able to read every single letter and digit easily from back there.