Present a Past Project with Slides to a Panel of Engineers and PMs

Prepare a slide deck about a project you have worked on, and present it to an interview panel of engineers and product managers. Panel members ask questions throughout the talk, not only at the end. The deck had to be prepared in advance against the company's written requirements, which the report describes as more numerous and more detailed than other companies' but does not list. This was the first of three onsite rounds for a software engineering role on a traditional product (non-AI) team. ```hint Two audiences, one story For each part of the talk, decide what an engineer on the panel needs to hear and what a product manager needs to hear, and where each kind of depth belongs. ``` ```hint Budget for interruptions Questions will arrive mid-slide. Decide in advance which slides you can drop and which material you hold in reserve, so an interruption never costs you the results and the lessons. ``` ### Constraints and Clarifications - Not reported: the length of the session, a slide limit, the required sections, and how long the question period runs. Get the written requirements and follow them exactly. - Anything confidential from a current or previous employer stays out of the deck. ### Clarifying Questions - How long is the session, and how much of it is presentation versus questions? - Which sections or topics must the deck cover, and is there a slide limit or a template? - How much technical depth does the panel expect, and will they want to see code, diagrams or data? - Who will be on the panel, and should I expect interruptions or hold questions until the end? - Which details of past work (metrics, architecture, customer names) am I allowed to share? ### What a Strong Answer Covers - A project choice with substantial personal ownership, real technical depth and a measurable outcome - A clear arc from problem and context, through goals, constraints and key decisions, to results and lessons - Technical decisions explained with the alternatives considered and their trade-offs, each tied to its user or business impact - A clear line between personal contribution and the team's, with honest coverage of what went wrong - Composure under interruptions: concise answers, backup material, and finishing on time - Respect for confidentiality while still giving concrete or relative results ### Follow-up Questions - What was the hardest technical decision in this project, and which alternative did you reject? - How did you know the project succeeded, and what would you have done if the main metric had not moved? - Which part of the work would you redo today, and why? - A product manager on the panel asks why this project was worth more than the other work your team could have done. How do you answer?