Before you save an edit to a shared step block, a case repository shows the list of cases that reference it. What do you do with that list, and what does it fail to tell you?
answer
- reach is not consequence
- computed from stored pointers only
- copies never appear on it
- setup rows and assertion rows count the same
- a sampling frame, not a sign-off
basics
~10 sRead the list for owners outside your team and for cases where the block carries the assertion, not the setup. It shows reach, not consequence: it cannot see pasted copies or open runs.
solid answer
~50 sThe impact list is computed from stored pointers, so it is an accurate answer to a narrow question: *which case definitions reference this block right now*. Use it to spot cases owned by other teams, and to sample cases where the block supplies the expected result rather than the preamble. What it does not answer is the question you actually care about — **what breaks**. It counts cases uniformly whether the block is incidental setup or the whole point of the case; it does not show runs already generated and in flight; it never shows the cases that pasted a copy of the block instead of referencing it, which are exactly the ones that will now say something different; and it says nothing about automation or documentation keyed to that wording. Treat it as a starting set to sample, not a verdict.
go deeper
Know that the repository can list which cases reference a shared block, and that you should read that list before saving an edit rather than after.
Explain where the list comes from — the stored pointers — and why that means pasted copies of the same steps can never appear on it.
Demonstrate the triage: separate cases where the block is incidental setup from cases where it supplies the expected result, sample rather than read everything, and notify owners outside your team before you save.
Frame reach against consequence as a standing rule for the team, including who is accountable for blocks that cross team boundaries and what notification a cross-boundary edit requires.
## What the list actually is The list shown before you save is the **reference index inverted**: the repository knows which case definitions store a pointer at this block, so it can enumerate them. That makes it exact about one thing and silent about everything else. It answers *who points here*, not *who is harmed*. That distinction is the whole skill. A list of two hundred cases feels alarming and may be entirely benign — two hundred cases whose sign-in preamble gains a consent dialog all want that change. A list of three cases can be the dangerous one, if in those three the shared block carries the expected result the case exists to check. ## How to read it before you save 1. **Scan for owners outside your team.** A block that crosses a folder or project boundary means people who are not in this conversation will see different steps tomorrow. That is a notification, not a veto. 2. **Classify by role, not by count.** For each cluster of cases, ask whether the block is *setup* (navigate, sign in, seed) or *substance* (the action under test and its expected result). Edits to substance are a different kind of change and deserve a different treatment. 3. **Sample, do not read everything.** Open a handful across the clusters — the oldest, the one from another team, the one with the most recorded history — and check that the edited wording still makes sense inside them. Shared blocks accrete callers whose context the block's author never saw. 4. **Check the timing.** Saving into a quiet week is different from saving while cycles are running against those cases. 5. **Decide the strategy, then save.** Either this is a clarifying edit that everyone wants, or it is a change of behaviour that should be a new block with cases repointed deliberately. ## The four blind spots - **Pasted copies are invisible.** The index only knows about pointers. Every case that copied the block's rows instead of referencing it keeps the old wording and will not appear on any list, ever. These are the most dangerous cases in the estate precisely because they are the ones that will now disagree with everybody else and nothing will report it. - **Runs already in flight are not case definitions.** The list enumerates definitions. Whether an execution already generated from one of them moves with your edit depends on when the repository materializes the step list, and the impact list is not the place that tells you. - **Weight is uniform.** Every row counts one. A case that merely signs in and a case whose only assertion lives in the block look identical on the list, and the second is where an edit does real damage. - **Everything outside the repository.** Automation that follows the same script, a runbook that quotes the step wording, a training deck, an onboarding checklist, a defect report that cites step four by its text — none of it is in the index. ## What a good reviewer does with it Treat the list as a **sampling frame**, not a sign-off. The concrete moves are: - Post the intended change and the affected-owner list before saving, so that the people who will inherit it can object while objecting is cheap. - Where the block supplies an expected result, prefer a new block and a deliberate repoint over an in-place edit, so each case's move is its own dated event in that case's history. - Search the repository's case text for the old wording as well as reading the index — that is the only way pasted copies surface, and finding them is an opportunity to convert them into references. - After saving, spot-check two or three of the sampled cases as rendered, rather than trusting that the block reads correctly in isolation. ## The judgment being tested An interviewer asking this is checking whether you know that **a tool-computed impact list is a mechanical fact, not an assessment**. Candidates who say "the tool shows me what is affected, so I check the list and save" have accepted a count as a risk assessment. The strong answer separates the two: the repository can tell you reach exactly, because reach is a graph query over data it owns; consequence lives in what those cases mean, in copies the graph cannot see, and in everything downstream of the repository that quotes the same words. That part is yours, and no product will compute it for you.
- The impact list is two hundred cases across four teams. Does that stop you saving?Not by itself — size is not risk. If the block is a sign-in preamble and the edit reflects a real change to sign-in, all two hundred want it. What stops me is finding cases where the block carries the assertion, or owners who would be surprised. Then I notify, or split the change into a new block and repoint.
- How would you find the cases the impact list cannot see?Full-text search the case corpus for a distinctive phrase from the block's step text. Hits that are not in the reference list are pasted copies carrying the old wording. Each one is a decision: convert it into a reference, or leave it with a note saying why it deliberately differs.
saying these in an interview costs you the question
- Treats the impact list as a completed risk assessment
- Assumes copies of the block appear in the list
- Judges risk by the number of affected cases alone
- Forgets automation and runbooks that quote the step text
- Saves during an active cycle without checking who is running