What makes a pipeline safe to re-run?
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.
The situation behind the question
Interviewers ask this because it happened to them.
A task failed halfway through a run. The on-call engineer wants to re-run it, and nobody in the channel is sure whether that is safe.
A strong answer
Flags
Green flags
- Builds re-runnable pipelines as a default, not as an advanced feature.
- Names the clock and mutable dimensions specifically as sources of non-determinism.
- Knows that merging needs a genuinely unique key and can say what happens when the key is not unique.
- Connects idempotency to the ability to repair, which is the reason it matters.
Red flags
- Says re-running is safe because the task is stateless, without looking at what it writes.
- Proposes a delete-then-insert with no atomic publish, leaving a window where consumers read nothing.
- Cannot name a source of non-determinism in a SQL transformation.
- Treats idempotency as a streaming concern only.
Follow-ups
Where the conversation goes if the first answer holds up.
- The merge key is not unique. What happens, and how would you find out before it matters?
- The transformation joins a dimension that changes daily. Is it still deterministic? What would make it so?
- How do you make a delete-then-insert safe for a consumer reading concurrently?