Lesson 1 of 4 · 60 min
Design a ten-minute technical presentation
Produce a timed teaching script with a prediction, demonstration, and transfer check.
A short technical presentation tests selection. You cannot explain an entire platform in ten minutes, so choose one problem and one mechanism that the audience can understand and apply. Clarify who will watch, what they already know, what tools are allowed, and whether the assessment values live coding, teaching, or product demonstration.
Write the outcome as an action. By the end, the audience can predict when a repeated event should create another effect is more useful than the audience understands our platform. The action determines the example and the final check. Keep the product connection relevant, but do not turn every explanation into an unsupported superiority claim.
Allocate time explicitly. A two-minute problem setup, four-minute demonstration, two-minute failure case, and two-minute transfer discussion can fit a narrow mechanism. Leave room for questions by knowing which optional detail can be cut. A script that uses all ten minutes before the first result is fragile.
Show the mechanism in a visible artifact. A small event table or state trace is often easier to follow than a large code file. Explain each identifier and let the audience predict the result. Then run or trace the example and connect the result to the rule. Do not assume that a successful command communicates why the behavior is correct.
Worked example
A fictional interview presentation teaches duplicate delivery. The opening shows a customer receiving two notifications for one action. The input table has E1 twice and E2 once. The audience predicts the number of effects. The demo records event identity and produces two effects. The failure case restarts the process and reveals that an in-memory set loses its history.
The closing transfer asks whether two different purchases with equal amounts should be combined. They should not. The speaker explains that identity follows the business operation, not equal values. The product connection is a documented delivery contract and a path to a durable example, with no claim that every external side effect is exactly once.
Turn the interview brief into a contract
Before drafting slides, identify the audience, duration, permitted tools, required topic, and assessment purpose. A technical sales demonstration and a teaching presentation may use similar screens while testing different outcomes. A live-coding brief may require implementation during the session; a prepared talk may prioritize explanation and questions. Do not assume a fallback that satisfies one brief satisfies another.
code
1Presentation contract2Audience: developers familiar with HTTP, new to duplicate delivery3Time:10minutes including one transfer question4Outcome: choose the right logical identity and explain restart limits5Visible artifact: three-delivery trace plus one changed business case6Tool boundary: prepared local example; no live paid service required7Evidence boundary: local mechanism only, external delivery unverified8Optional cut: provider history and extended storage comparisonThis original practice brief is not an attributed company question. Cockroach Labs has published teaching and editing exercises for technical-writer interviews. Those are useful adjacent evidence that explanation can be assessed through artifacts, but they do not prove this DevRel presentation is currently used there or elsewhere.
Write the actual minute-by-minute script
| Time | Speaker action | Audience evidence |
|---|---|---|
| 0:00-1:00 | Show one action with repeated delivery | Can state the user problem |
| 1:00-2:00 | Define event ID versus business effect | Can identify the intended invariant |
| 2:00-4:00 | Ask prediction, then trace E1, E1, E2 | Predicts two effects under event-level rule |
| 4:00-6:00 | Show local state and restart limitation | Names what disappears |
| 6:00-8:00 | Change to two events for one purchase | Chooses business-effect identity |
| 8:00-10:00 | Answer transfer question and summarize limits | Explains what needs a stronger contract |
The table is not a mandate to speak without interruption. It shows where a question can replace optional detail. If the audience misunderstands identity at minute 2, use the next trace to resolve it rather than rushing ahead into storage architecture.
A prepared sentence can make a boundary clear: this local set remembers IDs only while this process runs; it does not coordinate another worker or confirm an external send. Then point to the state that disappears. Concrete evidence is easier to follow than saying distributed systems are hard.
Avoid a misleading product connection
If the presentation mentions a product feature, cite its documented behavior and distinguish it from the local simulation. A provider may support an idempotency key for one API but not every downstream side effect. Do not generalize one mechanism into a platform-wide exactly-once promise.
The purpose of a technical example is not to avoid discussing limitations. A limitation can be the strongest part of the explanation when it reveals the actual contract. Connect it to the next useful learning resource or verification, not a vague claim that the production version handles everything.
A nontechnical audience can still understand this model. Replace the code with delivery cards and a ledger, but keep the distinction between a message and the business action it describes. Removing syntax should not remove the invariant.
Rehearse the reasoning, not just the timing
A rehearsal should test whether another person can identify the rule without being prompted by your exact words. Ask them to explain the new purchase case in their own language. If they repeat a slogan but combine distinct purchases with equal amounts, revise the contrast.
Also test display readability, command visibility, and transitions between code and result. A correct snippet that is too small to read cannot support the explanation. Provide a text version of the input and output so learners can inspect it independently. Accessibility here serves the technical task rather than becoming decorative polish.
Misconceptions and a second exercise
One misconception is that a short presentation must omit failure to stay positive. Without the limit, the audience may apply the local mechanism incorrectly. Another is that a polished live result proves a causal explanation. The audience still needs to predict and explain a changed case.
Exercise: the brief changes to six minutes for engineers who already know at-least-once delivery. Allocate one minute to the exact invariant, two to the identity contrast, one to restart/external-effect limits, and two to transfer and questions. Cut the general messaging introduction. Award one point for using the changed audience knowledge, one for the six-minute sum, one for retaining the boundary, and one for a transfer check.
Your finished script should be short enough to adapt but precise enough that the technical claim remains stable under questions. The interviewer's changed constraint becomes a chance to demonstrate selection and understanding rather than a reason to speak faster.
Exercise and solution
The interviewer cuts the session to six minutes. Revise the script. Preserve the problem, one visible trace, the restart limitation, and the transfer question. Remove optional API history and extra code details. Award one point for the core mechanism, one for keeping the limitation, and one for a final understanding check. A shorter sales pitch without technical evidence does not meet the stated outcome.
Interview probe and wrap-up
How would you adapt for product managers rather than API engineers? A strong answer changes assumed knowledge and examples while keeping the same accurate causal model. Follow up with a mixed audience. A weak answer only removes code and replaces it with vague claims. A strong short presentation leaves the audience with one reliable model and enough evidence to test it in a new situation.
Sources
docsGitLab Developer Advocate rolehandbook.gitlab.comdocsGoogle technical writing: audience and documentsdevelopers.google.comdocsCockroach Labs published technical-writer interview exercises, adjacent-role evidencegithub.comdocsDiataxis documentation formsdiataxis.frCheckpoint
An interview asks for a teaching presentation rather than a product overview. Which brief best directs preparation?
AList every feature that can be demonstrated within the time limit.BChoose a runnable demo first, then infer the audience's prerequisites from the code it uses.CState what this audience must be able to explain or do, and what evidence will assess that action.DOrganize the talk by API endpoint, with completion defined as covering the endpoint list.
Sign up free to answer and see whyCheckpoint
The audience already understands delivery retries and the talk drops to six minutes. Which cut preserves the identity-learning objective?
AShorten known background while retaining the identity contrast, failure boundary, and transfer check.BKeep the background and replace the trace with a statement that the library handles duplicates.CKeep the full code tour and move the only independent prediction to unobserved homework.DKeep both success traces but remove the restart limit because this run does not restart.
Sign up free to answer and see whyCheckpoint
A provider documents idempotency for one endpoint and a finite key-retention window. Which claim can a speaker safely make?
AThe same key prevents repeated effects on every endpoint because the provider uses one account.BA successful retry establishes the guarantee after the documented retention window too.CA local set is enough to show the provider will bind its external effect atomically.DThe documented guarantee is limited to the named operation and window; other effects need separate analysis.
Sign up free to answer and see whyCheckpoint
During rehearsal, the audience gets the repeated-ID total right but merges two distinct purchases with equal values. What does the next revision need?
AMore repetitions of the same worked answer without changing the identity case.BA contrast that holds amount constant while changing purchase identity, followed by a fresh explanation check.CA longer code listing that leaves the effect invariant implicit.DA faster demonstration so the audience sees more successful outputs.
Sign up free to answer and see whyCheckpoint
The brief is for support engineers who diagnose API calls but do not implement handlers. Which adaptation best fits that audience?
AReplace the mechanism with product benefits because the audience does not write handlers.BKeep the original code-first path and infer programming prerequisites from seniority.CTeach every programming prerequisite before showing the supplied failure.DUse request/response traces and diagnostic decisions while preserving the identity and effect guarantees.
Sign up free to answer and see whyCan you adapt a timed teaching contract to audience and duration changes while preserving the mechanism, evidence, and limits? State the relevant identifiers, failure boundary, and evidence in your own words before selecting your confidence.
Not yetGetting thereConfident
Sources
Free to read · better with Enzo
Learn it with Enzo
Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.