# Technical deep-dive interviews: explain your projects Choose a project you understand well. Explain the problem, trace the relevant system flow, and identify your own contribution. Prepare to justify one decision, discuss an alternative, and separate measured results from assumptions or outcomes you did not verify. About 7 min read. ## On this page - [What is a technical deep-dive interview?](https://preprole.com/guides/technical-deep-dive-interview#what-it-is) - [Choose a project you can explain from several angles](https://preprole.com/guides/technical-deep-dive-interview#choose-project) - [Give a short system overview before the implementation detail](https://preprole.com/guides/technical-deep-dive-interview#opening) - [Explain a decision through its constraints and alternatives](https://preprole.com/guides/technical-deep-dive-interview#trade-offs) - [Separate a working test from a measured production result](https://preprole.com/guides/technical-deep-dive-interview#evidence) - [Prepare for follow-ups that challenge your account](https://preprole.com/guides/technical-deep-dive-interview#follow-ups) - [Run a project rehearsal in three passes](https://preprole.com/guides/technical-deep-dive-interview#rehearsal) ## What is a technical deep-dive interview? A technical deep-dive explores how you understand a project, a design, or a difficult engineering decision. It may start with something on your resume and follow the details of your explanation. Unlike a fixed coding exercise, the discussion can move between architecture, implementation, operations, collaboration, and lessons learned. Confirm the expected format with the recruiter because companies use this label differently. The useful preparation is rebuilding your understanding of the work so that you can answer why a choice was made, what you personally did, and what evidence supported the outcome. You should be comfortable saying where your knowledge ends. Guessing about another team's internals usually makes the account less credible. Amazon's preparation guidance emphasises applying knowledge to problems rather than memorising every detail of a topic. Microsoft asks candidates to prepare specific examples and explain their reasoning. This guide uses those principles to structure a project rehearsal; it does not reproduce either company's interview rubric. Reference: [Amazon Careers: software development interview topics](https://amazon.jobs/content/en/how-we-hire/interview-prep/software-development-topics) ## Choose a project you can explain from several angles Select a project with a clear problem, a meaningful contribution from you, and at least one decision you can discuss. The largest project on your resume is not automatically the best choice. A smaller change that you investigated, implemented, tested, and observed can support a deeper conversation than a large migration in which you only touched one configuration file. Prepare a second project if the first is too far from the role or too confidential to discuss. Use approximate or hypothetical numbers only when you label them clearly. Do not bring internal diagrams, customer records, proprietary source code, or restricted documents into practice tools. You can explain a design using simplified components and public terminology. - Problem: what was difficult and who experienced it? - Boundary: which components and responsibilities were yours? - Decision: what did you choose, and what alternative did you reject? - Verification: how did you test or observe the change? - Reflection: what would you now change, and why? ## Give a short system overview before the implementation detail Open with the purpose of the system, the relevant flow, and your contribution. Name only the components needed to understand the problem. Ask whether the interviewer would prefer to explore the architecture or a specific implementation detail. This gives the conversation direction without assuming which part they want to assess. The following illustrative opening is not a customer answer. It leaves obvious follow-up points: the timeout, the dependency, the error response, and the verification. That is useful. A strong opening creates a path into the details instead of trying to settle every detail at once. > The service returned order status to a support dashboard. One external integration could respond slowly, and our handler waited without a clear deadline. I investigated that path and owned the timeout behaviour and tests, while another engineer owned the upstream integration. I added a bounded wait and a distinct error response so the dashboard could distinguish unavailable data from a missing order. I can walk through the request flow or the test cases first. ## Explain a decision through its constraints and alternatives A technology name is not a reason. If you selected a queue, cache, database index, or service boundary, explain the requirement that made it useful. Describe the relevant constraint: latency, failure isolation, development time, consistency, existing operational skills, or something else you actually faced. Then explain the cost you accepted. Every additional component creates work as well as capability. For the timeout example, adding retries would not automatically solve the problem. Retrying a slow dependency can increase its load, and retrying a side-effecting request can create duplicates unless the operation has suitable safeguards. You might instead return a clear failure and let the caller decide what to do. Explain what your system actually guaranteed rather than using reliability language as decoration. An alternative does not have to be objectively bad for your choice to be reasonable. Say why it was less suitable under the conditions at the time. If the interviewer changes those conditions, revisit the choice. Revising a design in response to a new constraint shows reasoning; defending every original decision regardless of context does not. ## Separate a working test from a measured production result Prepare the evidence behind each result you plan to mention. A passing unit test establishes something narrower than a successful rollout, and a successful rollout establishes something narrower than a business outcome. If you did not collect production measurements, say so. You can still explain which failure case you reproduced and what the change made observable. When you do have measurements, know the baseline, the observation window, and the conditions. If performance improved during a period when traffic also changed, be cautious about attributing the entire difference to your code. Interview preparation is a good moment to remove claims from your resume that you cannot explain responsibly, not to add more impressive-looking numbers. ## Prepare for follow-ups that challenge your account Ask a rehearsal partner to interrupt with why, how, and what-if questions. These should test the reasoning, not reward memorisation. For an area outside your ownership, explain the boundary and describe how you would find out more. Avoid silently changing a real project into an imagined ideal system when the discussion becomes difficult. If you spot an error in your own explanation, correct it directly. For example, clarify that a timeout limits waiting but does not prove that the remote operation stopped. That distinction matters when discussing retries or side effects. A precise correction is more useful than continuing with an oversimplified claim. - Why was that component or library needed? - What failed before the change, and how did you reproduce it? - Which part did you personally implement? - How did the system behave when the dependency was slow or unavailable? - What would you do differently with more traffic or a smaller team? - What did you not measure, and what would you measure next? ## Run a project rehearsal in three passes First, explain the project in plain language without a diagram. Check whether a listener can repeat the problem, your contribution, and the result. Second, draw the smallest useful architecture and trace one request or event. Show where data enters, where state changes, and where failure can occur. Third, challenge one decision by changing a constraint and considering an alternative. Afterwards, write down the first question that made you vague. That is your next preparation task. It may mean reviewing a concept, checking permitted project notes, or changing a claim to match what you know. Repeat the uncertain explanation aloud rather than rereading the entire project history. Useful rehearsal ends with a specific change to the next answer. ## Frequently asked questions ### Is a technical deep-dive the same as system design? Not necessarily. A project deep-dive often starts with work you actually did, while a system-design exercise may ask you to design a hypothetical service. Either can include architecture and trade-offs. Confirm the format rather than relying on the name alone. ### Can I discuss a personal project? Yes, if it is relevant and you identify it honestly. Explain the constraints and what you verified. Do not describe a learning exercise as a production service or invent users, traffic, operational incidents, or business outcomes. ### What should I do if I do not know an answer? State what you know, identify the uncertain part, and explain how you would investigate it. Distinguish a hypothesis from a fact about the project. If a follow-up concerns work owned by someone else, make that boundary explicit. ### Should I bring code to the discussion? Ask about the format and confidentiality constraints first. A small simplified example can help, but never share restricted code. If you use PrepRole's Code Pad, remember that it is read by the AI Interviewer and never executed. ## Practise the next answer Choose Technical Deep-Dive with your resume and Target Role. Use the Code Pad to make a small example concrete when useful. PrepRole's Code Pad is read by the AI Interviewer but does not execute code; verify runnable code separately in your own environment. Practise for your job: https://preprole.com/setup ## Sources and scope Employer sources describe their own processes, which may change. The exercises and illustrative examples are PrepRole editorial guidance, not employer questions or hiring criteria. - [Microsoft Careers: interview tips for all roles](https://careers.microsoft.com/v2/global/en/hiring-tips/interview-tips.html) - [Amazon Careers: software development interview topics](https://amazon.jobs/content/en/how-we-hire/interview-prep/software-development-topics) ## Related guides - [Prepare a system-design discussion](https://preprole.com/guides/system-design-interview-preparation) - [Make your contribution more specific](https://preprole.com/guides/improve-star-answers) - [Choose the right Interview Stage](https://preprole.com/guides/stages) AI feedback can be wrong. A practice Verdict is not a hiring decision.