Which assertion catches every unresolved placeholder in a rendered notification message at once?
answer
- Two directions of failure, not one
- Assert over the whole body, generically
- Delimiters, bare slot names, absent-value text
- Also check the subject line
- Seeded values must actually appear
basics
~20 sOne negative assertion over the whole rendered body beats per-field checks: fail if it still contains the message template's delimiters, a bare slot name, or the text an absent value renders as. Then assert the seeded values appear.
solid answer
~50 sA rendered message fails in two directions and a case needs both. The **generic guard** is a single assertion over the entire body: it fails when the body still carries anything belonging to the message template rather than to the recipient — the substitution delimiters, a bare slot name, the literal word a runtime prints for an absent value, or a slot that collapsed to an empty string. Written once as a shared helper, it catches slots added later without anyone editing a case. The **positive half** is the opposite assertion: the values this case seeded — the display name it registered, the reference it created — must appear. A residue-free body can still be one where every slot rendered nothing. Run both on the subject line as well as the body, and attach the rendered body to the failure so the defect is visible without a re-run.
code
pseudocode · 14 linesfunction assertNoTemplateResidue(part, label):
hits = []
hits += findAll(part, OPEN_DELIM + slotNameShape + CLOSE_DELIM)
hits += findWholeWord(part, ABSENT_VALUE_WORDS)
hits += findAll(part, labelFollowedByNothingShape)
if hits is not empty:
fail(label + " carries template residue: " + hits, attach = part)
function checkRenderedMessage(captured, seededValues):
assertNoTemplateResidue(captured.subject, "subject")
for body in captured.bodies:
assertNoTemplateResidue(body, body.kind)
for value in seededValues:
assert captured.contains(value)go deeper
Be ready to say what an unresolved placeholder is and to name more than one shape it takes: raw slot machinery, a bare slot name, and an empty slot. Knowing the failure exists is the floor here.
Explain why a generic assertion over the whole rendered body beats a list of per-field checks, and why absence of residue does not prove the right values rendered. Both halves, and the reason for each.
Show where the guard belongs so it survives growth — inside the shared capture step — and what its failure output must carry for someone to diagnose it without re-running. Talk about scoping a false positive instead of deleting the check.
Own the argument that unbounded negative space cannot be enumerated by cases, so it must be enforced by one shared rule. Be ready to defend the exception list as a small, reviewed artefact rather than a loosened pattern.
A message template is fixed prose with named holes in it — a greeting slot, an order reference, a formatted amount, a single-use link — and a rendering step fills those holes from data before the message is handed to the delivery path. An **unresolved placeholder** is a hole the rendering step did not fill, so the machinery itself reaches the person who opens the message. ## What the residue actually looks like "Unresolved" is not one shape. Rendering can fail in several distinct ways, and a case that only knows one of them has three blind spots: | Residue class | What the reader sees | Usual cause | |---|---|---| | Unrendered slot | the delimiter pair with a slot-shaped name inside it | the rendering step never ran on this body | | Bare slot name | the slot name alone, delimiters stripped | a partial substitution pass | | Absent-value word | the literal word a runtime prints when handed nothing | the slot resolved, the data behind it was missing | | Empty slot | `Hi ,` — a doubled space, a dangling separator | the slot resolved to an empty string | | Escaped machinery | markup characters displayed as characters | double escaping between two rendering layers | This is the most common content defect in notification work and the cheapest one to catch, which is why an interviewer asks *how* you catch it rather than whether you know it happens. ## Why per-field assertions rot The instinctive case asserts that the greeting contains the name it registered and that the body contains the order reference it created. That case is written against today's template, and it has three problems. - **It only sees the slots you thought of.** Someone adds a delivery-window slot next quarter, the data behind it is absent for accounts created a certain way, and every existing case still passes. - **It couples every case to the current copy.** Change a sentence and you edit cases that were never about that sentence. - **It confirms presence, never absence.** "The name is in the body" says nothing at all about the four lines underneath it. The space of things that should *not* be in a rendered body is unbounded, so it cannot be enumerated. It has to be asserted generically: one rule that fails on anything belonging to the template rather than to the recipient. ## The generic guard Write one helper that takes a rendered body and fails on any residue class in the table above. Three rules keep it worth having: 1. **Run it on every captured part.** The subject line, each alternative body of a multi-part email, and the short body of a text-message or push channel. Subject lines are the most often forgotten and the most visible. 2. **Fail loudly.** The failure names the residue class, quotes the offending excerpt with a little surrounding text, and attaches the whole rendered body as a run artefact. A failure that says only "assertion failed" costs a re-run before anyone can even see the defect. 3. **Scope it, never weaken it.** When a body legitimately contains a delimiter character, tighten the pattern to a delimiter pair wrapped around a slot-shaped name. Deleting the check because it fired once is how the guard dies. ## Absence is only half the job A residue-free body can still be wrong: every slot may have rendered an empty string, or rendered a value left over from other data. So the generic guard is always paired with a **positive assertion on values the case seeded itself**. Mint a unique marker for the run — a generated display name, an order reference created by this case — and assert the rendered body carries it. That marker doubles as the way the case identifies its own message when several are in flight, because the value it searches for is one it invented. The pairing is the whole technique: - the generic guard proves nothing template-shaped survived rendering; - the positive assertion proves the right data went in; - neither is sufficient alone, and together they cost one shared helper plus two lines per case. ## Where the assertion lives Put the guard inside the shared step that captures a message, not inside individual cases. Then a new message type inherits it the day someone writes its first case, and a slot added to any template months later is checked without anyone touching a case at all. A check written per field decays as the product grows; a check written once over the whole body compounds. That difference — not the cleverness of the pattern — is what the question is really about. A last practical note: keep a short, documented list of accepted exceptions rather than a looser pattern. If one message genuinely prints the word a runtime uses for an absent value as legitimate prose, name that one message in the exception list, with a comment saying why. The list stays readable, and the guard stays sharp everywhere else.
- Your residue check passes but the greeting line reads "Hi ," — how do you catch that?An empty slot leaves no delimiters and no slot name, so pattern-matching on machinery misses it. Add two things: a shape for a label or greeting followed by nothing before punctuation, and the positive assertion that the seeded display name appears in the body. The second catches it regardless of how the emptiness renders.
- Where should this assertion live so a new message type inherits it automatically?In the shared step that captures a message, not in individual cases. Every case that captures anything then gets the guard for free, a new message type is covered by its first case, and a slot added to any template later is checked without editing case code. Per-case assertions decay; a shared one compounds.
- A body legitimately contains the same delimiter characters the pattern looks for. What do you do?Scope the pattern rather than delete it: match a delimiter pair wrapped around a slot-shaped name, not a single character anywhere. If a specific message genuinely needs an exception, name that message in a short documented exception list with the reason, so the guard stays strict for everything else.
Proofreading a bulk mailing: you do not verify each name by looking for that name, you look for any letter that still opens with the slot instead of a person.
saying these in an interview costs you the question
- Asserts each placeholder individually, so new slots go unchecked
- Treats a residue-free body as proof the values are correct
- Checks only the body and never the subject line
- Fails with no excerpt and no captured body attached
- Weakens the pattern after one false positive instead of scoping it