Quiz: The Data Engineering Interview

Twelve questions. Answers with explanations follow — work through them first.

1. §39.3's rubric weights the architecture diagram at:

  • A. 40%
  • B. 25%
  • C. 10%
  • D. 50%

2. Six requirements questions open a design round. Which does §39.3 call the one that marks you out?

  • A. How much data?
  • B. How fresh does it need to be?
  • C. Does history change — can yesterday's number move?
  • D. What exists already?

3. Asking the six questions is necessary and not sufficient. What else must happen?

  • A. They must be asked in the first five minutes
  • B. The answers must visibly change the design
  • C. They must be written down
  • D. The interviewer must answer all six

4. In Case Study 1, both candidates chose CDC. What separated the scoring?

  • A. One named a specific tool and the other did not
  • B. One named the downside of their own choice — a replication slot that can fill the source's disk — and who gets paged for it
  • C. One drew a better diagram
  • D. One had used Debezium

5. Candidate B answered "what can go wrong?" with "I'd add retries and alerting; I'd monitor it." Why did this score 4 of 20?

  • A. It is factually wrong
  • B. Every noun is generic — it names categories rather than making decisions, and is indistinguishable from having read a blog post
  • C. It was too short
  • D. Monitoring is not part of the rubric

6. §39.6: the SQL round is testing what?

  • A. Whether you know window functions
  • B. Query performance
  • C. Whether you notice the awkward rows — the customer with no orders, the cancelled order, the same SKU on two lines, the refund settling in another month
  • D. Whether you can write CTEs

7. Why does NOT IN (SELECT ...) fail when the subquery contains a NULL?

  • A. It raises an error
  • B. x NOT IN (1, NULL) evaluates to UNKNOWN rather than true, so no rows are returned — and the failure is silent
  • C. It returns all rows
  • D. It only fails in some engines

8. §39.7 contrasts software instincts with data answers. Which pairing is correct?

  • A. "It's idempotent" → "add a canary"
  • B. "Add a test" → "add an assertion on the data, and reconcile against something independent"
  • C. "Validate at the edge" → "add retries"
  • D. "Canary it" → "add monitoring"

9. §39.8: what makes a project write-up read as a tutorial rather than an engineering artifact?

  • A. Its length
  • B. The absence of tests
  • C. Reporting only success — and specifically, a "what went wrong" answer with no cost attached
  • D. Using a well-known dataset

10. §39.10 calls one question the highest-yield in the reverse-interview bank. Which, and why?

  • A. "How is the team structured?" — it reveals reporting lines
  • B. "What is the last thing you deleted?" — it cannot be prepared for, requires knowing what is unused, and requires organizational permission to remove it
  • C. "What's the tech stack?" — it reveals maturity
  • D. "What are the biggest challenges?" — it invites honesty

11. In Case Study 2, the company said "we want to get you onto a proper platform." §"Read the Plan" gives three follow-ups. Which does it call the question?

  • A. Who decided that, and when?
  • B. What has been done toward it so far?
  • C. What happens to the forty-one dashboards while I build the platform?
  • D. What is the budget?

12. §39.12: the funnel is roughly 40 applications → 12 screens → 8 technicals → 4 loops → 2 offers. Which stage does the chapter say dominates, and what follows?

  • A. The technical screen; practise SQL
  • B. The first stage — 40 to 12 — which is résumé, referral, and timing, so an hour on a referral is worth more than an hour of LeetCode
  • C. The final round; practise behavioral answers
  • D. The loop; practise system design

---

Answers

1 — C. 10%.

Requirements clarification is 25%, trade-offs 20%, failure modes 20%, correctness 15%, cost arithmetic 10%, and the diagram 10%. Most candidates invert the first and last, and it is the cheapest correction available in this chapter. Case Study 1's candidate B drew the better diagram — scoring 10 of 10 on that line — and lost on every other one, finishing 31 to 89.

2 — C. Does history change?

It is the question that distinguishes a data pipeline from a service, and most candidates never ask it. If yesterday's number can move — refunds, corrections, late events — the whole design changes: the fact table must be incremental with a lookback rather than append-only, a closed month can be restated, and the dashboard needs an as-of date. Case Study 1's candidate B never asked, designed an append-only pipeline, and was invisibly wrong from minute five until the interviewer raised it at minute thirty-eight.

3 — B. The answers must visibly change the design.

Asking six questions and then designing as though you had not is worse than not asking, because it reads as a ritual. The sentence the 25% is for is of the form "because you said hourly rather than real-time, I'm going to use a batch micro-load rather than a stream, which removes the watermark problem entirely." Asking them early (A) and writing them down (C) are both good practice and neither is the point.

4 — B. Naming the downside of their own choice.

"I'd use CDC" is a preference; "CDC because the source is 340 GB and a full extract won't finish, at the cost of a replication slot that can fill the source's disk, so I'd monitor slot lag — and I'd want to know who gets paged when that database's disk fills, because it isn't going to be my team" is an engineering judgment. The last clause is the one that reads as senior: an organizational consequence of a technical choice, and noticing those is roughly what "senior" means. The whole addition takes about fifteen seconds.

5 — B. Every noun is generic.

Retries, alerting, and monitoring are all correct things to have — and "alerting" on what, at what threshold, to whom? The contrast is four short phrases in candidate A's answer that could not be produced by someone who had not run a pipeline: alert on remaining slack rather than the breach · with a deterministic tie-break · keyed on the run's logical date · and "because it's invisible." The last is the strongest and shortest — saying why a failure is hard to detect separates reading about a problem from chasing one.

6 — C. Whether you notice the awkward rows.

The fixture in interview_drills.py is seven orders long and every odd row is deliberate: customer 5 has no orders (LEFT JOIN), order 104 is cancelled (the filter everybody forgets), order 105 has the same SKU on two lines (SUM not DISTINCT), customer 3 has two orders on one day (GROUP BY two columns), and a refund on order 106 settles in April against a March sale (month sold, not month settled). Knowing window functions (A) is table stakes; noticing which rows break the naive answer is the signal.

7 — B. x NOT IN (1, NULL) is UNKNOWN.

NOT IN expands to a chain of <> comparisons ANDed together, and any comparison with NULL yields UNKNOWN rather than true — so the whole predicate is never true and no rows are returned at all. NOT EXISTS does not have this behaviour. Interviewers ask it because the failure is silent: an empty result looks like a correct answer to a question with no matches. It is a five-second habit that prevents it.

8 — B. "Add a test" → "add an assertion on the data, and reconcile against something independent."

The general pattern: software answers protect the system and data answers protect the numbers. The other correct pairings are "it's idempotent" (asserted) → "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"; and "canary it" → "shadow-run both and diff the outputs row by row." A canary tells you the new code does not crash; it tells you nothing about whether it computes the same values.

9 — C. Reporting only success, with no cost attached to the failure.

Interviewers ask about failures specifically to distinguish a project from a tutorial. The weak answer is a small, safe failure ("the config was tricky"). The strong one has five parts — what you believed, what happened, the cause, what you changed, and what it cost you — and the fifth is the one candidates omit and interviewers listen for. A failure with no cost attached is a failure you have not fully understood. Expect the follow-up "how would you have caught it sooner?", which Chapter 38 §38.14 answers with a method rather than a resolution to be more careful.

10 — B. "What is the last thing you deleted?"

Three reasons. It cannot be prepared for — every other question has an obvious good answer a manager can produce whether or not it is true, and this one requires recalling a specific event. Deletion requires knowing what is unused, which requires measuring usage (Chapter 25 §25.12), which almost nobody does. And deletion requires organizational permission, so a team that knows a pipeline is unused and cannot get agreement to remove it is telling you about its politics — which is usually what you want to know and is otherwise very hard to ask about. The follow-up that doubles its value: "how did you know it was safe to delete?"

11 — C. What happens to the existing work while I build the new thing?

The first two follow-ups distinguish an aspiration from a plan, and are worth asking. The third is decisive: the answer is almost always "we'd need to keep them running," which means the job is maintaining forty-one dashboards and also building a platform — with the first having deadlines and the second having none. Case Study 2's engineer built two pipelines and handled sixty-seven dashboard changes in eleven months, and nobody ever chose reporting over the platform; the platform simply lost every individual scheduling decision. The urgent thing has a requester, a deadline, and visible completion; the important one has none of the three — the same ratchet as Chapter 25's alerts, Chapter 30's grants, Chapter 33's idle warehouses, and Chapter 34's layer drift.

12 — B. The first stage.

Going from 40 applications to 12 screens is the widest cut and the one least related to engineering ability — it is résumé shape, referral, and timing. The uncomfortable implication is that an hour spent on a referral is worth more than an hour of LeetCode. Note also what the funnel means emotionally: two offers from forty applications is a normal, successful search, and it contains 38 rejections — which is worth knowing in advance so that ordinary outcomes do not read as failure.