The Project Deep Dive

One project, 20 to 45 minutes of questions: what you built, why, how big it is, what broke and what you would change. Prepared well, it is the round you control.

What this round really tests

Whether you really built what your resume says, and whether you understand it. The interviewer picks one project and goes one level deeper with each answer: how the data arrives, why this tool, how much data, what broke, how you found out, what you would change. With 0–2 years they check that you can explain every part you claim. With 2–4 years they also expect production habits: safe reruns, data checks, monitoring, and a real failure you fixed. Saying "we" for everything, or calling a small tutorial project "big data", ends the round early.

How to prepare

Pick one project and draw it from memory: where the data comes in, where it lands, what runs on a schedule, and who uses the result.
Prepare the six questions: draw the architecture; why this tool and not the obvious other one; how much data, what broke, and how you found out; what you built yourself and what the team built; what you would add if it ran for a year without you; and "show me the repo".
Say "I" for your own work and "we" only for the team’s. If it was a course or a personal project, say so: an honest small project beats a vague big one.
Know your numbers: rows a day, how long a run takes, how late the data can be, what it costs. A rough number with a reason is fine. No number is not.
Have one failure story ready: what broke, how you noticed, and what you changed so it cannot happen again. A rerun that duplicated rows, a schema change and a late file are the common ones.
Clean the repo before the call: a README with a diagram and how to run it, no passwords or keys in the code, one test, and a sample of the output.
Practise the long version out loud in the order shown in The Recruiter & Hiring-Manager Screen chapter, with its three worked examples and its follow-up questions.

At four to eight years: the architecture you owned

The senior version of this round asks what you decided, what it cost, what broke and what you would change. Tell it in about three minutes, with numbers.

Tell it in this order

The problem. What did the business need, and who used the result?
Scale. How much data, how fresh, how many users? Give numbers.
The architecture. From source to user, in one or two sentences.
Your decision. What did you choose, what did you reject, and what did it cost you?
What broke. One failure you led: how you found it, how you fixed it, what you changed after.
The result. Before and after, in numbers, and how you measured them.
Your part. What you owned, who you led or convinced. Say "I" for your part.
What you would change. The weakest part today, and what you would do next.

Have these numbers ready

If you do not know a number exactly, say how you would estimate it. Never invent one.

Rows or events a day, and the size of the data
How fresh the data must be, and how fresh it really is
How many people, teams or dashboards use it
How long a run takes
What it costs a month
How often it failed, and how long recovery took

A worked example

The numbers are made up. This is an example written for teaching, not a real project. Copy the shape, then use your own architecture and your own numbers.

Orders from Postgres into the lakehouse, in minutesChange data capture into Delta Lake, with dbt marts

The problem: Finance and operations saw yesterday's orders only the next morning. A nightly full copy of the orders database fed about 40 dashboards. Operations wanted the numbers within 15 minutes.
Scale: The Postgres database was about 2 TB, with about 3 million changed rows a day. The nightly copy took around six hours and often finished late.
The architecture: Debezium read changes from Postgres into Kafka, keyed by order_id. A Spark Structured Streaming job merged them into Delta tables every five minutes. dbt built the marts on top.
Your decision: I chose the lake with micro-batch MERGE, not a direct stream into the warehouse. Kafka kept seven days of changes, so we could replay a bad day. The cost was many small files, so I added a nightly compaction job.
What broke: One weekend the Spark job and the connector were down for a day. The replication slot kept all the WAL that Debezium had not read yet, and the database disk filled to 90 percent. The DBA dropped the slot to free the space, so we had to take a new snapshot. After that, I added an alert on slot lag. I also agreed with the DBA team to set max_slot_wal_keep_size. Now a stuck reader loses its slot instead of filling the disk, and we re-snapshot from the runbook.
The result: Data was about 10 minutes old at the 95th percentile, down from about nine hours. Stopping the nightly full copy cut its compute. The new jobs added about 2,000 dollars a month. A daily reconciliation against the source matched row counts and order totals.
Your part: I designed it and led two engineers through the build. I convinced the DBA team to allow logical replication, by showing the load test and the slot-lag runbook.
What you would change: I would add a data contract with the source team. Twice, a renamed column broke the merge before we noticed.

Common mistakes

"We" for everything: the interviewer cannot tell which part was yours.
Listing tools instead of decisions: why this tool, and what you gave up for it.
Knowing only the happy path: no answer for a rerun, a late file or ten times the data.
Claiming production scale for a tutorial project.
A repo with no README, secrets in the code, or nothing that runs.

Now rehearse it

Answered questions for this round — each with the short answer, the answer that gets you rejected, and the follow-up.

See all six rounds and the plans, or build something and have it reviewed: a daily orders pipeline or a marketplace model.

Back to Interview Experiences

Openingloading the content…

Prep chapter 07