This guide helps reviewers evaluate whether the candidate demonstrated senior-level data engineering judgment for a CDC-driven lakehouse workflow.
The assignment is intentionally not about building a wide analytics project. It is about whether the candidate can reason about:
- source modeling quality
- CDC correctness
- replay and recovery
- schema evolution safety
- validation parity
- historical reconstruction
- warehouse snapshot correctness
- dataset discoverability
Use this rubric to assess both the implementation and the pull request description.
Look for:
- correctness before tooling preference
- explicit data contracts and invariants
- safe failure on schema incompatibility
- durable change retention
- clear distinction between lake history and warehouse snapshot
- thoughtful validation design
- easy-to-follow platform flow
Do not over-index on any specific tool choice if the reasoning is sound.
You may score each category on a 1–4 scale:
- 1 — Weak
- 2 — Mixed / Partial
- 3 — Strong
- 4 — Exceptional
A strong submission will usually score mostly 3s, with one or two 4s in areas such as CDC design, schema safety, or validation rigor.
- 3 to 10 tables with realistic structure
- strong and weak entities
- sensible keys and relationships
- appropriate use of data types
- indexes that match likely access/change patterns
- clear constraints and invariants
- source schema resembles a realistic transactional domain
- strong vs weak entities are clearly identified and justified
- primary and foreign keys are sensible
- currency, dates, enums/statuses, and nullable fields are modeled intentionally
- indexes are not arbitrary; they support access patterns or CDC workflow assumptions
- important business rules are documented
- flat or unrealistic schema with little relational thinking
- tables exist mainly to satisfy the count requirement
- no clear strong/weak entity distinction
- missing keys, weak relationships, or under-modeled constraints
- indexes absent or added without rationale
- Does this look like a real transactional source system?
- Are relationships and entities modeled intentionally?
- Are constraints doing useful work, or merely storing fields?
- clear definition of how changes are captured
- inserts, updates, and deletes all handled
- durable replay/restart story
- duplicate/retry awareness
- lake and warehouse fed from a coherent CDC design
- candidate explains exactly what a “change” means in their design
- restart/replay behavior is explicit
- deletes are not ignored
- duplicate events or reprocessing are handled safely
- checkpoints, offsets, or extraction boundaries are defined
- design makes near real-time warehouse availability believable
- CDC is described vaguely as periodic refresh
- no delete handling
- no replay story
- duplicate events could corrupt history or snapshot
- near real-time claim unsupported by design
- If ingestion restarts mid-run, what happens?
- Can this design avoid losing or duplicating changes?
- Is the warehouse derived in a way that is consistent with the lake history?
- every change captured in the lake
- append-oriented or immutable design
- enough metadata to reconstruct change history
- durable historical record
- operation type, timestamps, keys, and ordering/version metadata are preserved
- lake model supports full audit of source changes
- lake is clearly distinct from curated warehouse outputs
- append-only semantics are visible in both design and tests
- lake is effectively just another snapshot table
- updates overwrite history
- missing metadata makes reconstruction difficult
- lake and warehouse roles are blurred
- Can every source change be recovered from the lake?
- Is the lake truly historical, or just another transformed layer?
- What information would be needed for replay or audit, and is it present?
- warehouse exposes latest snapshot
- design supports moving backward in time / restore
- historical reconstruction story is credible
- downstream model is understandable
- latest-state tables are clearly defined
- temporal, versioned, or SCD-style logic is used thoughtfully where helpful
- candidate explains how point-in-time restore works operationally
- warehouse logic preserves correctness under late or repeated changes
- warehouse only has current snapshot with no restore story
- time travel is hand-waved without data model support
- current-state logic could drift from CDC history
- update ordering assumptions are unclear
- Can I reconstruct prior state from this design?
- Is the warehouse really usable for restore / time-based recovery?
- Does the warehouse reflect latest state consistently?
- explicit detection of incompatible source changes
- ingestion stop behavior
- clear warning/failure signaling
- safe handling of non-backward-compatible schemas
- candidate identifies concrete compatibility rules
- breaking change detection is automated or clearly validated
- ingestion fails closed rather than silently drifting
- warnings or alerts are surfaced in a reviewable way
- schema contract is documented clearly
- schema evolution is ignored
- pipeline keeps running after breaking changes with undefined behavior
- no clear definition of what counts as incompatible
- failure signaling is vague or absent
- Would this pipeline stop safely on a dropped or renamed column?
- Is schema drift visible quickly?
- Does the candidate think in terms of contracts, not just happy-path ingestion?
- source validations carried into warehouse checks/models
- both system and business rules considered
- failures surfaced clearly
- parity documented, not implied
- not-null, uniqueness, referential, and domain rules are checked
- business rules are restated downstream intentionally
- validation logic is automated through tests/assertions/checks
- failures are made actionable
- warehouse assumes source is always valid
- only superficial row-count checks exist
- business validations omitted entirely
- no traceability from source rule to warehouse assertion
- Are downstream consumers protected from invalid source states?
- Did the candidate mirror the important source assumptions?
- Could validation drift over time, or is it explicit?
- both lake and warehouse are exposed in a discoverable way
- metadata is useful
- ownership and intended use are clear
- schema descriptions or data contract information exist
- lake and warehouse datasets are named and described clearly
- metadata includes schema, purpose, and update cadence
- consumer access path is documented
- candidate distinguishes operational data exposure from curated analytics exposure
- catalog requirement acknowledged but not addressed meaningfully
- no metadata beyond file/table names
- unclear which datasets consumers should use
- lake and warehouse access expectations are muddled
- Could a downstream user discover the right dataset easily?
- Is there enough metadata to understand what each dataset is for?
- Is access/documentation aligned with the modeled layers?
- clear separation of schema, ingestion, transformation, validation, and metadata concerns
- code/SQL/pipeline logic that is easy to follow
- maintainable repository structure
- minimal unnecessary complexity
- repository layout mirrors the data platform flow
- transformations and validations are separated clearly
- ingestion logic is understandable
- tests and configs live in obvious places
- naming makes the pipeline easy to reason about
- all logic mixed together in a few scripts
- no separation between raw, modeled, and validated data
- hard to see where invariants are enforced
- structure appears accidental rather than deliberate
- Can another engineer extend this without re-learning everything?
- Are responsibilities clearly separated?
- Is the flow from source to catalog easy to follow?
- tests for CDC correctness
- tests for schema change failure
- tests for latest snapshot correctness
- tests or assertions for historical reconstruction
- evidence of Red, Blue, Green discipline
- inserts, updates, deletes, duplicates, and replay are all tested
- incompatible schema changes are tested explicitly
- warehouse correctness is asserted against change history
- validations are executable, not merely described
- candidate explains important missing tests if time constrained
- only happy-path pipeline run tested
- no schema change tests despite assignment emphasis
- no delete/history validation
- little confidence in correctness under failure or replay
- Do the tests prove the important platform behaviors?
- Is there confidence in correctness after restart or schema drift?
- Are the most failure-prone paths explicitly checked?
The candidate clearly understands CDC reliability, schema contracts, and temporal data design.
Lake, warehouse, validation, and schema safety reinforce one another well.
The solution is coherent, pragmatic, and well-structured.
There may be simplifications, but the correctness story is convincing.
There are solid ideas, but one or more critical areas are underdeveloped, such as schema safety, replay, or validation parity.
The submission behaves more like a simple ETL refresh than a reliable CDC-based data platform.
History, schema change safety, or correctness guarantees are weak.
Reviewers should watch for these:
- lake stores only current state instead of every change
- warehouse snapshot logic is not clearly derived from CDC history
- deletes ignored
- replay/restart behavior undefined
- incompatible schema changes not detected or not blocking
- warehouse validations weaker than source assumptions
- no credible restore/time-travel story
- catalog requirement addressed only superficially
When in doubt, prioritize:
- CDC correctness and replayability
- safe handling of incompatible schema changes
- full change retention in the lake
- correct latest snapshot and restore logic in the warehouse
- validation parity with source rules
- maintainable layering
- breadth of tooling last
A modest solution that is deeply correct should outrank a broader but fragile one.