Resume Project Deep Dive: Tech Stack Choices, Trade-offs, Business Logic and Ownership

The first 20 minutes of an SDE II phone screen went to a deep dive on a project from the candidate's resume, followed by two leadership-principle behavioral questions that the candidate did not record. This entry covers the project deep dive. Pick one substantial project from your resume and walk the interviewer through it. Over the conversation you will be asked: - why the project uses the technology stack it does, - what trade-offs those technology choices involved, - how the business logic of the system works, and - exactly which part of the project you were personally responsible for. Because this is a deep dive rather than a summary, expect each answer to be followed by "why?" or "what would have happened if you had done it differently?". ```hint Pick a project you can defend line by line Choose a project where you took part in the technology decisions and can explain the business rules in detail, even if another project on your resume sounds more impressive. ``` ```hint Separate "we" from "I" before the interview Write down which components, decisions and incidents were yours alone, and where your part handed off to someone else, so the boundary comes out clearly when you are asked. ``` ### Clarifying Questions - Would you like the most recent project, or the one most relevant to this team? - Should the business logic be explained as the domain rules, or down to the code paths that implement them? - Would you prefer a short overview first and then choose where to go deep, or a walk through each area in order? ### What a Strong Answer Covers - A brief framing of the project: the business problem, its users, its scale, and your role in one sentence - Each major technology choice justified against a named alternative, with the constraints that decided it - Trade-offs stated as costs the team accepted, and how those costs played out in production - Business logic explained concretely: the key entities, the rules, the edge cases, and how correctness was verified - A precise ownership boundary: what you designed, built, decided and fixed yourself, and what teammates owned - Details and numbers that stay consistent when the interviewer probes the same point twice ### Follow-up Questions - If you started this project today, which technology choice would you change, and why? - Which business rule was hardest to get right, and how did you find out that the first version was wrong? - Which part of the project that you did not own caused you the most trouble, and how did you handle that dependency? - What did the project measurably improve, and how was that measured?