Your repository holds a years-old exported Postman collection; how do you upgrade it and verify nothing was lost?
answer
- Ask the file what it is first
- A program converts better than a person
- Review it as a diff
- Confirm the script lines survived
basics
~20 sRead the file's declared generation first, convert it with the collection transformer rather than by hand, then review the conversion as a diff and re-run the collection, checking that every old script string reappears as exec lines.
solid answer
~40 sStart by reading **`info.schema`**, because the file declares its own generation and every later decision depends on that answer. If it is the older shape, convert it with the **`postman-collection-transformer`** package — `converter-v1-to-v2.js` — rather than hand-editing, since the old shape holds arrangement in `order` and `folders_order` arrays that must stay in agreement with a flat request list. Then review the conversion **as a diff**, checking four things: the flat request list became nested entries; the ordering arrays are gone because sequence is now position; every `tests` and `preRequestScript` string reappears as `script.exec` lines; and the old auth object appears in the current attribute shape. Finally re-run the collection and compare outcomes, then commit the converted file — keep one generation in the repository, not two.
go deeper
Know the first step and say it plainly: look at what generation the file declares before changing anything. Recognising the flat list with order arrays as the older shape is enough at this stage.
Explain why conversion is a program's job — the old shape keeps content and arrangement in two structures that must agree, and hand-editing silently breaks that agreement.
Show the verification discipline: review the conversion as a diff, re-run the collection, and compare how many assertions actually executed rather than trusting a green result.
Own the boundary decision — where conversion happens, that only one generation lives in the repository, and how the declared generation is checked before anything downstream depends on the shape.
## Establish what you are holding The first move is not to convert anything; it is to **read `info.schema`**. A collection file declares its own generation there, and that single line decides whether there is a problem at all. Teams routinely spend an afternoon debugging a suite that "stopped asserting" when the file simply declares an older generation and the tool reading it does not. While you are in there, confirm the diagnosis against the shape itself. An older-generation export is recognisable without reading a URL: - a **flat request list**, with no nesting anywhere; - **`order`** and **`folders_order`** arrays carrying identifiers to supply the sequence; - **`tests`** and **`preRequestScript`** as plain strings on the requests; - an **auth object** rather than the attribute-array shape the current format uses. If the declared generation and the observed shape disagree, stop — you have a hand-edited file, and that is a different and worse problem than an old one. ## Convert; do not hand-edit The temptation is to "just nest the folders". Resist it. In the older shape, **content and arrangement are two structures that must agree**: an identifier in an ordering array with no matching request is a dangling reference, and a request that no ordering array mentions has no defined place. Hand-editing is exactly how those states get introduced, and they are silent. Use the **`postman-collection-transformer`** package instead. Its **`converter-v1-to-v2.js`** is the code that performs the structural translation, and the translation is mechanical rather than a judgement call — which is precisely why a program should do it. ## Review the diff, and know what to look for Convert into a **new file, under version control, reviewed as a diff**. Four changes should be visible, and each is a check: | What changed | What to confirm in the diff | |---|---| | Flat list to nested entries | every request from the old list appears exactly once | | `order` / `folders_order` gone | sequence now reads off position, and matches the old arrays | | Script strings to `script.exec` | each old string's lines appear as array elements | | Auth object to attribute shape | each credential survived rather than silently emptying | The script row is the one that gets missed. The conversion splits the old string on newlines, so the reviewer's job is to see the **same lines** on the other side — not to assume that because the file grew, the scripts came with it. ## Verify behaviour, not only shape A clean diff proves the document converted; it does not prove the suite still does what it did. So: 1. **Run the collection before converting** and keep the outcome, so you have something to compare against. 2. **Run the converted collection** the same way and compare, request by request. 3. **Count the assertions**, not just the failures — a suite where every named test silently stopped executing looks green in the least useful way. 4. **Spot-check one request that has both a pre-request script and a test script**, since that is where the two-key mapping onto listener entries is exercised. ## Then keep it from recurring - **Commit the converted file and delete the old one.** Two generations of the same collection in one repository is a trap for whoever arrives next; this is a repository whose contract you control, so there is no caller to keep compatible. - **Check the declared generation in review.** A one-line assertion on `info.schema` in a pipeline is cheaper than the afternoon it saves. - **Convert at the boundary.** If old exports keep arriving from outside, convert them on the way in, so no consumer downstream ever has to ask which shape it received. - **Do not conflate the numbers.** The library, the runner and the format each revise on their own schedule. Say which one you mean, and name generations as generations rather than dating a release. ## The judgement being tested The interviewer is looking for three habits: **read the artefact's own declaration before theorising**, **prefer a mechanical conversion to hand-editing a document with two structures that must agree**, and **verify behaviour rather than trusting a quiet exit**. The last is the senior one — an upgrade that produced a clean diff and a suite that no longer asserts anything is the failure mode worth naming out loud.
- Why not simply keep both the old and converted files in the repository?Because the next reader has to work out which one is authoritative, and any edit risks landing in the stale copy. Nothing outside the repository consumes the old shape, so there is no compatibility argument for keeping it — convert, commit the result, and delete the original.
- The converted collection runs clean and reports no failures. Why might that be bad news?Because a suite whose assertions never execute also reports no failures. Compare the number of assertions that ran, not just the verdict — if the scripts did not survive the conversion, every request still fires and nothing checks the responses, which looks green in the least useful way.
- How would you stop an older-generation export from reaching the repository again?Check the declared generation where files enter. A cheap assertion on info.schema, applied at the boundary where exports arrive, converts or rejects the file before anything downstream depends on its shape — much cheaper than diagnosing a silent suite weeks later.
saying these in an interview costs you the question
- Hand-edits the flat list into a tree by hand
- Rewrites the schema URL to make tools accept the file
- Trusts a clean diff without re-running the collection
- Keeps both generations of the file in the repository
- Declares success because the run reported no failures
- Never reads the file's declared generation before converting