Further Reading: The Data Engineering Interview

Sources are tagged Tier 1 (confident it exists, recommended without reservation) or Tier 2 (real and worth seeking, but confirm the current edition, version, or URL yourself).

A warning specific to this chapter, and it is a strong one. Interview-preparation material is the most commercially motivated literature in this book's bibliography. Much of it is sold by people whose product is the preparation, which creates a systematic bias toward making the process look more learnable, more standardized, and more gameable than it is. It also dates quickly and varies enormously by company and by year.

Read it accordingly, and weight practice far above reading. The single highest-return activity in this chapter is Exercise 39.11 — a mock loop with another person — and no amount of reading substitutes for it.

For the system design round

Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly, 2017). Not an interview book, and the best preparation for a data system design round that exists. The chapters on replication, partitioning, transactions, and consistency are the vocabulary the round is conducted in. If you read one book before interviewing, read this one — and note that it will also make you better at the job, which most interview material will not. Tier 1.
Chapters 3, 4, 11, 29, and 34 of this book. Architecture principles, distributed systems, the warehouse-versus-lake decision, streaming's four questions, and the layer boundaries. §39.4's worked answer is assembled from these five.
Alex Xu, System Design Interview (vols. 1–2). Widely used, and written for general software system design rather than data. Useful for the format — how to structure 45 minutes, how to manage a whiteboard — and substantially off-target on content for a data role, where the questions are about correctness and history rather than about request throughput. Tier 1 for format; skim for content.
Anything careful on requirements elicitation. §39.3's first 25% is a requirements skill, not a design skill, and the requirements-engineering literature is better on it than any interview guide. The transferable idea — a stated requirement is usually a proposed solution — is Chapter 29 Case Study 2's. Tier 2 — one chapter suffices.

For SQL

code/interview_drills.py in this chapter. Twelve problems whose wrong answers are enumerated with their causes. Do them against your own engine, because §39.6's window-frame question has a different answer in different databases.
Your database's documentation on window functions, specifically the frame clause. ROWS versus RANGE versus GROUPS, and what your engine's default is when you omit it. It is RANGE in standard SQL and in most engines, and this is the single most common silent wrong answer in a SQL round. Tier 1.
Anything on three-valued logic and NULL semantics. The NOT IN failure (§39.6) is one instance of a general property, and understanding UNKNOWN properly prevents several bugs at once — in NOT IN, in CHECK constraints, in != against a nullable column, and in aggregate functions. Tier 1 — most SQL references cover it; read the section deliberately rather than absorbing it.
Practice sites with a data slant — anything offering realistic multi-table problems rather than puzzles. The distinguishing feature to look for: does the data contain awkward rows? A practice set where every join is clean is practising the wrong thing. Tier 2 — the specific sites change; the criterion does not.

For the correctness round

Parts IV and V of this book. Chapter 20 (idempotency, SCD2, the deterministic tie-break), Chapter 23 (assertions), Chapter 24 (backfills), Chapter 26 (incidents), Chapter 29 (late data and watermarks). This round has no external preparation material worth naming, which is exactly why it discriminates.
Chapter 36 Case Study 1 and Chapter 38 Case Study 1. Reconciliation independence, and four failed reconciliations. "How do you know your pipeline is right?" is answered from these two.

For the behavioral round

Anything on structured behavioral interviewing, from the interviewer's side rather than the candidate's. Understanding what the interviewer is instructed to probe for — specificity, ownership, and what you changed afterwards — is more useful than memorizing STAR. Tier 2.
Your own incident write-ups. §39.9's best source. If you have written postmortems (Chapter 26), you already have the material, and a postmortem converts into a behavioral answer almost directly: timeline, actions, outcome, and what changed.

For the reverse interview

Chapter 25 §25.12, Chapter 30 Case Study 2, and Chapter 33 Case Study 1 of this book. Measuring usage, reviewing against usage, and unattributed spend. The reason "what is the last thing you deleted?" is diagnostic is that all three capabilities are required to answer it.
Anything on evaluating engineering culture from outside — the "questions to ask your interviewer" genre. Most of it fails §39.10's test (could the answer have been bad?), and reading it with that test in hand is a useful exercise in itself. Tier 2.
Public engineering blogs and incident write-ups from the company you are interviewing with. A company that publishes postmortems is telling you something no interview answer can, and it gives you a specific, informed question to ask — which is worth more than any generic one.

Practice, which is most of it

Run a mock loop. Exercise 39.11. With another person, scored against the rubric, with feedback that includes "was there a moment where you were not sure I had done this?"
Interview someone. The fastest way to learn what the rubric is measuring is to sit on the other side of it once.
Do the twelve drills against your own engine. Exercise 39.4, and check your window-frame default.
Write the five trade-off sentences. Exercise 39.6 — and notice which technologies you cannot complete the sentence for. Those are ones you have used and not operated, which is worth knowing before someone else finds out.
Interview a company you are not going to join. Exercise 39.13. Uncomfortable, and it calibrates the reverse-interview list at no cost.

A note on what to be skeptical of

Any claim that data engineering interviews are standardized. They vary more than general software interviews, because the role varies more — Case Study 2's entire subject.

Any preparation plan heavy on algorithms. The algorithm round is frequently absent and rarely decisive. Preparation time is better spent on the correctness round, which almost nobody prepares for.

Any advice to "be enthusiastic" or "show passion." It is unfalsifiable and it displaces specifics. Three moments where the interviewer thinks "they've done this" are worth more than an hour of enthusiasm, and they are all short sentences.

And any source that treats the interview as one-directional. §39.10 and Case Study 2: eleven months were spent discovering something knowable in forty minutes, and the questions that would have surfaced it are neither clever nor hard to ask.