Explaining a paper or project at 2, 10 and 45 minutes

Why it matters

Thesis and internship interviews ask you to explain a paper or your own project, often at several depths in one conversation. Listeners judge understanding and judgment together: whether you know which result matters, what the limitations are and what you personally did.

Core ideas

The two-minute version. Five beats of one or two sentences each:

1. Problem: what fails today and for whom.
2. Why it matters: a number or consequence, not an adjective.
3. Key idea: the one insight, in plain words.
4. Evidence: the most important result with its condition ("on trace X at 70% load").
5. Limitation or open question, plus your role if it is your project. Test it on someone outside the field; if they cannot repeat the key idea, simplify.

The ten-minute version. Expand the same skeleton around one running example:

1. Context and problem through a concrete scenario (1–2 minutes).
2. Why existing approaches fall short: the specific assumption that breaks (1–2 minutes).
3. Key insight and mechanism, shown on the running example (3 minutes).
4. Evidence: one or two results with baseline, workload and uncertainty (2–3 minutes).
5. Limitations, next steps and a one-sentence takeaway (1 minute). One slide or whiteboard sketch per point is enough. Peyton Jones argues that a talk should make listeners want to read the work rather than replace it, so cover the idea and skip most details.

The 45-minute discussion. Here the listener steers, so prepare layers you can open on demand:

• motivation and a precise problem statement;
• the closest prior work and the assumption that differs;
• design alternatives you considered and why you rejected them;
• the mechanism in detail, with its correctness argument or invariant;
• the evaluation: setup, baselines and their tuning, ablations, variance, threats to validity;
• implementation lessons, failures and surprises;
• open questions and the next experiment. Prepare a whiteboard version of the core mechanism and one backup figure per likely deep question.

Questions to expect. What was the baseline, and was it tuned? Why not the simpler alternative? Where does it fail? How general is it? What is guaranteed and what is measured? What would you do with six more months? What did you do personally? Give the short answer first, then detail, and say "I do not know, but here is how I would find out" when that is the truth.

Attribution. For a paper, say "the authors"; for team work, say exactly what you owned. Inflated roles are exposed by two follow-up questions and cost far more trust than a modest role.

Numbers with context. "Three times faster" invites "than what, where, how often?". Give baseline, workload, statistic and spread in the same breath.

Common misconceptions

• "A longer explanation shows more understanding." Choosing what to omit is the skill being assessed.
• "Start with background and build up." Listeners need the problem and the punchline early or they cannot follow the details.
• "Slides full of details are safer." Dense slides compete with you; keep details in reserve for questions.
• "Admitting a limitation weakens the case." Naming limitations before being asked signals command of the work.
• "I built it, so I can explain it without preparing." Builders often dive into implementation and skip the problem and the evidence.

How to approach it

Pick one paper and one of your own projects. Write the two-minute script, the ten-minute outline and the 45-minute layer list, then record yourself at each length and check timing and every claim against your notes. Keep the scripts in the app's Project notes. Graduates are expected to be clear and accurate; senior candidates should also discuss alternatives and decisions made under uncertainty.