## Question Choose one project you know deeply and defend its major technical trade-offs. Explain the original constraints, the architecture you chose, at least one credible alternative, what evidence changed or confirmed your decision, and what you would redesign now. Expect the interviewer to spend most of the discussion on this single project and to probe implementation details rather than accept a high-level summary. ### Constraints & Assumptions - Use a project in which you personally made or materially influenced a technical decision. - Separate decisions you owned from team decisions and inherited constraints. - Do not invent impact metrics; use the evidence actually available. - Be prepared to trace one request, event, or data record through the system. ### Clarifying Questions to Ask - Would you like the deep dive to emphasize architecture, reliability, performance, or delivery trade-offs? - How much product context is useful before the technical walkthrough? - Should I use a diagram or begin with the hardest decision? ```hint Pick a decision with a rejected alternative Depth comes from explaining why two plausible options behaved differently under the project's real constraints. ``` ### What a Strong Answer Covers - A compact system map and the candidate's exact ownership. - Concrete constraints, alternatives, decision criteria, and resulting failure modes. - Implementation detail that remains consistent under follow-up questions. - Measurement, incidents, or user evidence that tested the design. - A candid redesign based on what is known now. ### Follow-up Questions 1. Which assumption was most fragile? 2. What would fail first at ten times the load? 3. Which decision would another strong engineer reasonably dispute? 4. What did you personally implement or review?