How to prepare for a project deep dive

The project deep dive is the round where interviewers find out how much of your CV you really understand. It starts innocently, with "walk me through a project you're proud of", and then keeps going: why it was built that way, how a component works underneath, what happened when it broke, what you'd change. Somewhere in that sequence, everyone reaches the edge of what they know. The round is designed that way.

This guide covers what a technical deep dive interview is, how to choose the project you'll talk about, how to structure the walkthrough, and how to prepare for the follow-ups that make up most of the round.

What a technical deep dive interview is

A technical or project deep dive is a conversation, usually 45 to 60 minutes, about your past work and the fundamentals the job relies on. There's no set problem to solve. Instead, the interviewer picks a thread (a project on your CV, a technology in the job description, an incident you mention) and keeps pulling it.

It goes by several names: project deep dive, technical deep dive, past project interview, experience interview, or simply "technical discussion". Some loops make it a separate round; others fold it into a hiring manager conversation or the start of a system design round.

The interviewer is usually looking at four things:

Depth. How the tools and systems you've used actually work, not just their names.
Ownership. What you personally designed, built, or debugged, as opposed to what the team did.
Reasoning. Whether you can work toward an answer from first principles when memory runs out.
Debugging. Whether you have a systematic path from symptom to cause.

Reaching the limit of what you know is expected. What they're watching is how you behave when you get there.

Choosing your project

You'll usually get to choose, so choose well. A good deep-dive project is one where:

You worked on it closely, not as a distant contributor.
There were real decisions, with alternatives you considered.
Something was hard: scale, a tricky bug, a migration, a disagreement about the design.
You can explain the architecture end to end, including parts you didn't build yourself.
It's reasonably recent and relevant to the job. A project from last year that uses the stack in the posting beats an impressive one from a decade ago.

Prepare two projects, not one. The interviewer may want something different from your first choice ("do you have something with more scale?"), and a second project gives you room.

Walking through the project

"Walk me through a project you're proud of" is an invitation, not a request for a monologue. Aim for a three-to-five-minute overview, then let the interviewer steer. A structure that works:

The problem. What the system was for, who used it, and why it mattered. One or two sentences.
Your role. What you owned, and the size of the team.
The architecture. The main components and how data flows between them. Sketch it if you can share a drawing.
The hard part. The most interesting technical challenge, and how you approached it.
The outcome. What happened, with numbers if you know them, and what you'd do differently.

Like a behavioural story, it needs a clear "I". "We used a queue between ingestion and processing" is fine for the architecture; "I proposed the queue because the processing step was slowing down ingestion during peaks" is what shows your part. The structure in the STAR method for software engineers works for the narrative parts of a deep dive too.

Three levels deep

Expect the interviewer to go two or three levels down on anything you mention. Roughly:

What you used. "We used Postgres with a read replica."
How it works. "How does replication work there? What does a read from the replica see right after a write?"
What it costs, or how it fails. "What happens to your application if replication lag grows to a minute? How would you know?"

A good way to prepare is to go through your project and, for every technology and design decision, write down an answer at each level. For example, for "we added an index to speed up the lookup":

Level 1: what kind of index, on which columns, and why.
Level 2: how the index works (a B-tree, say), and why it makes that lookup fast.
Level 3: what it costs on writes and storage, when the database might not use it, and how you confirmed it helped.

You won't predict every question, but the exercise shows you where your understanding is solid and where it's borrowed, while there's still time to fill the gaps.

Common follow-ups

These come up in some form in most deep dives:

"Why did your team choose that over the alternatives?"
"What would break first if traffic grew ten times?"
"What was the hardest bug you hit on this project? How did you find it?"
"What would you change if you built it again today?"
"What part of this system did you not work on? How does it work?"
"You mentioned a cache. How did you handle invalidation?"

Prepare a specific answer to "what would you change?" for each project. It's asked almost every time, and a thoughtful answer shows you've learned from the work rather than just done it.

Debugging questions

Many deep dives include a debugging scenario: "The p99 latency doubled after a deploy. Where do you look first?" There's no single right answer; the interviewer wants a methodical path.

A shape that works:

Clarify the symptom. All endpoints or one? All users or some? Sudden or gradual?
Check what changed. The deploy is the obvious suspect. What was in it? Can you roll back?
Look at the signals. Metrics, logs, and traces: where is the time going?
Form a hypothesis and test it. "If it's the new query, I'd expect database time to have grown on those endpoints."
Fix, then prevent. The immediate fix, then what would catch it earlier next time.

The best preparation is a real incident you worked on. Practise walking through it step by step: what you saw, what you checked, what you got wrong at first, and what fixed it.

Sometimes your best project is under a confidentiality agreement, or involves details you shouldn't disclose. That's common, and interviewers are used to it. You can still go deep:

Abstract the domain. "A system that processes financial transactions for business customers" says enough without naming the client.
Round or relabel the numbers. "Tens of thousands of requests per second" is fine; you don't need the exact figure.
Keep the engineering specific. The architecture, the decisions, the tradeoffs, and the incidents are what interviewers want, and they rarely need confidential detail.
Say what you're doing. "I'll keep the client anonymous, but I can go into as much technical depth as you like" sets expectations and shows professionalism.

What doesn't work is staying vague about the engineering because the business is confidential. If you can't talk about a project in technical depth at all, choose a different one.

Saying "I don't know" well

You will reach the edge of your knowledge. The worst response is a confident guess; interviewers can usually tell, and they'll keep asking until the guess falls apart. A much better pattern:

"I'm not sure how that database handles it internally. My expectation is that it would have to take a lock on the row, because otherwise two writers could both see the old value. If I needed to know for certain, I'd check the documentation on its isolation levels and test it with two concurrent transactions."

That answer is honest, reasons from what you do know, and says how you'd find out. Interviewers generally respect it far more than a bluff.

How to prepare

Choose two projects and write a three-to-five-minute walkthrough for each.
Go three levels deep on every technology and decision in them.
Prepare "what would you change?" and "what was hardest?" for each.
Review the fundamentals in the job description, especially anything listed that you haven't used recently. Our guide to preparing from the job description covers how to find them and how to handle gaps between the posting and your CV.
Rehearse one incident from symptom to cause, out loud.
Practise with someone who keeps asking "why?" and "how does that work?". The point is to find your edges before the interview does.

If your loop also has a system design round, the preparation overlaps: the building blocks you explain in a deep dive (caches, queues, replication) are the ones you'll design with. Our 45-minute system design framework covers that round.

Hardmode's technical deep dive round tailors its topics to the stack and seniority in the job description, asks about the projects on your CV if you add one, and keeps pulling the thread until it finds where your understanding thins out, so you know what to review before the real interview.