How do you find out what a change will break — before you make it?
Whether the candidate distinguishes upstream debugging from downstream impact analysis, and whether they know the coverage limits of any lineage they have.
The situation behind the question
Interviewers ask this because it happened to them.
A team wants to rename a column in a widely used model. The last time something like this happened, eleven dashboards broke and two of them broke silently.
A strong answer
Flags
Green flags
- Understands lineage as a debugging and change-management tool rather than as documentation.
- Insists on column-level and on generated rather than maintained.
- Names what lineage does not cover, and treats coverage as a number to measure.
- Uses query logs as a second source of evidence about who actually reads a column.
Red flags
- Says the catalog has lineage without knowing whether it is column-level or what it parses.
- Plans the rename as a single atomic change with no deprecation window.
- Assumes anything not in the lineage graph does not exist.
- Cannot say how they would detect a consumer that broke silently rather than loudly.
Follow-ups
Where the conversation goes if the first answer holds up.
- What does a silent break look like, and which of your checks would notice it?
- The lineage tool does not parse the BI layer. How do you close that gap?
- How long should the deprecation window be, and what evidence ends it?