When would you hang a Postman script on the collection root rather than on a single folder?
answer
- Placement is a blast-radius decision
- The root covers future requests too
- Nothing below records that it inherited
- A request cannot opt out of what it inherits
- Narrowest container that covers the need
basics
~10 sOnly when every request in the collection genuinely needs it. The root's reach is the entire collection, including requests added later, and nothing inside a request hints that the script exists.
solid answer
~40 sPlacement is a blast-radius decision. A script on the collection root runs around every send beneath it — today's requests and every request anyone adds afterwards — and none of those requests records that it acquired the script. A folder narrows that reach to one subtree you can hold in your head, at the cost of repeating the script if two subtrees need it. The default is **the narrowest container that covers the need**: hoist to the root only for something genuinely universal and cheap, and prefer a guard inside one folder's script over duplicating it into many requests. Because inherited scripts stack rather than resolving to one owner, a root script cannot be opted out of from below, so anything at the root has to tolerate every request under it.
go deeper
Know the basic consequence before arguing placement: a script on the collection root runs for every request in the collection, and a folder's runs only for its own subtree.
Explain the mechanics behind the tradeoff — reach follows nesting, coverage of new requests is automatic, and the request itself records nothing about what it inherits.
Argue placement from blast radius and cost: what fails if the shared script breaks, how many sends pay for it, and how a reader of one request would ever discover it.
Own the standard for the team — a default of the narrowest sufficient container, named conditions for hoisting to the root, and root edits reviewed as collection-wide changes.
## The choice being made A script can hang on the collection itself, on any folder, or on a single request, and the runtime runs everything on the path from the root down to the request being sent. That makes placement a design decision with a measurable consequence: **where you attach the script decides how many sends it participates in**, now and in future. The engineering question is not "where is it convenient to put this" but "what am I signing every request beneath this point up for." The root is the maximal choice. Everything in the collection is beneath it, so a script there is unconditional coverage of the whole document. ## What the root buys, and what it costs | | Collection root | One folder | |---|---|---| | **Reach** | every request in the collection | that folder's subtree only | | **New requests** | covered automatically, wherever they are added | covered only if added inside the folder | | **Cost per run** | multiplied by the whole run | multiplied by the subtree | | **Blast radius of a bug** | every request can fail because of it | one subtree can | | **Discoverability** | worst — nothing anywhere hints at it | poor, but the folder is a smaller place to look | | **Duplication** | none | repeated if a second subtree needs it | The row that decides most real arguments is **discoverability**. Inheritance is invisible from below: a request carries no record that a parent script applies to it, so the reader of that request has no way to know. At the root, the set of places to look is the whole document; on a folder, it is one container. The second decisive row is **opting out**. Inherited scripts accumulate rather than resolving to a single nearest owner, so a request cannot cancel what it inherits — its own script runs last and can only react to what already happened. Anything at the root must therefore be tolerable for **every** request in the collection, including the awkward ones somebody adds next quarter. ## When the root is actually right - The behaviour is genuinely **universal** — it makes sense for every request in the document, not merely for most of them. - It is **cheap**, because its cost is multiplied by the size of every run. - It is **idempotent and non-fatal**: it does not fail a request that happens not to need it, and it does not depend on state only some subtrees establish. - Coverage of **future** requests is a feature you actually want, not a side effect you have not thought about. ## When a folder is the better home - Only one part of the tree needs it, and "only one part" is the honest description rather than a temporary state. - The behaviour depends on something that is true of that subtree specifically. - You want the blast radius small enough that a reviewer can enumerate what changed when the script changes. When nine requests in a folder need it and one does not, the choices are: guard inside the folder's script, move the odd request out of the subtree, or duplicate the script into nine requests. The first two are usually right. Duplication is the worst option available — nine copies drift apart, and the tenth never gets the fix. ## Making the cascade legible Inheritance is not the problem; **anonymity** is. A few habits keep a cascading script from becoming folklore: 1. Have inherited behaviour **name its own owner**. `pm.execution.location.current` names the owner of the script that is currently running, which turns an anonymous result into an attributable one for whoever reads the run. 2. Keep the number of **levels** carrying scripts small. Two levels are readable; four levels each contributing something make any single request's behaviour a research project. 3. Treat a change to a root script as a **collection-wide change** in review, because that is exactly what it is — the diff touches one node and the behaviour touches every request. 4. Re-examine placement when the tree is reorganised: moving a folder changes what its requests inherit without editing a single request. ## The judgment the question is testing There is no universally correct answer, which is the point. The interviewer wants to hear the tradeoff named in both directions: hoisting removes duplication and buys automatic coverage, and it pays for that in reach, cost, and a request that can no longer explain itself. A strong answer states the default — the narrowest container that covers the need — and then names the specific conditions under which the root earns the exception, rather than treating "put it at the collection level so it applies everywhere" as obviously good hygiene.
- Nine of ten requests in a folder need the script. Root, folder, or nine copies?Keep it on the folder and make the tenth tolerate it, or move that request out of the subtree. Nine copies drift apart and the fix never reaches all of them, while the root widens the reach far past the nine. A small guard inside one shared script beats duplication almost every time.
- What makes a root-level script expensive even when the script itself is short?Its cost is multiplied by every request in every run, and every failure it can produce is attributable to every request. It is also the hardest thing in the collection to reason about, because the reader of any single request sees no sign that it exists — the anonymity, not the runtime, is the real expense.
- Why can't a request simply opt out of a script it inherits?Because inherited scripts accumulate rather than resolving to one owner, and the request's own script runs last. There is no override step: by the time the request's script executes, the ancestor's has already run. The only real exits are guarding inside the ancestor's script or moving the request out of that subtree.
saying these in an interview costs you the question
- Defaults to the collection root because it applies everywhere
- Ignores that the root covers requests added later
- Duplicates a shared script into many requests instead
- Believes a request can opt out of an inherited script
- Treats a root script edit as a one-node change in review