Project Deep Dive: Design Decisions, 100x Scale, AI-Assisted Development and Reliability

In a technical round of a software engineer interview loop at an early-stage startup, you walk the interviewer through a technical project from your previous experience: its background, architecture, implementation decisions, challenges and possible improvements. The interviewer states that this is not a traditional system design interview; the goal is to see how you approach real engineering problems and make technical decisions. Expect frequent follow-up questions about the actual problem, the reasoning behind your decisions and the assumptions you made, and expect to be asked for concrete examples rather than abstract explanations. Choose one project you know in depth and answer every Part about it. ### Clarifying Questions - Should the project be one I led, or may it be one where I owned a specific component, and how should I mark which decisions were mine? - May I show source code or a diagram, and if the code is proprietary, is a sanitized walk-through acceptable? - How long should the overview take before the follow-up questions start? - Where exact scale or impact figures are confidential, are approximate ranges acceptable? ### Part 1 — Problem, architecture and technical decisions What problem were you trying to solve, and why was the project necessary? What did the original system or process look like? Explain the overall architecture. Why did you choose this design, which alternative approaches did you consider, and how did you evaluate the trade-offs between them? What constraints influenced your engineering decisions, and how did you measure the impact of your implementation? ```hint Start from the before state Describe what was broken or missing in the original system in terms someone outside the team would feel, then let each architectural choice answer one piece of that. ``` #### What This Part Should Cover - The problem, what it cost, and the original system or process - The architecture, with each major choice tied to a requirement or constraint - At least one real alternative and the criteria that ruled it out - An impact measurement against a baseline ### Part 2 — Scale, performance and a 100x workload What were the original scale and performance requirements, and how did they influence your architecture? How did you think about latency and performance during the design phase? What would happen if the workload increased significantly, potentially by 100x: which parts of the architecture would need to change, and what would become the primary bottlenecks? If you needed to optimize the system, where would you start? ```hint Multiply each stage Take the request rate and data volume at each stage of your architecture, multiply them by 100, and see which resource runs out first. ``` #### What This Part Should Cover - The original requirements stated as numbers: rates, data sizes, latency targets - Bottlenecks identified stage by stage in this architecture, in the order they would appear - What must change at 100x and what can stay - An optimization plan that starts from measurement ### Part 3 — AI tools in your development workflow Did you implement the project manually, or did you use AI coding tools? What does your typical development workflow look like? How do you break down engineering requirements before implementation? How do you use AI agents for design and for implementation? How do you review and validate AI-generated code, how do you ensure that it follows your intended architecture, and how do you approach testing when using AI agents? ```hint Where judgment stays yours Walk through one feature from requirement to merge and mark each step where the tool proposes and you decide, and how you would notice it being wrong. ``` #### What This Part Should Cover - An accurate account of how the project was actually built - Requirements broken into a specification and acceptance checks before any code is generated - Concrete review, architecture-conformance and testing practices for generated code - Where you keep ownership, and what you never delegate ### Part 4 — The mission-critical component and its failures Which part of your system is the most mission-critical, and what would happen if it failed? Which types of failure would be the most difficult to detect or recover from? Which parts of the implementation require the most careful manual review, and what safeguards would you put in place when using AI-generated code for critical functionality? What edge cases would you consider, how would you prevent failures from affecting other parts of the system, and how do you weigh correctness, availability and operational complexity against each other? ```hint Silent beats loud A crash pages someone. Ask which failure in your system would produce wrong results while every dashboard stays green. ``` #### What This Part Should Cover - The critical component and the blast radius of its failure - Silent failure modes and how each would be detected - Isolation and safeguards, including for generated code on critical paths - An explicit correctness, availability and complexity trade-off for this system ### Part 5 — Compromises and future improvements If you had more development time, what would you improve? What technical compromises did you make because of time constraints? How would you make the architecture more extensible, what would you redesign if the product requirements changed, and what additional reliability or validation mechanisms would you introduce? ```hint Debt you chose Separate the compromises you made knowingly, each with the condition that would make you revisit it, from the ones you discovered later. ``` #### What This Part Should Cover - Compromises named with their reason and their current cost - Improvements prioritized by risk reduced or value added - Extension points matched to the requirement changes most likely to come - Additional validation and reliability mechanisms ### Part 6 — Walk through the implementation Toward the end, the interviewer asks whether you can walk through the actual implementation. Show how the code is organized and discuss its implementation details and design decisions at a high level, pointing to where the decisions you described earlier live in the code. ```hint Follow one input Trace a single input from the entry point through the code to its stored result, stopping at each decision you defended earlier. ``` #### What This Part Should Cover - A path through the code that matches the architecture you described - Where the key decisions and the critical path live in the code - How the tests demonstrate the behaviour you claimed ### What a Strong Answer Covers - Clear ownership: which problems and decisions were yours, and the reasoning behind each - Trade-offs explained through the alternatives that lost and why they lost - Concrete examples and numbers whenever the interviewer asks, instead of abstract explanations - Engineering judgment kept when AI tools are used: specification, review and tests - Reliability and scalability reasoning grounded in this specific system rather than generic patterns - Clear communication under frequent follow-up questions ### Follow-up Questions - Which decision you defended in Part 1 is most likely to be wrong at 100x, and what signal would show it first? - Describe a specific case where an AI tool generated code that looked right but was not. How did you catch it, and what did you change in your process? - If you had to hand the system to a new engineer tomorrow, what would you document first? - If you had only one more week, which improvement would you make, which would you drop, and why?