How do you decide how much of a case's step list belongs in shared blocks, when heavy reuse means one edit ripples into cases several teams own?
answer
- will it change for all callers at once
- a named action, not repeated lines
- impact list of two bought nothing
- cross-team blocks need a named owner
- a block nobody edits has fossilized
basics
~10 sShare a step sequence only when it is one named action every caller would want corrected together. Fragments shared to save typing multiply the ripple surface, and a block nobody dares edit has fossilized.
solid answer
~50 sThe unit worth sharing is a **named business action with a stable expected result** — sign in as an administrator, seed a paid account, restore a clean state — not any repeated pair of lines. Two-row fragments promoted to blocks look economical and are not: each adds a dependency edge while the chance that all callers want the same correction falls. Ask of each candidate: if this action changes, should every caller change with it? Yes means share. Sometimes means it is the wrong seam — split it, or let the odd caller own its rows. The second half of the decision is ownership: a block crossing team boundaries needs a named owner and a way to announce a change, or it fossilizes, because nobody edits a definition whose blast radius reaches strangers. A fossilized block is worse than a copy, keeping the coordination cost with none of the corrections.
go deeper
Know that not every repeated step sequence deserves to be a shared block, and that sharing creates a dependency other people will feel when it changes.
Explain the test for a good seam: one named action with one expected result, incidental to every caller's assertion, that all callers would want corrected together.
Diagnose an existing estate — blocks with one caller, blocks nobody has edited in a year, pasted copies of a block's wording — and say what each symptom implies about the sharing decisions behind it.
Own the tradeoff explicitly: coupling cost against drift cost, plus the ownership and announcement conventions a cross-team block needs. Be able to argue why blanket rules in either direction reliably fail.
## The economics of a shared block A shared block trades **edit cost** against **coordination cost**, and the trade only pays under a specific condition. When an action genuinely changes for everybody, reuse saves you every edit but one, and it saves you the copies you would have missed. When the action changes for one caller only, reuse costs you a conversation, a fork or a divergence argument that copies would never have required. So the question for any candidate block is not "do these rows repeat?" but **"when this changes, will it change for all of them?"** That reframes granularity. A sign-in preamble almost always changes for everybody, because there is one sign-in journey and every case that signs in should follow it. A two-row fragment that happens to appear in many cases — open a menu, click a tab — usually changes for one caller at a time, because it is not an action anybody named, it is a coincidence of wording. ## Where the seams belong Useful heuristics for the boundary of a block: - **It should be nameable in the product's own vocabulary.** *Sign in as an administrator* is a block. *Steps four and five* is not. - **It should have one expected result the caller does not need to look inside for.** If a caller must know what happens midway through the block, the block is spanning two actions. - **It should be incidental to every caller's assertion.** The moment the shared rows contain the thing a case exists to check, an edit to the block changes what that case tests. - **It should be worth a coordination event.** If you would not bother telling anyone before changing it, it does not need to be shared — nobody depends on it in a way you respect. ## The two failure modes | | Over-sharing | Under-sharing | |---|---|---| | what it looks like | dozens of tiny blocks, long impact lists | near-identical preambles repeated everywhere | | the daily symptom | every wording fix becomes a cross-team negotiation | corrections land in some cases and not others | | how it fails | authors stop editing; blocks fossilize | cases quietly disagree about the procedure | | the endpoint | a shared estate nobody maintains | drift nothing reports | The fossilization endpoint deserves the emphasis. A block whose impact list spans three teams and whose owner has left is a block nobody will touch. Authors route around it — they stop referencing it, they paste its rows, they build a near-duplicate. At that point the estate is paying the full coordination cost of sharing and receiving none of its benefit, which is strictly worse than having copied from the start. ## Ownership is half the design Granularity alone does not settle it. A block that crosses a team boundary needs three things or it decays: 1. **A named owner** who can approve a change and is expected to look at the impact list — not a folder, a person or a role. 2. **A convention for announcing edits**, so a change to a cross-boundary block reaches the callers' owners before it lands rather than as a surprise in someone's cycle. 3. **A stated policy on divergence.** When one caller needs the action performed differently, does it fork the block or own local rows? Answer once, so the estate does not accumulate both patterns. Without these, teams reach the same equilibrium every time: the block freezes, and reuse is a story the repository tells about itself. ## Reviewing an estate you inherited The signals that tell you which way an existing estate has gone: - **Blocks with an impact list of one or two.** Sharing bought nothing; inline them and reduce the surface. - **Blocks whose last edit is very old while their callers are active.** Suspect fossilization, and check whether authors have been pasting copies instead. - **Near-identical blocks with sequence-suffixed names.** A fork that was never finished; find out which is current and retire the other once nothing references it. - **Blocks that contain an expected result several callers assert on.** The highest-risk shape in the estate, because a routine edit there rewrites what those cases mean. The defensible position to hold in an interview is that this is a **coupling decision**, identical in shape to any other shared dependency: sharing is right where the callers genuinely want the same future, and wrong where they merely happen to say the same words today. Uniform rules in either direction — share everything repeated, share nothing across teams — are cheap to state and reliably produce one of the two failure modes above.
- You inherit an estate where a third of the blocks have only one referencing case. What do you conclude and what do you do?Sharing bought nothing there — a block with one caller has all the coordination cost and none of the benefit. Usually it means authors were told to share by default. Inline those rows back into their cases and retire the blocks, which shortens the estate and makes the remaining blocks meaningfully mean shared.
- A block referenced by three teams has not been edited in a year while its callers change constantly. What is your first hypothesis?That it has fossilized — the blast radius deters editing, so authors paste copies or work around it rather than change it. I would search the case corpus for its wording to find the copies, then decide whether to give it a named owner and a change convention, or split it per team and accept the duplication honestly.
saying these in an interview costs you the question
- Shares every repeated pair of lines to save typing
- Treats a long impact list as proof the block is valuable
- Ignores who owns a block that crosses team boundaries
- Assumes a never-edited shared block is a stable one
- Applies one blanket rule instead of judging per action