Anthropic SWE Onsite: Project Deep Dive Guide
Estimated read time: 9-11 minutes
Summary: The Anthropic Project Deep Dive is a formal presentation round. You prepare a slide deck or structured document, present for around 20 minutes, and then face intense technical interrogation from a panel who will probe the limits of your knowledge on the system you claim to own. This is one of the highest-signal rounds in the entire process, and one of the most commonly mishandled. Showing up with a surface-level walkthrough ends your candidacy.
Want to see how the Project Deep Dive fits into the full onsite structure? View the Anthropic SWE interview roadmap
TL;DR + FAQ (read this first)
At-a-glance takeaways
- A formal presentation round, you prepare in advance and present to a panel
- Roughly 20 minutes of presentation followed by intense technical Q&A
- You must be able to answer deep technical questions on every part of your presented system
- Only present work you personally owned, the panel will find the edges of your knowledge
- Happens in Loop 2 of the onsite, after passing the Loop 1 hard gate
- Generic walkthroughs are a fast track to rejection
Quick FAQ
Do I prepare the presentation in advance?
Yes. Candidates are typically notified before the onsite that a Project Deep Dive is included. You are expected to prepare a slide deck or a structured Notion document. Do not wing this round.
Can I present a team project?
Only if you can speak exhaustively to your personal contributions. The panel will probe every decision in the system. If you did not make that decision, you will not be able to answer questions about it convincingly. Choose a project you truly own, not the most impressive one your team shipped.
How technical is the Q&A?
Very. Interviewers may ask about specific implementation choices, alternative approaches you considered and rejected, how your system would behave under specific failure conditions, and what you would do differently now. "I'm not sure" is acceptable occasionally, failing to understand the system you just presented is not.
What if I don't have a highly complex project to present?
Depth of ownership matters more than scale of the system. A well-understood, clearly owned project on a smaller system is more compelling than a surface-level account of a large distributed system you contributed to tangentially. Pick the project where your ownership is deepest, regardless of headline scale.
Is this round Pass/Fail like Loop 1?
The hard gate is at Loop 1. By the time you reach the Project Deep Dive, you are in Loop 2. However, performance across all Loop 2 rounds, including this one, informs the final hiring decision. A weak Deep Dive can still sink an otherwise strong onsite.
What the Project Deep Dive is actually testing
1) Provable ownership of past work
The purpose of this round is to verify that the experience on your resume reflects genuine, deep engagement with real systems. The panel is specifically probing for the difference between someone who owned a system and someone who was present while a system was built around them.
Provable ownership means: you can explain not just what the system does, but why every significant decision was made, what alternatives were considered, what failed, what you would do differently, and what the system's actual failure modes are under production conditions.
2) Technical depth and architectural judgment
The Q&A will go deeper than your presentation. Interviewers will ask about decisions you made, trade-offs you accepted, and approaches you did not take. They are looking for evidence that you understood the design space, not just that you shipped something that worked.
Strong candidates can articulate the reasons they chose one approach over its alternatives in the same way they would in a technical design review. Weak candidates can describe what they built but not the reasoning that led there.
3) Intellectual honesty and epistemic humility
Anthropic places significant weight on honesty and self-awareness. In the Deep Dive context, this means: you should be able to say what went wrong, what you got wrong, and what you would change. Candidates who present only the polished success story and have no answer for "what would you do differently?" are a red flag. The panel is not looking for perfection, they are looking for someone who understands their own work honestly.
4) Safety-aware thinking applied to real systems
As with every Anthropic technical round, safety and correctness thinking is a signal. When you describe your system, do you mention how you handled failure modes? Do you talk about the correctness guarantees the system provides, or the ones it does not? Do you flag the risks you accepted? These are the kinds of considerations that distinguish a safety-conscious engineer from one who ships first and investigates later.
How the round runs
You present your prepared deck or document for approximately 20 minutes. The panel typically lets you present without interruption, though some interviewers will ask clarifying questions as you go. After the presentation, the Q&A begins, and this is where the real evaluation happens.
The Q&A has no fixed duration but typically runs for 20-30 minutes. Questions will start at the level of your presentation and then go deeper. Expect the panel to probe specific implementation decisions, ask you to reason through failure scenarios, and challenge assumptions in your architecture.
Do not try to steer the Q&A toward comfortable territory. If the panel asks about something you are uncertain on, say so clearly, and then show your reasoning. "I'm not certain, but here's how I'd think through it" is a much better answer than deflecting or over-claiming confidence.
How to choose the right project
The criteria for the right project are ownership depth and technical substance, not headline impressiveness.
Choose a project where you: made the architectural decisions, understand every significant component, can speak to what failed and why, and can articulate the trade-offs made at each decision point. If you are unsure whether a project meets this bar, ask yourself: "Could I answer 30 minutes of deep technical questions about this system without deferring to a teammate?" If the answer is no, choose a different project.
Technical substance matters too. A system with interesting engineering challenges, concurrency, consistency, reliability, scalability, or safety constraints, gives the panel more to probe and more opportunity for you to demonstrate depth. A CRUD application is a harder project to generate 30 minutes of compelling Q&A from, even if you owned it completely.
Avoid projects where: your contribution was primarily integration or configuration rather than design; the interesting decisions were made by someone else on the team; or the technical complexity is borrowed from a framework rather than something you designed and understood.
How to structure your presentation
A strong Deep Dive presentation covers these areas in roughly this order:
Context and problem statement. What problem were you solving? What were the constraints and requirements? Who were the users or consumers of the system? Keep this brief, one or two slides, but make it clear why the problem was non-trivial.
Your role and ownership. Be explicit about what you personally designed, implemented, and were accountable for. Do not leave the panel to infer this. Stating it clearly also signals self-awareness and prevents the awkward moment where a question reveals you did not actually own something you implied you did.
Architecture and design decisions. This is the core of the presentation. Walk through the key architectural choices and explain why you made them. What alternatives did you consider? What trade-offs did you make? What constraints shaped the design? This is where depth of ownership is most visible.
What went wrong and what you learned. One of the most important sections and the one candidates most commonly omit. Describe a real failure, a real mistake, or a real thing you would do differently. This is not a weakness, it is evidence of genuine ownership and intellectual honesty.
Outcome and impact. What did the system achieve? How did it perform? What metrics mattered? Keep this honest, avoid inflating numbers or impact claims the panel might probe.
Questions candidates have been asked
"Walk us through a significant project you led."
The opening. Your 20-minute presentation is the answer. The panel will then follow up on everything in it.
"Why did you choose X approach over Y?"
Be ready for this for every significant architectural decision in your presentation. "We evaluated X and Y and chose X because of Z" is the expected format. "That was the team's decision" is not.
"What would happen to your system if Z failed?"
Failure scenario reasoning. The panel will pick specific components of your system and ask you to trace what happens when they fail. Think through your system's failure modes before the interview.
"What would you do differently if you rebuilt this today?"
One of the most important questions. Have a genuine, specific answer. "I'd do it the same" is not credible. "I'd change X because we learned Y" is.
"Describe a situation where trade-offs affected your design decisions."
This may come as a follow-up to your presentation or as a standalone question. The answer should be concrete and specific, a real trade-off you made, the reasoning behind it, and what you gave up.
"Tell us about a time you disagreed with a teammate or had to build something that conflicted with your values."
A behavioral question embedded in the Deep Dive. Anthropic values intellectual honesty and independent thinking. Have a real example ready, and be willing to name the disagreement specifically, not hedge it into "we had some alignment challenges."
Preparing your Deep Dive presentation and want to stress-test it before the real thing? A mock session gives you the panel experience without the stakes.
Book a mock Deep Dive session | Practice interview questions
Common failure modes
Presenting a project you don't fully own. The most common and most damaging failure. If you present a system you did not design, you will not be able to answer questions about the decisions made in it. The panel will identify this within the first few minutes of the Q&A. Present only work you can speak to exhaustively.
Showing up without a structured presentation. The Deep Dive is a formal round. Candidates who arrive expecting to talk through a project conversationally, without a deck, signal that they have not taken the round seriously. Prepare a structured document or slide deck regardless of how confident you are in the material.
Only presenting the success story. Candidates who describe a smoothly executed project with no failures, no trade-offs, and no things they would change are not credible. Every real engineering project involves trade-offs and mistakes. Omitting them signals either that the candidate did not truly own the work or that they lack the self-awareness to reflect on it honestly.
Deflecting Q&A questions to the team. "That was decided by the team" or "I'd have to ask my colleague" are round-ending answers. If you cannot speak to a decision in your presented system, you should not have included that part of the system in your presentation.
Generic architectural descriptions. Candidates who describe their system at the level of "we used microservices with a message queue and a distributed cache" without being able to explain why those choices were made, what the alternatives were, and what the specific challenges were, are not demonstrating the depth Anthropic is looking for.
How to prepare
Choose your project early and stress-test it. Do not leave project selection to the week before the onsite. Choose the project with the most ownership depth and then give it to someone else to interrogate. Ask them to probe every decision, every component, and every failure mode. If you struggle to answer their questions, either go deeper on that project or choose a different one.
Write out the "why" for every major decision. Before the interview, document why you made each significant architectural choice. What alternatives did you evaluate? What data or reasoning led you to your decision? What trade-offs did you accept? This exercise forces you to articulate your thinking in a way that will translate directly to the Q&A.
Prepare your "what went wrong" section deliberately. Do not leave this to improvisation. Identify a real failure or mistake from the project, articulate what happened, why it happened, and what you learned. Practice saying this clearly and without over-hedging.
Rehearse the presentation out loud. Reading your slides is not the same as presenting them. Practice delivering the full 20-minute presentation to a real person. Time it. Refine it. The goal is to be able to deliver it confidently enough that your full cognitive bandwidth is available for the Q&A.
Map your system's failure modes in advance. For each significant component in your system, ask: what happens if this fails? What happens under high concurrency? What happens under degraded network conditions? Practice answering these questions clearly before you are asked them under pressure.
Ready to put your preparation into practice? Work through real interview questions or book a session with an engineer who can give you live feedback.
Ready to map out your full preparation plan across every stage of the Anthropic SWE loop? View the Anthropic SWE interview roadmap