The Project Deep Dive Interview: How to Walk a Panel Through Your Work

You know the project better than anyone in the room. That can make this interview harder to prepare for. You have months of context in your head; the panel has a few sentences on your resume. Your job is to give them enough context to follow a choice, then enough detail to judge your part in making it.

The round goes by several names: a project deep dive, a retrospective, an experience discussion or a technical presentation. The useful preparation is much the same. Bring one project, explain the problem, and be ready to go several levels below the headline. The interviewer can ask about a decision you thought was ordinary, or a setback you hoped to skip.

Do not assume that every company runs it the same way. Ashby's published guide, updated July 25, 2025 and checked October 25, 2026, describes a candidate-led conversation, with questions along the way and optional slides. It asks for business context as well as technical detail. Its shorter introductory discussion and longer final round can use the same project.

OpenAI's public guide, checked October 25, 2026, says the interview format varies by team. It does not promise one standard project round or deck format. Candidate accounts for OpenAI, Anthropic, Meta and Stripe also vary. Use your recruiter's instructions for the time, audience and materials. Practise explaining the work either way.

Sources checked October 25, 2026: Ashby’s past projects guide and OpenAI’s interview guide.

Start with two possible projects. For each, write the problem, your responsibility, one hard choice, one miss and the result. Pick the one where you can give a concrete answer to every item. The largest project on your resume is not automatically the strongest. You may have had more judgement and responsibility on a smaller one.

Prefer work that reached users or an internal team and that you stayed with long enough to understand the result. A plan that never shipped can show reasoning, but leaves you guessing about its effects. A project where someone else chose the approach may still be useful if you can name the decisions you owned within it.

Ashby's guide warns that routine CRUD work, unreleased work and coordination-heavy stories can leave little to assess. It also cautions against migrations without meaningful business-driven decisions. That is a selection test, not a ban on a project name. A migration story needs to explain the customer problem and the choices, not just the old and new tools.

Anonymise when needed. Replace names, round sensitive numbers and say that you have done so. Keep relationships intact: which team owned what, how the baseline compares with the result, and what constraint limited your options. Do not reveal confidential customer data to make an example sound more convincing.

Prepare a two-minute opening before preparing the longer version. Say what the project was for, what part was yours, the choice that mattered most and what came of it. This gives the listener a map. In a longer walkthrough, expand the problem, the team, the constraints and the sequence without hiding the outcome until the last sentence.

For example: our billing process was failing too many invoices. I owned the cutover plan and data migration, with two engineers. I chose to move regions separately rather than switch every account at once. That meant maintaining both paths for longer. Failed invoices fell from 3 percent to 0.4 percent. Those are fictional practice facts, but notice how each sentence gives the interviewer something to test.

Leave space between parts. If the interviewer interrupts, finish the thought briefly and answer the question they asked. You do not need to defend your planned order. A useful return is: that was the trade-off; the next thing that happened was the first regional rollout. It reconnects the detail to the story without restarting it.

End by handing over: that is the overview; where would you like to go deeper? Then wait. Do not fill the silence with a second project. The opening has done its job when the interviewer knows what happened and can choose where to probe.

First, decisions. Pick the choice that changed the project. Name at least one real alternative, why you rejected it and the cost of the option you chose. A trade-off has two sides. Saying a tool was faster gives a benefit; saying it made support harder gives the cost. Explain who had the decision and who challenged it.

Expect a depth question. An engineer may be asked how the migration stayed consistent during cutover. A designer may be asked how a test separated preference from task success. A seller may be asked how the buying group changed the deal. Explain the mechanism in your field's language, then check that the listener has the context.

Second, what broke. Name a real miss, how you discovered it and what you did next. In the fictional billing example, a support ticket exposed a rounding bug that double-charged 212 accounts. The useful answer goes beyond fixing the code: why did the checks miss it, and what changed so that a similar error would be caught?

Third, numbers. Give the measure you chose before starting, the baseline and the result. Be precise about percentage points versus percent change. Explain what else changed at the same time. An honest limit on attribution is more useful than claiming the whole business result for your project.

Fourth, hindsight. Choose one thing you would change and explain why it was not the right or available choice then. Then show what the lesson changed in later work. “Communicate more” is hard to assess. “I added a support review before the next pricing test because the first test reached customers before support knew” gives a behaviour and a reason.

“We” is appropriate for shared work. The problem is using it for every decision. A panel cannot tell whether you chose the approach, implemented one part, coordinated the rollout or watched a team do it. Give credit precisely. Say what the team did, then what you personally decided or changed.

Try this distinction: the team built the migration; I proposed a regional rollout, compared it with a single cutover and took the extra maintenance cost to the lead. Another engineer designed the reconciliation check. That answer does not claim sole ownership. It lets the panel understand the boundaries of your contribution.

Managers need the same precision. Owning the work through other people does not mean claiming their design decisions. Explain the goal you set, what you delegated, where you intervened and the difference your intervention made. If you inherited a good plan, say what was already there before describing your contribution.

Level is an interpretation of evidence, not a reward for a large number or a familiar employer. A person can describe the same project as a well-executed task, a problem they framed and owned, or a change that made several teams more effective. The account has to support the scope claimed.

At mid-level, the evidence may be an owned component, sound choices within known constraints and a reliable local fix. At senior, it may include framing a team problem, deciding among uncertain options, bringing partners along and preventing a class of failures. At staff, it may include a problem across teams, competing priorities, a shared approach and effects that last beyond one delivery.

Manager and director evidence adds how work happened through people: the goals, the delegation, the decisions kept or handed off, and the change beyond an inherited team. Titles differ between companies. Use these signals to improve what your answer makes visible, not to claim that one interview proves your job level.

A level read should point to the words that support it and explain what was absent. A shorter screen offers less evidence than a full round. If the interviewer never reached the numbers, that absence alone does not show that you cannot measure impact.

Imagine the notes after you leave. Can the reader name the project, your part, a decision with its cost, a failure you handled and a measured result? Can they explain why the work mattered without retelling every meeting? That is a better rehearsal target than a perfectly polished speech.

Separate a concern from a judgement about character. “Could not name who chose the rollout” describes missing evidence. “Lacks ownership” leaps past it. In practice feedback, look for the observed behaviour and a specific way to repair the answer. You can add a decision boundary; you cannot act on a vague label.

Use five headings: In two minutes, The decisions, What broke, The numbers and Looking back. Under decisions, write the choice, options, reason, cost and who decided. Keep each item short enough to glance at. A brief is a recall aid, not a script to recite.

Mark gaps before rehearsing. If you cannot remember the baseline, find a permitted source or say what you do know. If the decision belonged to someone else, write their role. Do not fill gaps with plausible details. A follow-up will make an invented detail harder to maintain, and it changes the story you are trying to tell.

Practise three clocks. In two minutes, make the four pieces clear and end on the outcome. In a short screen, add the main decision and hindsight. In a full round, let the interviewer spend time on a mechanism, a failure or the numbers. Learn the facts and the choices well enough to change order.

Star Interview's project deep dive gives you those three formats: a 45-minute round, a 20-minute screen and a five-minute pitch drill. The interviewer takes a field lens from your role and project. The full report adds a decision record, an evidence-based level read and a brief you can copy. The pitch gives notes on the pieces of your opening. Use the next attempt to fix one missing piece, then listen to whether it comes through.