Technical Deep Dive: Present a System You Built as a Design Retrospective

In this round of a senior software engineering loop you present a system you designed or led in a past role, using an architecture diagram you prepare before the interview, and then the interviewers question it. Think of it as a system design interview run in reverse: instead of designing something new, you explain real decisions after the fact, defend them, and say what you would change. Interviewers at this company tend to start from a simple picture and build up from there, and they push for depth wherever your explanation stays shallow. Prepare the presentation, then work through the three parts below as they would unfold in the room. ### Constraints and Clarifications - The diagram is prepared in advance; the round assumes you arrive with it ready to share. - The system must be one you worked on, and your own contribution will be probed. - Confidential names and figures can be generalized, as long as the shape and rough scale stay honest. ### Clarifying Questions - How is the time split between my presentation and open questioning? - Should the system be one I led end to end, or can it be one where I owned a major component? - Would you prefer breadth across the whole system or depth on its hardest part? - How much detail is appropriate where parts of the system are confidential? ### Part 1 — Choose and frame the system Pick the system and open the session: what problem it solved, who depended on it, the constraints you worked under (scale, latency, team size, deadlines, legacy code), and exactly what you owned versus what others built. ```hint Choose for depth Prefer a system in which you could defend every box under sustained questioning over one that merely sounds impressive. ``` #### What This Part Should Cover - A system with real technical decisions in it and clear personal ownership - The problem, the users and the constraints stated before any architecture - An honest boundary between your contribution and the team's ### Part 2 — Walk the architecture and its key decisions Using your diagram, walk through the main components and data flows, beginning with the simplest view and adding detail. Then pick the two or three decisions that most shaped the system and, for each one, explain the alternatives you weighed, the constraint that settled it, and what it cost. ```hint Layer the picture Decide what a first-time viewer needs to see in the first minute, and what you reveal only when someone asks about a particular box. ``` #### What This Part Should Cover - A simple-to-detailed progression the interviewers can follow - Decisions framed as alternatives and trade-offs, tied to the constraints that drove them - Real numbers (load, latency, data size, cost) wherever they mattered to a decision ### Part 3 — Defend it and look back The interviewers now probe. Go deeper into whichever component they pick, describe something that failed or hit its limits in production and how you found out, explain how the system behaved as load or scope grew, and say what you would design differently today. ```hint Bring the scars Have a specific incident or limitation ready, with how it was detected and what changed afterwards; a retrospective with no mistakes is hard to believe. ``` #### What This Part Should Cover - Depth on demand in any component, including its failure modes - An honest account of a failure: detection, response, root cause and lasting fix - A redesign proposal grounded in what you learned, with its migration cost ### What a Strong Answer Covers - A clear arc across the session: problem, design, decisions, outcomes, lessons - Ownership stated precisely, with credit given to others - Trade-off reasoning rather than a tour of technologies - A readable diagram that supports the conversation instead of replacing it - Calm, specific answers when pushed beyond the prepared material ### Follow-up Questions - If traffic grew by an order of magnitude tomorrow, which component would break first, and what would you do about it? - Which decision would you reverse today, and what would migrating away from it cost? - Which part did you not build yourself, and how well do you understand how it works? - How did you know the system was doing its job, and which metric would have warned you first that it was not?