Key Takeaways: The Data Engineering Interview

The one thing

Data engineering interviews have a distinctive shape and the shape is learnable: heavier on system design and SQL, lighter on algorithms, and with one round that barely exists elsewhere — data correctness. That round has no LeetCode, and Parts IV and V of this book are the preparation.

The rubric

 25%  requirements clarified before designing
 20%  a defensible choice with a stated trade-off
 20%  failure modes named and handled
 15%  correctness: idempotency, ordering, exactly-once scope
 10%  cost and scale reasoned about with numbers
 10%  the architecture diagram

The diagram is 10%. Most candidates spend most of their time on it.

🎓 Six questions in the first five minutes, and the fifth — does history change? can yesterday's number move? — is the one that marks you out, because it distinguishes a data pipeline from a service.

And the answers must visibly change the design. "Because you said hourly rather than real-time, I'm going to use a batch micro-load, which removes the watermark problem entirely" is the sentence the 25% is for. Asking six questions and designing as if you had not is worse than not asking.

The sentences that score

🔎 Name the downside of your own choice. The pattern, used three or four times per round, fifteen seconds each:

"<choice>, because <requirement it satisfies>,
 at the cost of <specific operational downside>,
 which means <who is affected and what they need to do>."

The last clause is what reads as senior — an organizational consequence of a technical choice.

Short phrases carry more than long explanations, because they could only come from experience:

"alert on remaining slack rather than on the breach"
"with a deterministic tie-break"
"keyed on the run's logical date"
"because it's invisible"          <- the strongest

Saying why a failure is hard to detect separates reading about a problem from chasing one.

⚠️ And "I'd add monitoring" scores as nothing, because every noun is generic. Monitoring what, alerting whom, at what threshold? Announce the shape before the list — "four things, and they need different answers" — which signals a taxonomy rather than a list and stops you trailing off after two.

💸 Ninety seconds of arithmetic, out loud, with assumptions stated, ending in what it implies. The rubric asks whether you reason in cost, not whether you compute correctly — Case Study 1's candidate had a wrong number and scored 8 of 10, because they finished with "so I would not optimize this."

The take-home

💸 Four hours of yours is fifteen minutes of theirs. Five companies is half a working week.

Do at most two at a time · reuse your capstone deliberately and say so · decline the unbounded ones by offering a four-hour version, because the answer to that offer is itself information.

Spend the last hour on the README, which is what a reviewer with fifteen minutes reads. "What I left out and why" is the highest-signal section, because a reviewer cannot otherwise distinguish deliberate scope from an incomplete attempt.

Live coding is the same round with observation added: narrate · write the wrong thing first and say so · ask about the data, not the algorithm ("can customer_id be null here?" — it is almost always yes) · and say what you are stuck on, which usually gets you the answer and costs less than twenty seconds of silence.

SQL

🧪 The round tests whether you notice the awkward rows, not whether you know window functions: the customer with no orders · the cancelled order · the same SKU on two lines · two orders on one day · the refund settling in another month.

The eight that come up: every X including those with no Y · more than one X per Y per day · top-N per group · a running total · the gap between consecutive events · X that never had a Y · attributing a value to the right period · a rate in integer arithmetic.

Two separate mid from senior:

ROWS versus RANGE — they differ when the ordering column has duplicates, RANGE includes every peer row, and most candidates do not know their engine's default (it is RANGE).

NOT EXISTS, not NOT IN — a single NULL in the subquery makes NOT IN return no rows at all, silently, and an empty result looks like a correct answer.

And say your assumptions out loud. The ambiguity is usually deliberate.

Correctness

⚠️ Do not answer this round like a software engineer.

software instinct          data answer
"it's idempotent"          "delete-and-insert by partition, keyed on
                            the run's logical date"
"validate at the edge"     "quarantine it, keep the row, page if the
                            queue grows"
"add a test"               "add an assertion on the DATA, and reconcile
                            against something INDEPENDENT"
"canary it"                "shadow-run both and diff row by row"

Software answers protect the system; data answers protect the numbers. A canary tells you the new code does not crash and nothing about whether it computes the same values.

The sentence that signals you know the difference: "the failure mode I care about is the one where everything is green and the number is wrong."

The project

🎓 The capstone beats a certification because it is checkable. Five things ready: a one-paragraph description · the reconciliation sentence (the headline, and almost nobody has it) · one number you can defend · what went wrong · what you would do differently.

"What went wrong" has five parts, and the fifth is the one candidates omit: what you believed · what happened · the cause · what you changed · what it cost you. A failure with no cost attached is one you have not fully understood.

Expect the follow-up "how would you have caught it sooner?" — and answer with a method, not a resolution to be more careful.

Behavioral answers need a number. "412 alerts a quarter to 31" is engineering; "we cleaned up the alerting" is effort.

The reverse interview

🔎 Ask questions whose answers you have thought about, and apply one test: could the answer have been bad?

⚠️ The four most commonly recommended questions all fail it. "What's the tech stack?" is identical at a company running one DAG and four hundred; "what would my first 90 days look like?" asks for an intention, which is free.

The bank that works:

"how many pipelines, and how many dashboards?"   the fastest single signal
"what did the last person in this role do?"
"what happened in your last data incident?"      "we don't have any" -> nothing
                                                  is monitored
"who is on call, and how often does it page?"
"what share of engineering time is unplanned?"
"what is the last thing you deleted?"            the highest-yield one

🔎 "What is the last thing you deleted?" cannot be prepared for · requires knowing what is unused · and requires organizational permission to remove it, which is usually what you actually want to know.

🎓 The pipelines-to-dashboards ratio is fast, concrete, and hard to answer misleadingly. Ask the trend too, and ask who builds new dashboards — if it is the data engineers, the ratio will not improve regardless of intent.

And when a company describes the job as fixing a problem, ask what happens to the problem while you fix it. If it continues and you keep handling it, the fixing is what gets deferred — the urgent thing has a requester, a deadline, and visible completion; the important one has none of the three.

Write your decline rule before you need it. A reverse-interview list with no decline rule is a list whose answers you will read and rationalize.

Rejection and the funnel

🏭 A single rejection is nearly uninformative; a pattern across four or five is diagnostic.

failing the SCREEN   a specific technical gap, fixable in weeks
failing the DESIGN   structure, not knowledge -- usually requirements
failing the FINAL    often levelling or an internal candidate

The third is misread most, because it hurts most and arrives last. A final-round rejection after four strong rounds is frequently a levelling decision, and the right response is to ask whether a different level is open — which people almost never do.

Do not optimize against a sample of one.

📏 Roughly 40 applications → 12 screens → 8 technicals → 4 loops → 2 offers. Two offers is a successful search and 38 rejections. The widest cut is the first, it is least related to engineering ability, and an hour on a referral is worth more than an hour of LeetCode — which is uncomfortable and true.

Levelling

Level is set by scope, not years: a mid engineer builds what they are asked to build · a senior decides what should be built · a staff engineer changes what the organization builds.

Interview at your level and one above. Under-levelling is far harder to correct after joining.

And take the reverse interview seriously enough to walk away. The cost of a wrong job is a year, which dominates any negotiable difference — and Case Study 2's eleven months were knowable in forty minutes.

The code

code/interview_drills.py — twelve SQL problems on a deliberately awkward seven-order fixture, each with the expected answer and the common wrong ones with their causes; the design rubric with weights; and the reverse-interview bank with what each answer means. Forty-two self-checks.