Data engineering interview

Tests: Whether the candidate can distinguish two workloads by their physical shape rather than by convention, and whether they will defend the simple option when it is genuinely correct.

Tests: Whether the candidate understands what a file format stores beyond the values — layout, statistics, encodings — and can explain what those let a reader skip.

Tests: Whether the candidate treats this as a question about where compute lives and what history is retained, rather than as a fashion.

Tests: Whether the candidate treats partitioning as a cardinality budget rather than as a rule, and — more importantly — whether they ask anything before answering.

Tests: Whether the candidate can distinguish work that scales with rows from work that scales with objects, and whether they recognise a problem that adding compute cannot solve.

Tests: Whether the candidate can state a grain precisely, verify it rather than assume it, and recognise the specific way a mixed grain produces a confidently wrong number.

Tests: Whether the candidate recognises that this is a history-modelling question rather than a query problem, and whether they know what it costs and when it becomes impossible.

Tests: Whether the candidate recognises a governance problem wearing the costume of a bug, and whether they can decompose the gap before arguing about it.

Tests: Whether the candidate can name the specific properties that make a re-run produce the same result, and whether they recognise that idempotency is a precondition for ever fixing anything.

Tests: Whether the candidate understands what each mechanism can and cannot observe, and whether they know the specific way a timestamp-based extract loses rows.

Tests: Whether the candidate can name the specific property a durable partitioned log provides that the alternatives do not, and whether they will decline it when nothing needs that property.

Tests: Whether the candidate separates event time from processing time and can state a lateness policy rather than describing whatever their tool happens to do.

Tests: Whether the candidate can decompose the phrase into the three places it might apply and name the assumption that buys each one.

Tests: Whether the candidate reasons about partitions, shuffle and skew rather than about cluster size, and whether they can explain why more workers changed nothing.

Tests: Whether the candidate can separate the obligation to produce correct data from the obligation to measure it, and whether they treat quality as engineering rather than as diligence.

Tests: Whether the candidate knows the difference between schema compatibility and consumer compatibility, and whether they can hold a nuanced answer under pressure to say yes or no.

Tests: Whether the candidate knows that meaning can change without structure changing, and whether they can name the mechanisms and the checks that would catch them.

Tests: Whether the candidate distinguishes upstream debugging from downstream impact analysis, and whether they know the coverage limits of any lineage they have.

Tests: Whether the candidate separates fixing the code from repairing the history, and whether they treat a backfill as a production change with capacity and blast radius rather than as a re-run.

Tests: Whether the candidate treats duplicates as normal transport behaviour, chooses the right key, and can name the duplicates their approach will not catch.

Tests: Whether the candidate knows that a run failing loudly and a consumer seeing a broken state are independent problems, and can name mechanisms for making a publish atomic.

Tests: Whether the candidate derives the target from a consumer decision rather than from current performance, and whether they know which clock the check should read.

Tests: Whether the candidate reasons about drivers rather than about totals, and whether they attribute before optimising.

Tests: Whether the candidate can tell a naming convention from an architecture, an organisational model from a technical one, and can price each before adopting it.

Tests: Whether the candidate recognises a data migration disguised as a configuration change, and whether they know what makes vectors from two models incomparable.

Tests: The domain's thesis. Whether the candidate knows that a task status reports on a process and not on rows, and whether they can name the checks that would say something about the rows.