# Present a Technical Project to a Cross-Functional Audience Prepare a 20-minute deep dive on a project you actually worked on, followed by technical discussion. The audience includes engineers who do not share your domain background. Your presentation must make the business value understandable without hiding the important engineering decisions. ### Clarifying Questions to Ask - What background can be assumed from the audience? - Should the presentation optimize for architecture depth, leadership evidence, or both? - Are approximate metrics acceptable when details are confidential? ### Part 1: Build the narrative Outline the opening that explains why the project existed, who benefited, what success meant, and what you personally owned. #### What This Part Should Cover - A concise problem statement and business motivation - Personal contribution separated from team output - A measurable or observable success definition ### Part 2: Explain the design and trade-offs Choose one consequential technical decision. Present at least two viable options, the constraints used to compare them, the choice made, and what evidence later supported or challenged it. #### What This Part Should Cover - Real alternatives rather than a retrospective straw man - Technical and organizational decision criteria - Acknowledgment of residual risks and reversibility ### Part 3: Discuss challenge, measurement, and retrospective Explain one surprise or difficult constraint, how you responded, the outcome or return on investment, and what you would do differently. Generalize the lesson into a reusable engineering pattern without overstating it. #### What This Part Should Cover - A concrete challenge and decision under uncertainty - Credible outcome measurement - A bounded, reusable lesson and a changed future behavior ### What a Strong Answer Covers - A clear high-level story that remains technically defensible under follow-up - Honest attribution, useful diagrams or examples, and disciplined terminology - Decision quality, evidence, and learning rather than a chronology of tasks - Enough domain translation for a newcomer to ask meaningful questions ### Follow-up Questions 1. Which slide would you remove if the presentation were cut to ten minutes? 2. What assumption drew the most skepticism during review? 3. How did you measure value separately from implementation completion? 4. What part of the design would not generalize to another domain?