How would you decide whether a hosted Postman workspace or your repository holds the authoritative collection?
answer
- Two inputs: who edits, who refuses
- Anything automated forces the repository
- Design for the person in a hurry
- Never two writable homes
- Degrade the loser on purpose
basics
~20 sDecide by who must be able to change the collection and who must be able to refuse a change. If anything automated reads it, the repository owns it; a pure exploration surface may live in the workspace.
solid answer
~50 sFrame it as one question with two inputs: who has to be able to edit this, and who has to be able to refuse an edit. If something automated reads the collection, the repository must own it — a build cannot depend on a document that a stranger's save can change between runs and that your review never saw. If the collection exists so that people without repository access can explore a service, the workspace owning it is fine, provided nothing automated reads it and everyone knows the file in the repository, if any, is a snapshot. The arrangement to rule out in both cases is two writable homes: the copies share no history and no common ancestor, so after both have moved, reconciliation is a person guessing. Also price in that the workspace's copy, its record and its reviewers all depend on an account your organisation may not administer.
go deeper
Know that one copy has to be named authoritative, and that the choice depends on who needs to edit it and whether anything automated reads it.
Explain why two writable homes cannot be reconciled: no shared history, no common ancestor, so differences cannot be attributed to intent.
Show the operating design — degrade the losing copy deliberately, give it an owner and a refresh cadence, and make the authoritative path fast enough to use during an incident.
Own the whole tradeoff: the consumer that must trust the document, the cost of depending on an account you do not administer, and the signal that would reverse the decision.
## The decision is not about tooling preference The question sounds like *repository or hosted account*, and it is not. It is two questions whose answers together determine the home: 1. **Who must be able to change this document?** If that set includes people who have no repository access and should not be granted some — support engineers, analysts, a partner team, anyone whose job is not writing code — then requiring a pull request does not produce careful changes. It produces changes made somewhere else, unreviewed, by whoever could reach the application. 2. **Who must be able to refuse a change?** If the answer is *something automated, before it runs*, then the document has to live where a gate exists. Only the repository has one. When those two pull in the same direction the decision is easy. When they conflict, the second wins for anything a machine reads, and the first is served by giving those people a different, non-authoritative surface rather than by moving the truth. ## The two viable arrangements | | Repository is authoritative | Workspace is authoritative | |---|---|---| | Who edits routinely | people who can commit | whoever the workspace admits | | Who can refuse a change | your reviewers and checks | whoever holds the workspace | | What automation reads | the repository copy | nothing automated should read it | | What the other copy is | a working surface, refreshed | a snapshot, explicitly stale | | Record for an auditor | your history | the vendor's, through their application | | Main failure mode | people bypass it in a hurry | a change nobody outside can see | Both of these work. What does not work is the row that is missing, because it is not an arrangement at all. ## The arrangement that is never viable **Two writable homes.** The copies share no history and no common ancestor. Once each has been edited, no tool can tell you which difference was intended and which was an accident, because neither system ever agreed with the other about a base. Reconciliation is a person reading two documents side by side and choosing, and that person is usually doing it under time pressure because the discrepancy was discovered rather than reported. Every team that ends up here got there by not deciding — the hosted copy was convenient, the file was already committed, and nobody said which one was wrong. ## What depending on an account you do not hold actually costs Price these explicitly rather than treating them as paranoia: - **Reach.** The document, its record and its reviewers are all inside an account. Whoever administers that account can change who reaches it, and that person may not report to you. - **Departure.** People leave. If the copy that matters sits in a space one departing person owned, offboarding is a data problem, not a checklist item. - **Continuity.** Everything about the hosted copy is available on their terms. A checked-in file is already on every machine that ever fetched it, which is a different kind of guarantee and the reason the repository wins ties. - **Evidence.** If somebody outside the team ever has to be shown who changed what, the record must be one you can produce. A record you can only screenshot from someone else's application is weak evidence and an awkward dependency. ## How I would actually decide 1. **Ask what reads it.** If the answer includes anything automated, stop: the repository owns it, and the conversation becomes how to give the non-committers a usable surface. 2. **Ask who edits it in a hurry.** Design for that person. If the authoritative path is too slow for an incident, they will use the other one and the arrangement will fail exactly when it matters. 3. **Name the loser out loud, in both places** — in the repository's README and in the workspace description — so nobody has to infer which document is real. 4. **Give the non-authoritative copy an owner and a refresh cadence**, so it is stale on a schedule instead of by surprise. 5. **Write down the reversal.** Which choice would you revisit, and on what signal? Usually: the repository takes over the moment anything automated starts reading it, and the workspace takes over if the editor population stops being engineers. ## What a strong answer sounds like A strong answer refuses the false symmetry. The two homes are not equivalent options differing in taste: one has a gate, a searchable history and a copy on every machine; the other has reach, immediacy and an audience that cannot commit. You pick by naming the consumer that must be able to trust the document, and then you deliberately degrade the other copy so it cannot quietly become a second source of truth. The weak answer is *keep them in sync*, because keeping two writable documents in sync by hand is exactly the work nobody schedules and nobody notices has stopped happening.
- Non-engineers must edit requests daily, but a pipeline also reads the collection. How do you resolve that?Do not split authority; split the surface. The repository owns what the pipeline reads, and the non-engineers get a hosted copy that is explicitly a working surface, with a named owner who carries agreed changes into the repository. The alternative — both writable — guarantees the pipeline eventually runs a definition nobody reviewed.
- What would make you move authority from the repository to the hosted workspace?The editor population changing. If the people who must change it are no longer people who commit, and nothing automated reads it any more, insisting on a pull request only pushes edits somewhere unreviewed. State the reversal condition when you make the original decision, so the move is a planned change rather than a slow drift.
saying these in an interview costs you the question
- Answering keep both copies in sync as a strategy
- Treating the two homes as equivalent options differing by taste
- Ignoring who must edit when there is no repository access
- Letting automation read a document any workspace member can change
- Never naming which copy is authoritative anywhere visible