Your platform team must decide which behaviours may be attached as markers and which stay explicit calls, so where do you draw the line?
answer
- uniform policy, or per-call judgement
- what silent absence would cost
- does it change the result's meaning
- keep the vocabulary small
- ship an explicit escape hatch
basics
~20 sAttach uniform policy that every reader would assume anyway and whose absence fails loudly; require an explicit call wherever the behaviour needs per-call judgement, changes the meaning of the result, or would corrupt data by being silently absent.
solid answer
~50 sDraw the line on three questions. **Is the behaviour uniform?** A boundary or a metric applied identically to every write path is a policy, and a policy belongs on the declaration; anything decided case by case is a judgement and belongs in the code where the judgement is made. **What does silent absence cost?** If a missing behaviour merely loses a metric, a marker is fine; if a missing boundary leaves half a payroll run committed, the behaviour needs something that fails loudly rather than quietly reverting. **Does it change the meaning of the result?** Re-attempting an operation whose second attempt is not safe is not a cross-cutting concern at all — it is a decision about that call. Then govern the outcome: a small vocabulary, an owner per marker, an explicit form of the same behaviour as an escape hatch, and an effective-wiring report so the choice stays inspectable.
go deeper
Recall that attaching behaviour to a declaration is a choice with a cost, not simply the tidy option. Behaviour that differs from call to call usually belongs in the code you can see.
Explain the trade in both directions: attaching buys uniformity and one place to change policy, and spends the call site's ability to explain itself; writing it by hand does the reverse.
Apply the criteria to real behaviour: which of boundaries, retries, checks and metrics you would attach, what you would build first so absence is loud, and where you would insist on an explicit call.
Own the standard itself — the size of the vocabulary, who may add to it, the escape hatch for per-call judgement, and the report that keeps the whole arrangement inspectable rather than remembered.
## What the decision is actually about Both forms produce the same behaviour. What differs is where the reader has to look and what happens when someone forgets. A marker buys **uniformity and one place to change the policy**, and spends **the call site's ability to explain itself**. An explicit call buys **a self-explaining call site** and spends **repetition, which drifts**. A platform standard is not a taste preference between the two; it is a rule for which of those costs a given behaviour may impose on every team in the organisation. ## Three questions that decide it 1. **Is this policy, or is it judgement?** Policy is behaviour that is the same everywhere it applies and that a reader would assume even without seeing it: a boundary on every write path, a duration metric on every handler, the same caller check before every method on an administrative surface. Judgement is behaviour whose correct setting differs per call site. The moment the answer is "it depends on the call", attaching it to a declaration hides the decision instead of recording it. 2. **What does silent absence cost?** Every marker-driven behaviour can go missing without a compiler noticing. Grade the consequence. A lost metric is an annoyance. A lost boundary that leaves a payroll run half-committed is a data-integrity incident. Behaviour in the second category may still be attached, but only with something that makes the absence loud — a build-time check, a test that fails, a startup report that is diffed. 3. **Does the behaviour change the meaning of the result?** Re-attempting an operation changes the caller's contract if a second attempt is not safe to make. A behaviour that alters what a successful return *means* is not cross-cutting, however cross-cutting it looks; it belongs where the caller can see and accept it. ## A working rubric | Behaviour | Uniform? | Cost of silent absence | Where it belongs | |---|---|---|---| | Duration metric on every handler | Yes | A gap in a dashboard | Marker | | Boundary around every write path | Yes | Partial writes | Marker, plus loud absence checks | | Caller check on an administrative surface | Yes | Unauthorised access | Marker, plus loud absence checks | | Re-attempt after a failure | Per call | Duplicated effects | Explicit, unless the operation is safe to repeat | | A fallback value when a dependency is down | Per call | Wrong answers served as right ones | Explicit | The rubric's shape is the point: uniformity decides whether attaching is *possible*, and the cost of silent absence decides what you must build before attaching is *allowed*. ## Governing the standard, not just writing it A rule nobody can apply is not a standard. Four mechanisms make it real: - **Cap the vocabulary.** A reader can hold a handful of markers in their head. Every addition taxes everyone, so new markers should be scarce and argued for, not merged quietly. A codebase with forty behaviour-causing markers has readers who have stopped reading them, and that is worse than any single bad choice among them. - **Give each marker an owner.** Somebody is accountable for what it does, for the report that proves it is in force, and for changing it. Unowned behaviour-causing metadata is how the system acquires markers nothing acts on. - **Ship an escape hatch.** For every attached behaviour, offer an explicit form of the same thing for the cases that need per-call judgement. Without it, teams either abuse the marker where it does not fit or reimplement the behaviour by hand, and both outcomes defeat the uniformity you attached it for. - **Make the wiring inspectable.** A report of which declarations actually receive which behaviour is what lets a reviewer or a responder check the standard against reality rather than against the document. ## The two failure modes of a standard The permissive failure is a codebase where everything is attached: readers cannot predict any call, reviews cannot see behaviour changes, and diagnosing an incident starts with learning a convention. The restrictive failure is the opposite and is less often noticed: policy written by hand at every call site drifts, three sites end up with different settings, nobody can change the policy centrally, and a new call site simply forgets. A standard that only forbids produces the second failure and calls it discipline. ## What a strong answer sounds like Name the trade in one sentence, give the criteria as tests rather than as preferences, put a concrete behaviour on each side of the line and say why, and then talk about governance — vocabulary size, ownership, escape hatch, inspectability. An answer that ends at "it depends on the team" has not made the decision the question asked for.
- How do you keep the marker vocabulary from growing past what readers can hold?Make addition expensive and removal cheap. Require an owner, a stated policy the marker encodes, and evidence that the behaviour really is uniform; publish the full list so its size is visible; and review markers nothing acts on for deletion on a schedule. Growth is otherwise invisible, because each addition looks individually reasonable.
- Why does an attached behaviour need an explicit form of itself as an escape hatch?Because some call sites genuinely need per-call judgement, and without an alternative those teams will either attach the marker where it does not fit or hand-roll the behaviour. Both destroy the uniformity that justified attaching it. Offering the explicit form keeps the marker honest about the cases it covers.
- Would you ever forbid attaching a behaviour that is genuinely uniform?Yes, when silent absence is unacceptable and nothing makes absence loud. A caller check that is uniform in principle but can vanish without a build failure or a report is a security control that depends on nobody deleting a line. Either build the loudness first, or require the explicit call until you have.
saying these in an interview costs you the question
- Says cross-cutting behaviour should always be attached as a marker.
- Says explicit calls are always clearer, so markers are never justified.
- Ignores what a silently missing behaviour would cost.
- Treats a growing marker vocabulary as free for readers.
- Decides by team preference rather than by failure mode.
- Attaches a per-call judgement and calls it a cross-cutting concern.