Quiz — Chapter 31: Delivering Technical Presentations
Target: 70%+ before moving on. Answers are hidden — attempt each before expanding.
Section 1 — Multiple Choice
1. You have a 20-minute slot. Roughly how long should the talk you rehearse run, and why?
- A) Exactly 20 minutes, to use all your time
- B) About 18 minutes (~90%), because live talks run longer than rehearsal
- C) About 15 minutes, so you have lots of Q&A time
- D) However long it naturally runs; timing is rigid and unhelpful
Answer
**B.** Aim for ~90% of the slot. Live, talks run *longer* than in rehearsal — asides, repeats, clicker lag, demos, and latecomers all add time and none subtract it — so a talk timed to fill the slot exactly will run over, which forces you to be cut off or steal the next speaker's time. The 10% buffer absorbs what real rooms consume. (A) ignores live time inflation; (C) over-corrects and may waste your slot; (D) abandons the discipline that protects your conclusion. See 31.2.2. What is the single most reliable way to measure how long your talk actually runs?
- A) Read the slides silently and time yourself
- B) Estimate one minute per slide
- C) Rehearse out loud, on your feet, with a timer
- D) Count your words and divide by 130
Answer
**C.** Speaking aloud is the only true measure — you read three to four times faster than you speak, so a silent read (A) badly underestimates spoken length. (B) is a rough sanity check from [Chapter 18](../../part-03-academic-scientific-writing/chapter-18-conference-presentations-posters/index.md) but isn't a substitute for timing the real thing. (D) is too crude (pace varies, demos and pauses aren't words). Out-loud rehearsal also surfaces tangled sentences and weak transitions a silent read hides. See 31.2.3. Which delivery mode do most strong technical speakers use?
- A) A full script, read aloud verbatim
- B) The entire talk memorized word-for-word
- C) A keyword outline (structure cold, a few scripted sentences, the rest improvised)
- D) No preparation; pure improvisation for authenticity
Answer
**C.** Know the *structure* cold, script only the load-bearing sentences (hook, key transition, takeaway), and generate the rest live from a keyword outline or your slide headlines. (A) sounds stilted (written ≠ spoken register) and kills eye contact. (B) sounds recited and is brittle — lose your place and you have nothing to fall back on. (D) is not a real option for technical content. See 31.3.4. According to the cognitive-reappraisal approach, what should you tell yourself when you feel the physical surge of nerves before a talk?
- A) "Calm down and relax"
- B) "I'm excited"
- C) "Nobody is really watching"
- D) "Just get through it"
Answer
**B.** Relabel the arousal as *excitement* rather than trying to suppress it. Anxiety and excitement are both high-arousal states with nearly identical physical signatures, so reinterpreting the energy you already have is easier and more effective than fighting it ("calm down," A — which tends to backfire and adds meta-anxiety). This is a Tier 2 attributed finding from reappraisal research, presented as a well-supported technique, not an iron law. See 31.4.5. A questioner asks something you genuinely cannot answer. What's the best response?
- A) Make your best confident guess so you don't look unprepared
- B) Say "I don't know" and move on quickly
- C) State the limit, connect to what you do know, and offer a reasoned next step (bridge)
- D) Redirect to a different question you'd rather answer
Answer
**C.** Use the bridge: state the limit → connect to what you do know → offer a next step. (A) is bluffing — experts detect it instantly and one bluff destroys your credibility on everything else. (B) is honest but wastes the chance to show command of the surrounding material. (D) is evasive and the room notices. "I don't know, but here's how I'd find out" reads as competent and honest. See 31.6 (and [Ch 18](../../part-03-academic-scientific-writing/chapter-18-conference-presentations-posters/index.md)).6. The single most important precaution for a live demo is:
- A) Practicing the demo many times on your own laptop
- B) Having a backup recording of the demo working
- C) Using the fastest available internet connection
- D) Keeping the demo very short
Answer
**B.** Always have a backup recording. Most demo failures come from the *environment you don't control* at the venue (hostile Wi-Fi, projector resolution, missing dependency, third-party API outage), so practicing on your own laptop (A) doesn't protect you — "works on my machine" is exactly the condition that won't hold. A recording converts a catastrophic live failure into a five-second detour. (C) and (D) help but don't save you when the network or equipment fails. See 31.7.7. In a virtual presentation, what should you fix first?
- A) Your background and lighting
- B) Your slide animations
- C) Your audio
- D) The length of your talk
Answer
**C.** Audio first. Audiences forgive mediocre video but not bad sound — muddy or cutting-out audio makes you literally not understood, and people drop off within minutes. The others matter (and you should shorten and fix lighting), but if you fix only one thing, fix the audio. See 31.8.8. To make "eye contact" with a virtual audience, you should look at:
- A) The participant grid of faces
- B) Your own thumbnail video
- C) The camera lens
- D) Your slides
Answer
**C.** Look at the camera lens. When you look at the on-screen faces or your thumbnail (which sit *below* the lens), you appear to everyone watching to be looking down and away — disengaged. Looking at the lens feels unnatural but reads as direct eye contact. Put your notes and participant video as close to the lens as possible. See 31.8.9. A speaker feels an "um" coming mid-sentence. The best in-the-moment move is to:
- A) Push through and say the "um" — everyone does it
- B) Mentally chant "don't say um" before every sentence
- C) Close their mouth and pause silently for that beat
- D) Speak faster to get past the gap
Answer
**C.** Replace the filler with a pause — close your mouth and be silent for that half-second. The silence is invisible to the audience as a flaw and actually reads as composed and deliberate, so you trade a credibility leak for a credibility signal. (B) adds self-monitoring load that usually *increases* disfluency and anxiety. (A) is fine in small doses but a dense stream erodes credibility. (D) makes things worse. Build the habit by recording rehearsals. See 31.5.10. How should you open a technical talk?
- A) Title slide, your name and role, and an agenda of what you'll cover
- B) A hook that opens a loop (a problem, surprising number, scene, or question)
- C) An apology for any rough slides and a note that you put it together quickly
- D) A long thank-you to the organizers and the audience
Answer
**B.** Open with a hook that earns attention in under a minute, *then* give a one-sentence roadmap, *then* (briefly) your name/housekeeping if needed. (A) is throat-clearing — the audience reads the agenda off the slide and gets no reason to care. (C) lowers their estimate of your talk before they've judged it (never pre-apologize). (D) wastes your most valuable seconds. Beginnings are disproportionately remembered. See 31.1.11. You're behind schedule with five minutes left and three points to go. What do you do?
- A) Speak faster to fit everything in
- B) Skip your conclusion and stop when time runs out
- C) Cut a body point (planned in advance) and protect your conclusion
- D) Ask the chair for more time
Answer
**C.** Cut content, never race — and *always* protect the conclusion (your most-remembered 60 seconds). Cutting a planned body point keeps your pace calm and your close intact. (A) wrecks comprehension and sounds panicked. (B) sacrifices the most important part. (D) is usually not granted and steals from others. This is why you plan cut points in advance. See 31.2.12. A hostile questioner challenges your work with a clearly aggressive tone. The room is watching. Your priority is to:
- A) Defend yourself forcefully so you don't look weak
- B) Match their energy to show you won't be pushed around
- C) Stay even, extract the legitimate core, and answer the substance — not the tone
- D) Refuse to answer and move on
Answer
**C.** Separate substance from tone and answer only the substance, calmly. The room judges *how* you handle it more than *what* you say; composure under pressure wins the audience to your side, while getting defensive (A) or matching the hostility (B) loses the room *even if you're right*. Most hostile questions wrap a real point in attitude — extract and address it. If the asker keeps pushing argumentatively, close gracefully and offer to continue offline. See 31.6.Section 2 — True/False with Justification
State true or false and explain why.
T1. "If my slides are excellent, my talk will be excellent."
Answer
**False.** The deck and the talk are different artifacts (the chapter's threshold concept: the talk is the performance, not the file). A great deck does not deliver itself — you can click through beautiful assertion–evidence slides and still lose the room by reading them, monotoning, rushing, or skipping the hook. Delivery — structure, pacing, presence, rehearsal — is a separate, learnable skill that the deck does not supply. See 31.1.T2. "Reading from a carefully written script produces a better talk than speaking from a keyword outline, because the script's sentences are more polished."
Answer
**False.** Sentences crafted for the *eye* sound wrong to the *ear* — too long, too formal, full of clauses — and read aloud they sound recited, which (plus the lost eye contact) signals "doesn't know the material." A keyword outline forces you to generate sentences live in natural spoken register, with emphasis, pauses, and eye contact, so the audience experiences a person explaining rather than reading. The slightly less polished sentence spoken naturally beats the perfect sentence read woodenly. See 31.3.T3. "A deliberate pause after an important sentence is dead air that makes you look unprepared."
Answer
**False.** The pause is one of the most powerful delivery tools. After an important point it gives the audience processing time (which they need and you don't feel), signals "that mattered," and projects confidence — only a speaker in control is willing to stop talking. It also replaces filler words. Silence feels terrifying on stage but reads to the audience as composure, not unpreparedness. See 31.5.T4. "If I've run my demo successfully many times on my own machine, I don't really need a backup recording."
Answer
**False.** Most demo failures come from the venue environment you *don't* control — conference Wi-Fi, projector resolution, missing dependencies on a borrowed laptop, third-party API outages, slow startup on unfamiliar hardware — not from your code. "Works on my machine" is exactly the condition that won't hold in the room. The backup recording is the highest-leverage prep you can do; it converts a talk-ending failure into a five-second detour. See 31.7.T5. "A virtual presentation is basically the same as an in-person one; you just deliver it over video."
Answer
**False.** Virtual is a different medium with its own failure modes. You lose the room's feedback and energy (so you must manufacture engagement and bring more energy than feels natural), you must look at the lens rather than the faces, audio becomes more critical than video, attention erodes faster (so shorten), and a pile of mechanics can break (screen sharing the wrong window, your connection dropping, codecs). The demo rules apply *doubly* because you can't walk over and fix anything. See 31.8.T6. "Apologizing for a weak slide ('sorry, this one's a bit messy') is just being honest and humble."
Answer
**False.** Pre-apologizing lowers the audience's estimate of your talk *before they've judged it for themselves* and signals low confidence. If a slide is bad, fix it; if you can't in the moment, present it without comment. Honesty about *substance* (e.g., a real limitation in Q&A) is a virtue; reflexive self-deprecation about your *delivery or slides* just undermines you. See 31.9.Section 3 — Short Answer
Two or three sentences each.
S1. Explain why "cut content, don't talk faster" is the right move when you're behind on time.
Model answer
Speeding up wrecks comprehension — the audience is already processing in real time at the edge of keeping up, and they can't rewind you — and it makes you sound panicked while slurring your most important sentences. Cutting a (pre-planned) point keeps your pace calm and your delivery in control, and signals mastery rather than failure. *Rubric: names the comprehension cost of speed AND the calm/control benefit of cutting.*S2. What is the "bridge" technique for answering a question you can't fully answer, and why does it beat bluffing?
Model answer
The bridge is: state the limit → connect to what you *do* know → offer a reasoned next step ("I haven't tested that, but the mechanism is region-independent, so I'd expect it to hold — I'd want to measure first"). It beats bluffing because experts detect a bluff instantly, and one bluff destroys your credibility on everything else you said; the bridge demonstrates honesty *and* command of the surrounding material. *Rubric: states the three-part bridge AND the credibility reason honesty wins.*S3. Name two concrete things (besides reappraisal) that reduce pre-talk nerves, and say why each works.
Model answer
Any two of: **rehearse until the structure is automatic** (most stage fright is fear of fumbling, so deep preparation removes the thing you fear); **arrive early and test everything** (surprises spike nerves; eliminating them is free calm); **breathe slow with long exhales** (nudges the nervous system toward steadiness); **plant your feet and deliver sentence one slowly** (the first 30 seconds of composure settle the rest, and the audience reflects your calm back). *Rubric: two valid items each with a mechanism.*S4. Why should you look at the camera lens, not the faces on screen, in a virtual talk?
Model answer
The faces (and your own thumbnail) sit *below* the lens, so when you look at them you appear, to everyone watching, to be looking down and away — disengaged. Looking directly at the lens is what reads as eye contact to your audience, even though it feels unnatural to you. *Rubric: identifies the geometry (lens above faces) and the resulting perception of disengagement.*S5. How does rehearsing a talk out loud map onto Chapter 5's writing process, and what is the talk's equivalent of "the first draft is supposed to be bad"?
Model answer
Rehearsing out loud *is* the draft-and-revise of a talk: the first spoken run is the rough draft (too long, rough transitions, stumbled sentences) and each subsequent run is a revision that cuts and smooths. The talk's equivalent of "the first draft is supposed to be bad" is that your first out-loud run will run over time and feel clumsy — and that's expected and useful, because it shows you what to fix. *Rubric: maps runs→drafts/revisions AND normalizes the rough first run.*Section 4 — Applied Scenario
Graded by rubric.
P1. Script a hook + roadmap, then handle a hostile question. You're giving a 15-minute talk to fellow engineers about a database migration your team completed that reduced query latency by 70% but required two weeks of effort and a brief planned outage.
(a) Write, verbatim, your hook (30–60 seconds, opens a loop — no "Hi, I'm…") and the one-sentence roadmap that follows it. (b) A senior engineer asks, with an edge: "A planned outage and two weeks of work for some latency? Seems like you over-engineered this." Write your delivered answer, separating substance from tone.
Rubric
**Hook (0–3):** Opens a loop with a problem/number/scene/question (the 70% gain, or the outage decision, or "what would you trade two weeks of work for?"); does *not* lead with name/housekeeping; spoken register. **Roadmap (0–2):** One clear sentence naming the talk's shape (e.g., "I'll show you why we did it, how we kept the outage to ten minutes, and what we'd do differently"). **Hostile answer (0–5):** (1) stays even, no defensiveness; (2) extracts the legitimate core (*was the cost worth the benefit?* — a real question, not an attack); (3) concedes the cost honestly (two weeks, an outage are real); (4) gives the specific benefit with scope ("70% latency drop that was timing out under peak load and paging us — worth it for *this* traffic; for a low-traffic service I'd agree it isn't"); (5) optionally offers to discuss further. **8–10 total:** ready. **Below 6:** review 31.1 (hook) and 31.6 (hostile Q&A) and redo.Scoring & Next Steps
| Score | What it means | Do this |
|---|---|---|
| < 50% | Core delivery model not yet solid | Re-read 31.1–31.3 (structure, timing, delivery mode), then retake |
| 50–70% | Partial grasp | Redo Exercises Part B (revise the weak openings, answers, recoveries) |
| 70–85% | Solid | Proceed to Chapter 32; try a recorded rehearsal (Exercises E1) |
| > 85% | Strong | Do the Deep Dive: watch and analyze a compelling talk's delivery (Exercises E3) and apply it to your portfolio talk |