Architecture Deep-Dive: 15–20 Minute Past-Project Talk and Retrospective Follow-ups

One round of this staff-level loop is an architecture deep-dive on your own past work. You prepare a 15–20 minute presentation about a significant technical project you were deeply involved in, deliver it to the interviewer, and then answer follow-up questions, including retrospective ones such as "What would you do differently?" The interviewer is judging both the system and you: how well you understand and explain its architecture, why it was shaped the way it was, which decisions were yours, what the outcome was, and how honestly you can critique it in hindsight. ### Constraints and Clarifications - The talk itself runs 15 to 20 minutes; follow-up questions come after it. - The project must be one you personally worked on. Keep the real technical substance, but abstract away anything confidential, such as internal names or exact figures. - Expect the follow-ups to go deeper than the slides: alternatives you rejected, failure modes, and hindsight. ### Clarifying Questions - Are slides expected, or is a whiteboard or shared document acceptable? - Will the interviewer interrupt during the talk, or hold questions until the end? - Is the audience one engineer or a panel, and how much domain background should you assume they have? - Does the project need to be recent, or is the most representative one preferred even if it is a few years old? ### Part 1 — Choose and deliver the presentation Pick the project and plan the 15–20 minutes. Describe which project you would choose and why, how you would structure the talk and budget its time, and how you would present the architecture and the key decisions so that a technical listener outside your domain can follow and evaluate them. ```hint Choose by decisions, not size The best project is the one where you can point to hard choices you drove, not necessarily the biggest system you were near. ``` ```hint Budget the minutes Write the time split down before building any slides; the architecture section is usually what gets squeezed. ``` #### What This Part Should Cover - A project selection rationale tied to scope, ambiguity and personal ownership - A time-budgeted outline that frames the problem and its stakes early - Architecture at the right altitude, with the key decisions and the alternatives rejected - A clear line between what you did and what the team did, plus measurable results ### Part 2 — Handle the follow-ups After the talk the interviewer asks "What would you do differently?" and keeps probing: a component they think is fragile, a decision they would have made another way, a result that looks surprising. Explain how you would answer the retrospective question and how you would handle the probes, including one you cannot fully answer. ```hint Hindsight with substance A convincing retrospective names one specific decision and the information that later changed your view. ``` #### What This Part Should Cover - A concrete retrospective answer covering the original reasoning, what changed, and the alternative - Defending a decision through its constraints while staying open to a better idea - Handling a question you cannot answer without bluffing - Short, direct answers that let the interviewer steer the depth ### What a Strong Answer Covers - The problem and its business stakes framed early, before technical detail - Technical depth on the decisions that mattered, including trade-offs and failure modes - Ownership that is specific and credible at staff-level scope - Honest self-critique rather than defensiveness or false modesty - Time discipline and clear communication throughout ### Follow-up Questions - Which part of the system would fail first at ten times the load, and how would you find out before users did? - Who disagreed with the central design decision, and how was the disagreement resolved? - If the timeline had been cut in half, what would you have dropped or simplified? - How did you measure success after launch, and did the results match what you predicted?