## Present a Metrics-Driven Technical Project Choose one project you personally worked on and present it to a general software-engineering audience. The project may come from a specialized domain, but the explanation must make its problem, architecture, trade-offs, and impact understandable without assuming domain expertise. ### Constraints & Assumptions - Use a real project and remove confidential identifiers or values where necessary. - Separate your own decisions and implementation from the work of the wider team. - Explain each domain-specific term before relying on it. - Tie every metric to a baseline, denominator, measurement window, and interpretation. - Include one limitation, failed approach, or unresolved risk rather than presenting a flawless story. ### Clarifying Questions to Ask - How much time is available for the presentation and discussion? - Should the audience prioritize architecture depth, execution, or business impact? - May diagrams or a small number of slides be used? - Which project details must remain abstracted for confidentiality? ### What a Strong Answer Covers - The user or system problem, why it mattered, and the candidate's responsibility. - A plain-language system model before specialized terminology. - The main architecture and one or two consequential technical decisions. - Alternatives considered, constraints, failure modes, and validation. - Metrics that establish a credible before-and-after comparison. - A limitation, lesson, and next step connected to the evidence. ```hint Make the metric carry meaning State what changed, compared with what baseline, over which population and period, and why that change mattered to the system or customer. ``` ### Follow-up Questions 1. Which part of the outcome can you confidently attribute to your change? 2. What domain concept was hardest to translate for a generalist audience? 3. Which alternative did you reject, and what evidence drove that choice? 4. What failed in production or testing, and how did the design change afterward? 5. If usage grew substantially, which assumption would fail first? 6. What would another engineer need in order to operate the system without you?