6 Tips for an Amazing Qiskit Hackathon Presentation
Authors: Vicente Pina Canelles, Yaiza García, Julien Gacon.
Hello, Qiskitters! At the end of every Qiskit Hackathon (like the one in Madrid, or as part of a Qiskit Camp), participants explain in a 3-minute presentation what they have been working on for the last 24 hours. This presentation can be a hard task, but fear not! Participants have proven over and over again that it is possible to convey your work in this presentation format. And it is very important to do so, since your presentation makes up for 25% of the judging criteria (and maybe even more, given that the other criteria rely on how well you communicate your work).
We are Vicente (Qiskit Advocate and judge in Qiskit Camp Asia), Yaiza (IBMer and coach in Qiskit Camp Asia) and Julien (IBMer, Qiskit Advocate and coach in Qiskit Camp Europe). We have also been participants in previous Qiskit Hackathons, so we know first-hand how hard it can be to condense 24 hours of coding in 3 minutes. Here’s some general advice that has helped us in the past.
1. Structure your talk strategically
Keep it clear and simple. Remember that there are no questions afterwards. We recommend dividing your presentation into four fundamental parts:
- Introduction: Don’t take for granted that the audience knows a single thing about your topic. Try to make your introduction as non-technical as possible, since Qiskit Hackathons are attended by a hugely varying audience: computer scientists, physicists, designers, artists, chemists, mathematicians, communicators and many more!
What is the problem that you are trying to solve? Why is it important? - Your work: Now, it’s time to explain what you did. Emphasize the parts that you find especially novel or creative. Maybe you developed a new algorithm or functionality, or used a method in a way no one thought of before…
How did you tackle the problem? What were your key ideas? Where did you struggle? Don’t be afraid to discuss troubles you encountered along the way. Did you overcome them? Or do you intend to solve them in the future? How? - Results: Keep in mind that even “bad results” are results. Possible solutions to unexplored problems must be studied sooner or later, and often they won’t be as useful as one may think beforehand. Did you think of a method to optimize a process and it turned out to not be better than the current one? Then you proved that the current method is good! Be realistic, but not pessimistic.
What did you see? Did you expect this? Why do you think this happened? - Future: So, you have been working on your project for 24 hours. Coaches and judges alike want to know how you will keep working on your project.
This information is crucial for IBMers who want to help you after the Hackathon is over, and also for the judges: the potential of your idea is a key point! Demonstrating how your ideas can be developed in the future can also be applicable to the “usefulness” category in judging.
What are the immediate next steps to take? How will the project scale in the future? Will it be able to solve more complex problem than the examples you used it for?
You might want to include a (very, very brief) summary at the very end of your talk in a few sentences: your initial problem and your final results.
2. Start working on your presentation early
Developing your project can get quite chaotic. To maintain structure in both your work and presentation, choose a team member to keep track of progress of your project as you all work on it. This person is then also suitable to write the introduction of your talk.
Just in case, collect data ahead, and don’t wait until you get the final results. You don’t know whether your “final” results will meet your initial expectations. Don’t rush your data collection just before the deadline. Plus, even the failing attempts can be part of the final story, so keep everything!
3. Write a script and stick to it
Write a script and rehearse, rehearse, rehearse! This has 3 key advantages:
i. You avoid leaving anything out. You don’t want to skip any small piece of information and spend the rest of the night banging your head against the wall.
ii. You avoid rambling. Talking too much is just as bad as coming up short. The explanations of your technical project should be as straight forward as possible. It is crucial that you fit everything into the limited time you are given. You will be cut off if you take too long!
iii. You minimize stuttering and fillers. Avoid filling your speech with “uh”, “well”, “so”, etc. while your brain is processing what to say next. It seems unprepared, unconvincing and it can take away a good chunk of your precious time.
4. Have only one speaker
The audience has a lot to process while you are giving your speech, which will probably be very packed. Let the flow of information be as simple as possible: don’t switch speakers during the presentation. Ideally, your speaker should be the most vivid, outgoing and clear-speaking person of your team.
If you really want to have more than one speaker, make the transitions between them as seamless as possible. Put special attention to this moment when practicing. Each speaker must present separate sections in order to keep things tidy.
5. Watch your text to image ratio
Try to keep the content of your slides minimal. Your audience should listen, not read. Generally, keep the following points in mind:
- Mathematical formulae can be scary and dense. It is better to explain the phenomena behind the equations.
- A lot of text can be cumbersome and distracting. It is better to use graphs and images to support your talking points.
- If you include graphs, make sure that the data they represent is clear (labelled axes, large enough labels and a title).
6. Get creative with your format
Don’t be scared to stand out. You can be quirky and fun (without undermining your technical achievements). After all, it’s a Hackathon: if it fits the tone of your project, be creative! A wonderful example for how to pep up the presentation is Quantum Duel, from Qiskit Camp Asia 2019: by clicking on the link, you can see the trailer that they filmed during the event and included at the beginning of their presentation.
Also, demos are a great way of showcasing a project! However, they can suffer the dreaded “demo effect” and, while everything may work fine during practice, it might go south when doing it live. We advise you to record the demo in order to keep it bug-free and within a very specific time limit.
A final example
Remember that everything we have said so far are just very general guidelines that we personally have found useful in the past. They may work for you, or they may not.
Below is an example of a fantastic presentation. In fact, this group, “Designing a pulse programming language”, were the winners of Qiskit Camp Asia 2019:
