In a deep-dive round you pick one project and an experienced engineer spends 45 minutes taking it apart: the architecture, the decisions, the failures, and exactly which parts were yours. It is the round where invented scope collapses fastest and real depth scores highest, and at Staff level it often decides the level. This chapter covers where the round appears, how to choose the project, a 45-minute structure, the probes to expect, a full worked deep dive on a side project, and a fill-in template for a work project.
Where the round appears
The name changes by company; the format barely does. You present a project, usually with a diagram, and the interviewer interrupts with "why", "what else did you consider" and "what did you personally do".
| Company | Round | What is known |
|---|---|---|
| Meta | Project retrospective | Reported for some E6 loops, chosen by the hiring team for certain roles; not every E6 gets one, and those who do not get a second coding round. About 45 minutes with an engineer, drawing in Excalidraw while you talk. Scored on technical depth, ownership and leadership, impact measured in numbers, and reflection. |
| Googleyness & Leadership | Reported in May 2026 (Business Insider, via Exponent) as a pilot in some orgs that adds a technical design discussion of your past work. It is not known to be standard in India yet: ask your recruiter, and have a deep dive ready in case. | |
| Amazon | Loop round at SDE III | Reported: one of the five rounds is either object-oriented design or a project deep dive. Every Amazon round also asks Leadership Principle questions, so expect "Dive Deep" and "Ownership" probes on the same project. |
| Microsoft, LinkedIn, Uber, Apple | Hiring-manager round | Candidates commonly report the manager asking for a walk-through of a recent project, taking a large part of the call. Same skills, less time. |
| Everyone | "Walk me through your résumé" | Any interviewer can turn one line of your résumé into a ten-minute deep dive. Everything on it must survive that. |
The round tests one question from four angles: did you understand the system, did you make the decisions, did you know what they cost, and did you learn from what went wrong? Every probe in the probe list maps to one of those four.
How it is scored
| Signal | Senior (L5 / E5) | Staff (L6 / E6) |
|---|---|---|
| Technical depth | Explains every component you built and why it is shaped that way; answers two levels of "why" | Same, plus the parts you did not build: why the whole system is shaped that way, and where it will break next |
| Ownership | Clear about what you designed, built and decided | Clear about which decisions you drove across teams, and who you had to convince |
| Trade-offs | Names the alternatives you rejected and what your choice cost | Shows the choice was right for the organisation, not only the code: timelines, team skills, migration risk |
| Impact | A number for the result | A number, plus what changed for other teams or the business afterwards |
| Reflection | What you would change | What you would change and the mechanism you put in place so the next project does not repeat it |
Choosing the project
You get to choose, and the choice is half the score. Score each candidate project against these criteria before you prepare any of them.
| Criterion | Strong | Weak |
|---|---|---|
| Your role | You were the technical lead or made the key design calls | You implemented one part of someone else's design |
| Technical meat | Real trade-offs: consistency, failure handling, data model, migration | CRUD with a framework doing the hard parts |
| Scale or stakes | Load, money, users or other teams depended on it | An internal tool used by five people |
| Something went wrong | A failure, incident or wrong turn you can explain | Everything went to plan (nobody believes it, and there is nothing to probe) |
| Numbers | Before and after figures you can defend | "It improved things a lot" |
| Recency | Last two to three years; you remember the details | Five years ago; you will guess under questioning |
| Other people | Cross-team work, disagreement, persuasion | Solo work only (fine for Senior depth, weak for Staff) |
Example: one candidate's shortlist
Arjun, our example candidate (a composite) is a tech lead on the backend of a retail trading app, and built a trading-research system on the side. His shortlist, scored the same way:
| Project | Strengths | Risks | Use it for |
|---|---|---|---|
| FIX order routing (work) | Hard correctness problems: exactly-once orders, session recovery, unknown states. Money at stake. | Needs real numbers and his exact role. Confidentiality: describe shapes, not secrets. | The default deep dive for any backend or infrastructure team |
| Ledger and reconciliation (work) | Data modelling, auditability, break investigation; easy to show impact with break counts | Can sound like accounting if you do not bring out the engineering decisions | Payments, fintech, any team where correctness is the product |
| Trading research system (side project) | Every fact is his own and on record; strong judgment and scientific method; a real failure (the look-ahead bug) handled well | Solo, so "team dynamics" probes have thin answers. Small scale. Some interviewers discount side projects. | Judgment-heavy rounds, AI or data teams, or as the second project |
Prepare two: one work project as your default, and a second that shows a different strength (for Arjun, the side project). Use the work project unless the interviewer asks for something else or the team is about research, data or AI. Ask at the start if they have a preference: "I can do our order-routing system or a trading research system I built; which is more useful?"
A 45-minute structure
Prepare a spine you could deliver uninterrupted in about 15 minutes. In practice you will be interrupted after two, and the interviewer will drive. The spine is there so that after each digression you know where to return.
- 0–3 min
- Context. The business problem, who the users were, why it mattered, the constraints (deadline, team size, regulation). One sentence on what success meant.
- 3–10 min
- Architecture. Draw it. Boxes for services and stores, arrows for data and requests, and mark the part you owned. Walk one request through it end to end.
- 10–12 min
- Your role. What you designed, built, decided and led. Who else was involved and what they owned. Say this explicitly; do not make them dig.
- 12–25 min
- Three key decisions. For each: the options, what you chose, why, and what it cost. This is the scoring centre of the round.
- 25–32 min
- The hardest problem. The bug, incident, migration or disagreement that nearly went wrong. How you found it, what you did, what changed afterwards.
- 32–37 min
- Results with numbers. Before and after. Who used it. What happened six months later.
- 37–40 min
- What you would change. One or two real things, with why you did not do them at the time.
- 40–45 min
- Your questions, or overflow from the probes.
Spending 15 minutes on context and architecture before reaching a decision. Interviewers record decisions and trade-offs; context earns nothing on its own. If you are past minute 10 and have not said "we had two options", you are behind.
Decisions: the shape of each one
DECISION what had to be chosen, in one line OPTIONS 2–3 real alternatives (the ones a competent team would consider) CHOICE what you picked WHY the constraint that decided it (data, deadline, risk, team) COST what it made harder, and how you contained that HINDSIGHT would you choose the same today? what would change your mind?
The cost line is where most candidates lose points. "We chose Kafka because it scales" earns nothing; "we chose a per-account partitioned log so order events stay in sequence, which cost us hot partitions for our largest accounts, so we [mitigation]" earns the signal.