The Project Deep Dive Round, From Resume Line to a Defended Walkthrough

This is a procedure for the scheduled project deep dive, also called a project retrospective: an interview where you lead a 30 to 60 minute walkthrough of one project from your resume and a panel questions it. It works for engineering, data, product, and design candidates who already have the invite. You start from that invite and the resume you submitted, and you finish with a chosen project, a rebuilt record of it, a timed opening, a probe-answer sheet, and one hostile mock. Every number you say will match the page the panel is holding.

What is a project deep dive round, and what should you expect?

A project deep dive is an interview where you lead. You walk a panel through one past project, usually in 30 to 60 minutes, and they interrupt to test your decisions, your role, and your numbers. Published formats differ on length, audience, and slides, so confirm the format with the recruiter instead of assuming one.

Only a few employers publish their own guidance. The rest is reported by third parties. The table below gathers what is documented.

A few details change how you prepare:

• The project can come up twice. At Ashby it appears first in an intro call with an engineering leader, then again in a final round with the VP of Engineering and another engineering leader. Ashby says you are welcome to use the same project throughout.
• The project should be your hardest. Hiro asks for the most complex, challenging, or impactful project you have worked on.
• The round may not exist for your role. Meta's retrospective is reported as optional, used only for certain teams and roles. One guide lists it as a "0-1 round" in the E6 loop.
• You may have to write something first. One HubSpot candidate reported having to submit a doc about a project before a one-hour technical deep dive.
• Expect "why" again and again. A Databricks deep-dive interviewer is described as walking through your past projects and continuing to ask "why?"

Official guidance from Meta, OpenAI, Stripe, Dropbox, and HubSpot could not be found. Treat everything about those companies as secondhand and check it with your recruiter. Employer pages also change, so open the current version of any page you rely on rather than trusting a summary of it.

Why the round exists

Ashby explains the format as a replacement for simulations, which it says give "extremely artificial time constraints and little context." That reasoning should shape your preparation. The panel wants to see real decision-making, so your record of why you chose things matters more than your architecture diagram. Candidates who spend their prep polishing the diagram usually prepared the wrong part.

The behavioral pivot

The round does not always stay technical. In one Robinhood report, only the first 2 to 4 questions were about the project, and after that the interviewer switched to standard behavioral questions. Nobody has published how often this happens. Plan for it anyway, because the cost of preparing is small.

What do interviewers assess, and how does it change by level?

Panels assess how you gathered information, made decisions, weighed trade-offs, and handled setbacks on real work. They read your level mostly from which project you chose, before you answer a single question. No employer has published a scored rubric that changes between junior, senior, and staff levels, so anything more precise than that is guesswork.

Here is what the published guides say gets assessed:

• Ashby: how you gather information, make decisions, plan work, and deal with time constraints or setbacks.
• Hiro: the trade-offs or options you considered in the design, why you made the final choices, and the stakeholder and communication side of the work.
• Meta TPM (third-party): basic software concepts, end-to-end functionality, and dependencies and trade-offs.

The guidance on level is thinner but points in one direction:

• Meta E6 is described as needing evidence of architectural decisions that affected multiple teams.
• E7: in a Blind thread, a respondent warned an E7 candidate that choosing the hands-on coding project "will get you down leveled to E6". Respondents preferred the project with more scope, even though it was less technical.
• New grads: one source says to cut the gloss and give details.

What these show is that scope signals level, and detail signals competence. A senior candidate who brings a narrow, code-heavy project has made a level claim before saying anything about it.

Why scope matters most at staff level

At staff level there are few candidates, and project scope is what separates them. In Refolk's index of professional profiles, 33,066 people currently hold the title Staff Software Engineer in the United States, against 182,832 Senior Software Engineers.

The pool is also concentrated geographically. In a 25-profile sample of UK Staff Software Engineers in Refolk's index, 12 (48%) were in London or the London Area. In the matching US sample, 5 of 25 (20%) were in San Francisco.

To be clear about the limits: the index shows how small the staff pool is. It does not show how panels score candidates. The claim that a staff candidate stands out mainly through project scope is my inference from the small pool combined with the E6 and E7 guidance above. It is not a measured result.

How do you pick the project? The scored selection table

Score every project you could plausibly present on four criteria: ownership, complexity, recency, and how close its level is to the target role. Choose the one that wins clearly. If two projects tie, choose the one you can draw in four to six boxes, because a project you cannot explain within the slot loses to a smaller one you can.

Each criterion tells the panel something specific, and each can mislead you:

• Ownership shows you made the decisions. It misleads when you were present for the decisions but did not make them. Ask yourself whether you could explain the alternatives that were rejected.
• Complexity shows you can handle hard problems. It misleads when the complexity is just background: many systems, little you decided about them.
• Recency shows your skills are current and your memory is reliable. Coditioning says recency matters less than depth of ownership, while SlideShare advises focusing on one recent project. My view is that ownership should outweigh recency, with recency used to break ties, because older work is harder to rebuild accurately from memory.
• Level match shows you work at the scope of the target role. It misleads when a project sounds large but your part in it was small.

If the employer works the way Ashby does, you can send the hiring manager a couple of ideas, each with a one or two sentence description, and let them choose. Use your top two from the table below.

Project: ____________________
Ownership (x2):    0 = present for it | 1 = owned a part | 2 = owned the key decisions
Complexity:        0 = routine | 1 = one hard problem | 2 = several linked hard problems I decided on
Recency:           0 = records gone, memory thin | 1 = partial records | 2 = recent, well documented
Level match:       0 = below target | 1 = at target | 2 = at or above target, with cross-team decisions
Diagram fits in 4 to 6 boxes?  Yes / No
Total: ____ / 10
One-line pitch for the hiring manager: ______________________________________

The step-by-step procedure

Allow about 8 to 12 hours in total, based on the time estimates for each step below. The rebuild step varies the most. Done well, the last step leaves you with no surprises left.

When you ask about the format, ask about reuse specifically. If the project you bring to the final round already came up in a shorter intro call, the final panel may have notes from that call. Any number that changed between the two conversations will be visible to them.

How do you rebuild the project, split I from we, and handle confidential work?

Rebuild only from records that were legitimately yours or that are public, and attach a source to every number. Then mark every sentence as "I" or "we", and turn anything confidential into percentages and general patterns. Each claim you plan to make should carry five things before it goes into the walkthrough.

Records you may use

• A personal brag document or work log kept while you were employed. Julia Evans's brag document post and The Pragmatic Engineer's work log template are the best-known formats for these.
• Performance reviews you were legitimately given and kept.
• Public artifacts your former employer published itself.
• Memory. It is the legally safest source and also the least reliable one.

One performance-review guide warns that without a log, "you're forced to reconstruct months of work from memory, and research shows that people systematically forget their own contributions." Some degree of rebuilding from memory is normal. Write down what you remember before you start looking for anything to confirm it, and mark any figure you cannot source as approximate.

Two questions have no published guidance: whether you can use offer or bonus letters to back up a metric, and whether you can cite public release notes or conference talks. Under the US Defend Trade Secrets Act, part of what makes information a trade secret is that it is "not being generally known or readily ascertainable through proper means." That makes material your former employer published itself the safer category. Still, no guide addresses this directly, so read your own confidentiality agreement before you rely on it.

Splitting "I" from "we"

Coditioning lists defaulting to "we" as a consistent failure mode. Four of the seven prep guides tallied below probe for personal versus team contribution. Go through your rebuilt notes one sentence at a time:

1. Label each sentence I, we, or they.
2. For each we, write a sentence that names your part: "The team shipped the migration. I designed the cutover plan and chose to run both systems in parallel because rollback had to take minutes."
3. For each I, ask whether you could defend it if the panel asked who else was involved. If not, change it to we and name your part.
4. Keep a few honest they sentences. Saying who made the calls you disagreed with shows you understood the whole project.

Confidential and NDA-bound work

The documented practice is to generalize names, figures, and specifics:

• Give percentages, not absolute figures.
• Leave out internal project codenames and roadmap details.
• Describe the client by industry and size, not by name.

Tell the panel at the start that you are generalizing. One source suggests saying that you cannot share the client name or the exact proprietary algorithm, but that you can walk through the architecture patterns, the trade-offs you evaluated, and the performance results you achieved. Two cautions apply. Do not share trade secrets, customer names, or specifics that would damage a current or former employer. Leaking also counts against you directly, because the interviewer may wonder whether you would share their company's data in a future interview. No regulator or employer has published a standard on this.

Reconciling numbers with the page the panel holds

If you tailored your resume for this application, the version the panel holds may not match your master copy. Reconcile against the version you actually submitted. Refolk tailors the resume to each posting, so the version attached to this application is the one to check every spoken figure against. If you redacted a figure to a percentage in the walkthrough, make sure the resume line does not show the absolute number. A panel that sees both will ask which one is true.

How do you build the timed opening and the probe-answer sheet?

Keep the opening to one third of the slot or less and build it around one diagram of four to six boxes. Then write the next two questions for every major claim, starting with trade-offs, your role, and failures. Most of the round is the probing, so most of your preparation should be too.

PracHub recommends an opening of about five to seven minutes. CopilotInterview says you talk for roughly the first 10 to 15 minutes of a 45 to 60 minute round. Either way, the opening is a small share of the time:

• 30-minute slot: opening of no more than 10 minutes.
• 45-minute slot: no more than 15 minutes.
• 60-minute slot: no more than 20 minutes, and closer to PracHub's figure is better.

Ending on what you would change does two things. It answers the question Jacob Kaplan-Moss includes in his interviewer question set ("What would you do differently next time?"), and it gives the panel an easy place to start, which usually leads to the trade-off questions you prepared best for.

Which probes to prepare first

No one has published how often each probe comes up across a defined sample of candidates. The tally below is my own count of probe categories across seven named prep guides: CopilotInterview, Medium, Prepfully's Databricks guide, Coditioning, Hiro, DarkInterview, and Kaplan-Moss. Use it as a place to start, not as a frequency study.

PracHub's rule for the sheet is to prepare the next two questions for every major claim. The template below puts that into a fixed format.

CLAIM: ______________________________________
Resume line it matches: ______________________
Source: brag doc / kept review / public artifact / memory (approximate)
Owner: I / we (my part: ____________________)

Probe 1 (why): Why did you choose this over the alternatives?
Answer: Options were ____ and ____. I chose ____ because ____. The cost was ____.

Probe 2 (what else): What else did you consider, and why did you drop it?
Answer: ____ was rejected because ____. If ____ had been true, I would have picked it.

Failure probe: What went wrong, and what did you do about it?
Answer: ____ broke / slipped. I noticed by ____. I fixed it by ____. Since then ____.

Change-now probe: What would you do differently?
Answer: I would ____ , because I now know ____.

Behavioral tie-in: conflict story ____ / ownership story ____ (same project)

The last line of the template is there for the behavioral pivot. If the panel moves to behavioral questions after a few probes, you can stay with the same project and answer with stories they can check against the details you have already given them.

How does a project deep dive go wrong?

Most deep dives fail for one of eight reasons. Each one has a recognisable sign and a check you can run before the call. Picking the wrong project for your level and claiming the team's work as your own are the two that do the most damage, because no answer can fix either one during the round.

1. Picking for scope rather than level. The project is too hands-on for the level you are applying at. The sign: lots of code detail and no decisions that crossed teams. The check: compare it with the E7 thread, where a respondent warned that the hands-on coding project would lead to a down-level. If your target is staff, at least one decision in your opening should have affected another team.
2. A project too complex for the slot. One candidate described a project that was "both too difficult to explain (too many systems involved and background) and not technically impressive enough." The sign: your first five minutes are all context. The check: if the diagram will not fit in four to six boxes, present one slice of the project or pick another.
3. "We" inflation. You claim the team's results as yours. The sign: every outcome is "I" and no one else appears in the story. The check: for each sentence, ask whether you could say "I" and defend it if asked who else did the work.
4. Rebuilding from copied files. You restore metrics from documents you took when you left. The sign: figures more exact than anything you could remember or source legitimately. The check: every source was legitimately yours or public. A copied file can create a breach-of-confidence record even if no one ever finds out.
5. Over-sanitizing. You redact so much that no measurable impact is left. One resume guide warns that filler like "worked on secret project" without context raises red flags. The check: every redacted figure still has a percentage, a direction, and a baseline.
6. Rehearsing only the monologue. The sign: your mock was a run-through of the opening, not questioning. The check: the mock spent at least two thirds of its time on probes.
7. Being caught off guard by the behavioral pivot. As in the Robinhood report, the questions turn behavioral after 2 to 4 probes. The check: you have a conflict story and an ownership story from the same project, written on the probe sheet.
8. Fabricating or embellishing the project. One source is blunt: "You will get destroyed by a competent interviewer when they probe into your story." The check: every claim in the stack has a source, even if that source is approximate memory marked as approximate.

Panels read your level from the project you chose before you say a word about it.

Two less obvious false positives are worth knowing. A smooth mock with a friendly peer is not evidence that you are ready. It only shows you can deliver the opening. And a project that matches the posting's keywords perfectly can still be the wrong pick if your part in it was narrow, because a panel checking ownership will find the narrow part within a few questions.

How do you run the hostile mock and keep the work current?

Run one mock where a peer interrupts you, keeps asking why after your prepared answer runs out, and spends at least two thirds of the session on probes. Then confirm the checklist below before the call. After the round, update your brag document so the next deep dive starts from a written record instead of memory.

Give your peer a short brief:

• Interrupt within the first two minutes, the way Ashby's interviewers stop candidates for questions along the way.
• Ask "why?" at least three times in a row on one decision, the way a Databricks interviewer is described as doing.
• Ask for one rejected alternative, one failure, and one thing you would change.
• At some point, switch to a behavioral question about conflict or ownership on the same project.
• Write down every question you could not answer cleanly.

Each question you could not answer cleanly becomes a new block on the probe sheet. Run the questions again, not the whole mock. One full hostile mock is the minimum, and a second only makes sense if the first one exposed a gap in the project choice itself.

Keeping it current

The deep dive is easier the second time if the first one leaves a record behind. After the round, write down which probes came up and which answers held. Then add any new numbers or new decisions you remembered to your brag document. When you apply to the next role, keep the figures in the tailored resume identical to the ones you defended. Refolk tailors each version from your own history, so a number you corrected once stays corrected in every later version instead of drifting back. If the next employer publishes its own format page, as Ashby and Hiro do, read the current version before you start step one. These pages change, and the format you prepared for last time may not be the one you face now.