Skip to main content

Technical Paper Review and Presentation Template

A summary results from structuring, not merely reading. Record claims, evidence, and judgment separately.

This document provides a reusable template for reading an academic paper, organizing it into a review, and presenting it in a short talk. The reading stage is based on the three-pass method proposed in S. Keshav's How to Read a Paper (ACM SIGCOMM Computer Communication Review, 2007). Keshav's article concerns reading efficiency, however, not review structure or presentation design; the review sections and slide allocation below are original rules from this document. Do not confuse quoted guidance with added guidance. The template assumes a peer-reviewed conference or journal paper, but the same sequence also applies to technical reports and long-form preprints.

See the Hijacking Bitcoin review for a completed example using this template.

0. Define the audience and question first​

Reviews and presentations of the same paper take different forms for different audiences. Before reading, write one sentence for each of these points.

  • Audience: What do listeners already know, and what do they not know? This determines the depth of background explanation and what can be omitted.
  • Question: Can you state the question the paper answers in one sentence? Why should the audience care about that question?

If you cannot state the question in one sentence, you have not finished reading. Return to the reading stage instead of starting the review. Once those two sentences are fixed, they become the baseline for every later decision. Whenever you add a slide or paragraph, ask, "Does the audience need this to evaluate the question?" Remove unnecessary material from the talk and move it toward the end of the written review.

1. Reading: three passes​

Keshav's three-pass method is a procedure for abandoning the attempt to understand everything in one close reading. Each pass has a different purpose, so knowing which stage you are in also tells you what to record.

  1. First pass (overview): Scan the title, abstract, introduction, section headings, conclusion, and references to judge the paper's category, context, correctness, contributions, and clarity. Keshav proposes completing this stage within minutes; its purpose is not understanding but deciding whether the paper is worth continuing.
  2. Second pass (understanding the content): Skip proof and experiment details while focusing on figures, tables, and definitions to capture the main flow. At the end, you should be able to summarize the paper's core with supporting evidence.
  3. Third pass (reconstruction): Read as if you were deriving the authors' assumptions yourself. Look for unstated assumptions, missing citations, weaknesses in experimental design, and possible alternative conclusions. Most material for the review comes from this stage.

This procedure is a scale, not a mandatory rule. A short workshop paper may require only the second pass, while a reproduction effort turns the third pass into implementation work. Preserve one boundary: starting slides before the third pass often reduces the presentation to a list of summary statements. Critical material emerges only during reconstruction, so postpone the presentation until the reading is complete.

2. Review section template​

2.1 Paper identity and central claim​

Create a table listing the authors, venue and year, DOI or public source link, period covered by the data, and the central question in one sentence. Do not omit the data period because it becomes the baseline for discussing generalizability.

An author introduction is optional. Include it only when the authors' background affects how the paper should be interpreted, such as when they work for the manufacturer of the evaluated product, funding creates a conflict of interest, or context from follow-up research by the same group matters. Otherwise, spend presentation time on the central claim rather than biographies.

2.2 Required background​

Introduce only the minimum concepts the audience needs to evaluate the paper's claims. The goal is not to summarize related work. Every background item should answer, "Which claim cannot be evaluated without this?" Remove items without an answer.

2.3 Method, system, and data​

First show the entire structure at one level of abstraction. Then state separately what each component does and why the authors chose that design. For data-driven papers, specify the collection period, source, and scale. Mixing what and why makes the authors' design choice appear to be the only possible answer. If alternatives existed but the paper did not explain its choice, that omission belongs in the limitations section.

2.4 Evaluation design​

List the experiments, observations, and simulations used to evaluate the claims. For each one, record the question it tests, its comparison target, and its metrics. A key measure of methodological strength is whether the paper combines multiple kinds of evidence rather than relying on one experiment. When reading, reverse the question: which claim would collapse without this experiment? If a paper reports only peripheral metrics without directly testing its central claim, address that gap during interpretation rather than presenting the metrics as results.

2.5 Results, authors' interpretation, and reviewer's judgment​

Always separate these three layers.

  • Results: Values and observations reported by the paper, together with the conditions and period in which they were obtained.
  • Authors' interpretation: Conclusions the authors derive from those results. Put this in a separate paragraph from the results.
  • Reviewer's judgment: The scope the results actually support and where the interpretation runs ahead of them. Write this in the form, "This value establishes X, not Y."

2.6 Threats to validity and generalization​

List conditions under which the result may fail or differ. Common categories include limits to a measurement-time snapshot, inferred rather than directly observed data, false positives from heuristics, and changes in protocols or environments. Replace the question "Does it hold under other conditions?" with "What must be verified again for it to hold?"

2.7 Contributions​

State what the paper actually added using verbs: modeled for the first time, measured, implemented, or falsified. Classifying the kind of contribution before its magnitude helps prevent exaggeration.

2.8 Strengths and limitations​

Define strengths as what only this paper provides and limitations as what it does not answer. Evidence for strengths usually comes from inside the paper, while evidence for limitations comes from outside it—follow-up studies, environmental changes, or omitted baselines. A limitation is not an accusation; it is a boundary marker for the next reader.

2.9 Reproducibility check​

Check whether code, data, and artifacts are public, what the experiment depends on, and how its numbers can be reproduced. Do not stop at "not reproducible." State what is missing and which stage can no longer be verified because of it.

2.10 Further extensions​

Record possible extensions as questions. Good examples include asking which values would change if measured again under current conditions or which altered assumption would change the conclusion.

3. Slide allocation for a 15-minute talk​

A 15-minute presentation should use 12–14 slides and spend at least half its time on the method and results.

OrderTimeContent
11 minTitle, central question in one sentence, and why this paper matters now
22 minBackground—the minimum concepts needed to evaluate the claim
31 minProblem definition and central claim
44 minMethod—one overview slide and two or three component/design-rationale slides
52 minEvaluation design—data, experiment setup, and metrics
62 minResults—focus on values and include conditions and periods
72 minReviewer's judgment—strengths, limitations, validity threats, and bounds on generalization
81 minReproducibility status, further questions, and conclusion

If the background begins to exceed three minutes, the audience definition is wrong. When time is short, reduce the background and preserve the method. Measure and adjust the table's timings during rehearsal. If the session includes questions, place anticipated questions and evidence locations in backup slides after the conclusion, outside the 15-minute main talk.

4. Evidence ledger template​

Record every value and claim used in the review or presentation on one line. This serves two purposes: returning immediately to its evidence when a question arises, and preventing the authors' words from blending into the reviewer's judgment.

#Sentence used in the review or talkLocation in the paperEvidence typeNotes
1§3.2, Table 2, etc.Direct measurement / author inference / author assumption / external citation / reviewer calculationConditions and period

For entries classified as "author assumption" or "reviewer calculation," disclose that fact during the presentation as well. Bring the ledger to the talk. Checking the corresponding row whenever you cite a value prevents mistakes in conditions or periods caused by relying on memory.

5. Final review checklist​

Check each item from top to bottom before finishing.

  • Are the audience and central question each stated in one sentence at the beginning?
  • Is the paper-identification table complete with authors, venue, year, DOI, and data period?
  • Does every background item connect to a claim that cannot be evaluated without it?
  • Are results, authors' interpretation, and reviewer's judgment in separate paragraphs?
  • Does every value include its conditions and period?
  • Are threats to validity and the bounds of generalization explicit?
  • Is there evidence for every strength and limitation?
  • Do non-reproducible items state what is missing?
  • Are further extensions written as questions?
  • Does each value used in the talk correspond to one evidence-ledger entry?

References​