Choose the best response for 5 scenarios involving product demos, architecture presentations, and sprint reviews — including handling silence and unexpected questions.
Presentation essentials for developers
Frame + scope first: "I'll cover X, Y, Z in 10 minutes"
Mixed audience: analogy first, technical depth for engineers
Unexpected questions: Acknowledge → Defer → Commit to follow up
Post-demo silence: seed the discussion with a known concern
0 / 5 completed
1 / 5
You're starting a 10-minute product demo for a new feature. Your audience includes both engineers and a non-technical product manager. Which opening is most effective?
Why B is best: frame, scope, and invite participation
A strong demo opening has three elements:
What you'll cover: "walk you through the new notification feature"
Structure + timing: "In 10 minutes, I'll cover what it does, how to use it, and next steps"
Audience invitation: "feel free to ask questions as we go"
Why the others fail:
A: Opens with jargon (Redis, TTL, write-through). Non-technical stakeholders are immediately lost
C: Stiff and formal — sounds like a robot, not a colleague
D: Unprepared — never start a demo without your screen already shared
Demo opening templates:
"Today I'll walk you through [feature]. It should take about [X] minutes."
"Let me show you what we shipped this [sprint/week]."
"I'll start with the user perspective, then show you what's happening under the hood."
"Feel free to stop me with questions — I've built in time for discussion."
2 / 5
You're presenting a proposed architecture change to move from a monolith to microservices. The CTO asks "Why microservices and not just modular monolith?" Which answer demonstrates the best technical communication?
Why C is the model answer: specific driver + acknowledged trade-off + incremental plan
When defending an architectural decision to leadership, use the Driver–Trade-off–Mitigation framework:
Driver: "Our main driver is independent scalability — payment vs notification load profiles differ"
Trade-off: "The trade-off is operational complexity" — shows you've thought critically
Mitigation: "Start with two services and expand incrementally" — reduces risk
Why the others fail:
A: "Everyone is doing it" — not a technical justification; shows herd mentality
B: "I know you prefer…" — dismissive of the CTO's valid concern, looks confrontational
D: Lists benefits without specifics ("different load profiles") and ignores the actual question about modular monolith
Useful architecture presentation phrases:
"Our main driver for this choice is…"
"The trade-off here is… and we plan to mitigate it by…"
"Compared to [alternative], this approach [advantage/disadvantage]."
"I'd recommend we start small and validate before committing."
3 / 5
During a sprint review presentation, a stakeholder asks an unexpected question outside your prepared scope. How do you handle it most professionally?
Why C is best: acknowledge, defer, commit
When you encounter an unexpected question in a presentation, the Acknowledge–Defer–Commit pattern is professional and honest:
Acknowledge: "That's a great question" — validates the questioner
Defer: "it's outside what I've prepared today" — transparent, not defensive
Commit: "I'll follow up with you after the meeting with a specific answer" — closes the loop
What to do if you're asked a question you genuinely don't know:
"I'm not certain of the exact figure — I don't want to give you wrong information. I'll verify and follow up."
"I'd need to check on that — can I send you a note this afternoon?"
Why the others fail:
A: Giving an incorrect answer destroys trust more than saying "I'll find out"
B: Harsh and defensive — doesn't offer resolution
D: Dismissive of a valid stakeholder question — looks arrogant
4 / 5
You're explaining a complex data pipeline to a mixed technical and non-technical audience. Which approach to handling jargon is best?
Why D is best: layered explanation for mixed audiences
The key technique for mixed audiences is the simple analogy first, technical depth second pattern:
Start with the business/user impact: "50 million events per day"
Use an analogy: "think of it as a series of assembly-line steps"
Layer in technical specifics for those who need them: "For the engineers in the room — Kafka, Flink, Snowflake"
Useful phrases for mixed-audience presentations:
"In simple terms, this means…"
"For the technical folks in the room, this translates to…"
"Imagine it as [analogy]. Under the hood, it's actually [technical reality]."
"The business impact is [X]. The technical mechanism behind it is [Y]."
The "zooming in" technique: Start broad → zoom into technical detail on request. "I've kept this high-level — happy to go deeper on any component."
5 / 5
You've just finished your demo and you say "Any questions?" Nobody responds. What's the best follow-up?
Why D is the best facilitation technique: seed the discussion
Silence after a demo usually means people are thinking, feel unsure about asking, or are waiting for someone else to go first. A skilled presenter seeds the discussion by:
Directing to a specific person ("Name")
Asking a question you know is relevant ("something that often comes up")
Relating it to their context ("Does this resonate with your team's situation?")
Other effective ways to handle post-demo silence:
"Let me anticipate a question I often get about this: [question]. The answer is [answer]."
"One thing that surprised us when we built this was [insight]. Does that align with what you'd expected?"
"While you're thinking — the one limitation I want to flag proactively is [limitation]."
Why the others fail:
A/B: Missed opportunity for feedback and engagement
C: Assumes your clarity — often the opposite is true; people may be confused but reluctant to look "slow"