Quiz: The Data Engineering Career
Twelve questions. Answers with explanations follow — work through them first.
1. §40.1 traces four eras of the job — distributed systems, big data, modelling, and today's. What does it say has been constant?
- A. SQL
- B. The need to move data between systems
- C. Somebody has to be able to say what a number means and whether it is right
- D. Cost pressure
2. §40.2 expresses levels as the question you are trusted to answer. Which is the senior one?
- A. How do I build this?
- B. Is this built correctly?
- C. Should this be built?
- D. What should we be building?
3. Reading the "judged on" column downward — a code review, a design review, the outcome, other teams' outcomes — what does the progression describe?
- A. Increasing technical difficulty
- B. A move from your work, to the result of your work, to other people's results
- C. Increasing seniority of the reviewer
- D. Increasing scope of the codebase
4. §40.3: what is the most common career stall in this field?
- A. Refusing to learn new tools
- B. Getting better at the mid-level job and expecting a senior title — being twice as fast at building components is not evidence about outcomes
- C. Specializing too early
- D. Avoiding on-call
5. §40.3 lists four kinds of senior evidence. Which does it call the strongest, and which almost nobody has?
- A. A system you designed
- B. A performance improvement with a number
- C. A thing you did not build, with a written reason
- D. A postmortem you wrote
6. §40.5's track chart is asserted to have a specific property, checked by the self-check. What?
- A. Every track scores at least 3 on demand
- B. No track dominates another — otherwise it would be advice rather than a trade-off
- C. The scores sum to the same total
- D. Streaming scores highest overall
7. Streaming scores 5 on technical depth and 5 on on-call burden. §40.5 says these are:
- A. Independent properties that happen to coincide
- B. The same fact — a system that processes events continuously fails continuously, and the interesting problems are interesting because they happen at 3am
- C. A scoring artifact
- D. True only for open-source streaming
8. §40.9: a team with a catalog (+2) and cost attribution (+2) that says "we don't really have incidents" (−5) and where most engineering time is unplanned (−5) scores −6. What is the point?
- A. Catalogs are not worth building
- B. The cheap signals are visible on a tour and the expensive ones cannot be bought — and good signals require sustained effort while bad ones are the resting state
- C. The weights are arbitrary
- D. Four signals are too few to judge
9. §40.11 splits skills into durable and perishable. What is the distinguishing rule?
- A. Age — anything over ten years old is durable
- B. Open source versus proprietary
- C. The durable list is mostly properties and the perishable list is mostly products
- D. Whether it appears in job postings
10. Case Study 1: two engineers spent the same four years on the same Hadoop cluster, and one transferred while the other left the field. What differed?
- A. One learned Spark earlier
- B. Which question they were asking while they had the experience — "how does this tool behave?" versus "why is this slow?"
- C. One had a better manager
- D. One worked harder
11. Case Study 2: cycle 2 shipped 14 models and a 40% build-time improvement and was declined; cycle 3 shipped 6 models and was promoted. What separates the two?
- A. Cycle 3's work was more technically difficult
- B. Cycle 2 improved something the team had decided to do; cycle 3 changed what the team decided to do
- C. Cycle 3 had better visibility
- D. The criteria changed
12. §40.10 finds that being on call, writing postmortems, and reviewing others' designs compound, while courses and certifications do not. What is the distinguishing property?
- A. Cost
- B. Whether the learning is attached to a system you are responsible for
- C. Whether it is technical or theoretical
- D. Duration
---
Answers
1 — C. Somebody has to be able to say what a number means and whether it is right.
The tooling changed completely across all four eras — MapReduce to Spark to SQL-and-YAML — and the custody did not. This is the reason the field is durable even though its tools are not: the infrastructure keeps getting easier and the custody does not. SQL (A) is remarkably durable and is still an instrument rather than the constant.
2 — C. Should this be built?
The full progression: junior how do I build this · mid is this built correctly · senior should this be built · staff what should we be building · principal what will we need in two years. Note that senior is the first level where the answer can be "no," which is most of what distinguishes it.
3 — B. From your work, to the result of your work, to other people's results.
A junior is judged on whether the code is good; a staff engineer is judged on whether three other teams shipped. That is uncomfortable and it is the actual bargain — and it is why a staff engineer's best work is often invisible: the migration that did not happen, the mesh not adopted, the ordering guarantee nobody bought.
4 — B. Doing more mid-level work faster.
The strategy that got you here is precisely the one that stops working, because the two levels are judged on different things. Case Study 2's cycle 2 is the worked example: 14 models, 3 pipelines, and a 40% build-time improvement — genuinely good work, and all of it evidence for a level already held. Doing your current job excellently is the default strategy, is genuinely valuable, and is not evidence about the next one.
5 — C. A thing you did not build, with a written reason.
"We scoped this, found the consumer had stopped using the report, and deleted the request." The other three are a decision you changed, a problem you found that nobody asked about, and someone else's work that got better because of you. All four are less visible than shipping, which is why they must be recorded as they happen — at review time you will remember what you shipped and not what you prevented, because shipped work leaves artifacts and prevented work leaves nothing.
6 — B. No track dominates another.
If one did, the chart would be advice rather than a trade-off and §40.5's argument would be false — so the self-check asserts it across all pairs, treating demand, portability, and depth as "more is better" and on-call and obsolescence as "less is better." The practical use is to read the two columns that do not appear in job postings: on-call burden and obsolescence risk.
7 — B. The same fact.
A system that processes events continuously fails continuously, and the technically interesting problems — watermarks, state, out-of-order delivery, idle partitions — are interesting precisely because they manifest at 3am. You cannot take the depth without the pager, and people routinely try. This is why §40.5 frames on-call burden as a lifestyle decision disguised as a technical one.
8 — B. The cheap signals are visible and the expensive ones cannot be bought.
A catalog can be bought and populated by a crawler; cost attribution is a tagging exercise. A reconciliation requires knowing what "right" means; a named incident with a timeline requires having had one and learned from it; a deletion requires measurement and organizational permission. The asymmetry is the finding: good signals require sustained effort and bad ones are the resting state, so a team that has done nothing scores negative — which is correct, and is why "they seem fine" is weak evidence.
9 — C. Properties versus products.
SQL (1974), dimensional modelling (1996), idempotency, partitioning, reconciliation (1494), and distributed systems fundamentals (1978) are properties. Hadoop, Hive, a specific orchestrator, a specific streaming framework, and a cloud's product names are products. The operational test is "if this product disappeared tomorrow, what would I still know?" — and it explains why learning Airflow teaches DAGs, retries, idempotency, and backfills (all of which survive Airflow) while learning its operator zoo teaches nothing that does.
10 — B. Which question they were asking.
The colleague asked "how does this tool behave?" and became excellent at Oozie's XML quirks, the Cloudera Manager screens, and the version matrix — all real expertise, all product facts, all gone at once. The engineer asked "why is this slow?" and learned partitioning, shuffle, skew, and data locality, which transferred to systems that did not exist yet. The transferability of experience is decided by which question you were asking while you had it, not by which technology you had it on — and the uncomfortable corollary is that you are choosing this right now and will not find out for years.
11 — B. One improved a decision, the other changed one.
Both were unrequested initiative and both were valuable. Making the nightly build 40% faster improves something the team had already decided to do; establishing that a requested real-time dashboard was not needed changes what the team decides to do, which is the boundary between the levels. The first is more satisfying, more measurable, and more clearly yours — a 40% improvement is a number and "we did not build it" is an absence, which appears in no system that tracks output.
12 — B. Whether it is attached to a system you are responsible for.
Being paged for a pipeline you own teaches that pipeline's failure modes permanently, because the memory is attached to consequence; a course on streaming teaches a vocabulary that decays unless used within weeks. This is not an argument against courses — they are excellent for acquiring a vocabulary you are about to need — but against them as a substitute for responsibility, which is how they are most often used, because responsibility is uncomfortable to ask for and a course is easy to enroll in. The one-line version: ask to own something you are slightly not ready for, and make sure it pages you.