Explain the purpose of `package.json` and `npm`. | Interview Question

Q: Explain the purpose of `package.json` and `npm`.

**Target Audience:** Engineers preparing for Node.js phone screens — no prior npm experience assumed. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The file contents below came from **actually running** `npm init -y` and `npm install` on this machine, not a hand-written example. ## 1. Why This Even Matters — A Story First A shopping list says "a loaf of bread" — not the specific loaf, not which store, not the exact price paid. Whoever does the actual shopping (the store trip itself) decides which precise loaf satisfies "a loaf of bread" today, and keeps the receipt showing exactly what was bought, for next time. `package.json` is the shopping list. `npm` is the person who does the shopping. `package-lock.json`, covered separately, is the receipt. ## 2. The Core Idea 📌 **Interview term: `package.json`** is a **manifest** — a declarative description of the project (name, version, e

The problem

Question presented to candidate: "A new teammate asks what package.json actually does versus what npm does. How do you explain the division of responsibility between the two?"

What a strong answer should cover:

package.json is a declarative manifest: the project's name, version, entry point, scripts, and — most importantly for this question — its dependencies, each expressed as a semver range (e.g. ^4.17.20), not a single pinned version.
npm (Node Package Manager) is the tool that reads that manifest and acts on it: resolving each dependency's range to an actual version, downloading it from the registry, laying out node_modules, and running the scripts declared in package.json's "scripts" field via npm run <name>.
📌 The precise distinction worth stating: package.json describes intent (what range of versions is acceptable); the actual, exact versions that were resolved and installed are recorded separately, in package-lock.json — covered in its own dedicated question.
npm is also the interface to the npm registry, the public (or private) package repository npm install <package> downloads from — package.json has no knowledge of the registry itself, only of the range it wants satisfied from it.
"scripts" in package.json is a common source of confusion: it is not a build system, just a named-command shortcut table (npm run build → whatever shell command "build" maps to) that also gets the project's local node_modules/.bin added to PATH for that command.
A precise answer also names that npm is one of several compatible package managers (Yarn, pnpm) that all consume the same package.json format — the manifest format is a de facto ecosystem standard, not npm-proprietary, even though npm is the default bundled with Node.

Clarifying questions expected:

"Is the question about the file format, the CLI tool, or the registry?" — these are three distinct things commonly bundled under "npm."
"Does the team use npm specifically, or Yarn/pnpm against the same package.json?" — decides how much of the answer should be npm-CLI-specific versus format-general.

Code / implementation expected: Optional — showing a real, freshly generated package.json after npm init and npm install is a clean way to ground the answer in something concrete rather than a description.

npm
package.json
dependencies
tooling

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js phone screens — no prior npm experience assumed. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The file contents below came from actually running npm init -y and npm install on this machine, not a hand-written example.

1. Why This Even Matters — A Story First

A shopping list says "a loaf of bread" — not the specific loaf, not which store, not the exact price paid. Whoever does the actual shopping (the store trip itself) decides which precise loaf satisfies "a loaf of bread" today, and keeps the receipt showing exactly what was bought, for next time.

package.json is the shopping list. npm is the person who does the shopping. package-lock.json, covered separately, is the receipt.

2. The Core Idea

📌 **Interview term: `package

The solution is hidden so you can try first

5 min read · 8 sections

Read the code

A real package.json generated by npm init + npm install, showing a semver range rather than a pinned version

$ npm init -y
$ npm install lodash@4.17.20
$ cat package.json

JavaScriptThe resulting package.json content

{
  "name": "pkg-test",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": { "test": "echo \"Error: no test specified\" && exit 1" },
  "license": "ISC",
  "type": "commonjs",
  "dependencies": {
    "lodash": "^4.17.20"
  }
}
// Note the "^" — a semver RANGE (4.17.20 or a later compatible 4.x), not a pin.
// The exact resolved version lives separately, in package-lock.json.

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.