skip to content

Which Postman variable store would you commit to version control with the collection, and why?

level: seniorimportance: should knowfreq 45%

answer

  1. A repository can only track files
  2. One store is not a file
  3. Ask which change produces a diff
  4. Commit the array inside the document

basics

~20 s

Commit the collection document's own variable array: it is a field of the file the repository already tracks, so its entries diff and review like any other change. Nothing in pm.globals is committable, since it lives in no file.

solid answer

~40 s

Only one of the two is even a candidate. The collection's own `variable` array is a field of the collection document, so committing the collection commits those entries; they appear in diffs, get reviewed, and are restored by any checkout. The store behind `pm.globals` is declared by no collection schema and held outside the file, so a repository cannot see it at all — there is nothing to commit, nothing to review, and nothing a fresh machine can restore. My rule follows from that: the committed document should declare everything a teammate needs to run it after a clone, kept to non-sensitive defaults; anything that varies per person or per deployment is handed over as its own file; and a real credential never goes into a document under version control at all.

go deeper

for a junior

Be ready with the simple version: the collection's variable array is part of the collection file, so it gets committed with it, while the globals store is not in any file at all.

for a middle

Explain the consequence for review. A change to a committed variable entry appears in a diff and can be objected to; a change to a global leaves no trace anywhere.

for a senior

Demonstrate the standard you enforce: the committed document declares everything a clean clone needs to run, values that vary per person are handed over separately, and secrets are never committed.

for a principal

Own the reproducibility argument. Decide what a shared collection is allowed to assume about the machine running it, and make the self-sufficiency of the artefact the reviewable rule.

## What the repository can actually see A repository tracks files. That single constraint answers most of this question before any preference comes into it. The **collection format** declares an array named `variable` on the collection document. It is text in the file, beside `info` and `item`. If the collection is in the repository, that array is in the repository — you do not opt into it, and you cannot commit the collection while leaving it behind. The store reached from a script as **`pm.globals`** has no counterpart in that schema at all: **no collection schema declares a globals store**. It is held outside the collection file. There is no path to add to the repository, no bytes to stage, and nothing for a checkout to restore. ## Why that makes one store reviewable and the other not | Question | The collection's own `variable` array | The store behind `pm.globals` | |---|---|---| | Is it in a file? | Yes, the collection document | No | | Can it be committed? | Yes, with the collection | No | | Does a change show in a diff? | Yes | No | | Can a reviewer object to it? | Yes | No | | Does a fresh clone reproduce it? | Yes | No | | Reached from a script as | `pm.collectionVariables` | `pm.globals` | The rows that matter to a senior interviewer are the middle three. A committed `variable` entry is a **reviewable decision**: somebody proposed a value, somebody else saw it in a diff, and the history records when it changed and who changed it. A global is a decision **nobody can see**. It was made once on one machine, it produced a behaviour difference in every run on that machine, and it left no trace anyone can inspect afterwards. ## What the committed array should hold The fact that it *can* be committed is not a licence to put everything in it. A useful standard: - **Declare what makes the collection runnable after a clone.** Names the requests depend on should exist in the document, so the first run by a new teammate is not a scavenger hunt. - **Prefer stable defaults and placeholders.** A value everyone receives identically is a good fit for an array everyone receives identically. - **Keep per-person and per-deployment values out.** They differ by definition, so a single committed entry is wrong for somebody; they belong in a file handed over separately. - **Never commit a real credential.** A document in version control is copied, forked and mirrored; how the tool is asked to keep a secret out of a file is its own subject with its own mechanism, but the rule stands on its own. - **Treat the array as reviewed content.** If a value would raise an eyebrow in a code review, it should raise one here too. ## The failure mode a global creates The reason interviewers ask this question at all is a specific, repeated failure: 1. Somebody seeds a value into the globals store while exploring, and their runs go green. 2. The collection is committed and pushed. The document is complete as far as its author can tell. 3. A teammate clones, imports and runs — and the run fails on a name the document never declared. 4. Nobody can diff their way to the cause, because the value that made the original runs work was never in a file. 5. A run driven from files elsewhere fails for exactly the same reason, and equally silently. The cure is structural, not disciplinary. If the artefact must be self-sufficient, the store that is part of the artefact is the only one worth relying on, and the honest test is to ask whether a clean machine holding only the checkout could run the collection. ## Boundaries worth stating out loud Answering well also means declining a few adjacent questions: - which store answers when the same name is declared in several places is resolution mechanics, a separate subject; - the structure of a per-deployment file of values belongs to the environment store's topic; - the mechanism for keeping a secret out of a shared document has its own question; - and moving a value from one request to the next during a run is a flow concern rather than a storage one. The answer stays compact: commit the collection's own `variable` array because it is part of the file the repository tracks and therefore reviewable and reproducible; you could not commit the globals store even if you wanted to, and that is exactly why nothing important should ever depend on it.

  • How would you check that a committed collection is genuinely self-sufficient?
    Read it as the recipient would, with only the checkout in hand, and look for any name the requests depend on that the document does not declare. Better still, run it on a machine that has never held your session state: anything that only worked because of a value in `pm.globals` fails immediately and visibly.
  • Is there any legitimate use left for the globals store once you work this way?
    Yes, as scratch space for the session you are in — an ad hoc value while you explore, which you never expect anyone else to have. The rule is simply that nothing shared may depend on it, because no collection schema declares it and no repository can carry it.

saying these in an interview costs you the question

  • Proposes committing globals as a separate tracked file
  • Says both stores are equally reviewable in a diff
  • Puts real credentials in the committed collection document
  • Relies on a global to make a shared collection run
  • Assumes a teammate's clone restores the author's globals