JSON Interview Questions and Answers (Including Data Engineering)

Q: What is JSON?

A: JSON (JavaScript Object Notation) is a text-based data format for representing structured data as key-value pairs and ordered lists. It's derived from JavaScript object literal syntax but is language- independent — every mainstream language ships a parser for it.

Q: What are JSON's data types?

A: Exactly six: string, number, boolean, null, object, and array. That's it — no date type, no undefined, and no function type, unlike a JavaScript object which can hold any of those.

Q: Why is JSON so popular for APIs, over something like XML?

A: Three reasons interviewers usually want to hear: it's language-agnostic (every runtime can parse it), it's human-readable without special tooling, and its two structures — objects and arrays — map directly onto the maps/dicts and lists most languages already have, so there's no impedance mismatch to deserialize into. The full comparison, including where XML still wins, is in Is My JSON Valid? and the JSON Formatter guide.

Q: What's the difference between JSON and a JavaScript object literal?

A: JSON is a text format — a string. A JavaScript object is a live, in-memory structure that can contain functions, undefined, Dateinstances, circular references, and more. They look similar but aren't interchangeable: JSON.stringify() turns an object into a JSON string, and JSON.parse() turns a JSON string back into a plain object. Passing an object directly where a JSON string is expected — or vice versa — is a very common junior mistake.

Q: How do you store a JSON column in Postgres — JSON or JSONB?

A: JSONB almost always, unless you have a specific reason not to. JSON stores the exact input text — whitespace, key order, and duplicate keys are all preserved verbatim, and every read re-parses the text. JSONBstores a decomposed binary representation: it's not literally the input text, keys are de-duplicated (last one wins), key order is not guaranteed to be preserved, and it supports indexing (GIN indexes, containment operators like @>). Use plain JSON only when you need the exact original bytes back, such as an audit log.

SELECT * FROM events
WHERE payload @> '{"type": "signup"}'::jsonb;

Q: What is JSON Lines (.jsonl), and why use it instead of one big JSON array?

A: JSON Lines is one complete, valid JSON value per line, with no enclosing array and no comma between lines. It's the standard format for streaming and large datasets because a consumer can read, parse, and process the file one line at a time without ever holding the whole thing in memory — a single 50 GB JSON array, by contrast, generally can't be parsed incrementally without a streaming parser, and a single malformed record corrupts the entire array instead of just one line.

{"id": 1, "event": "signup"}
{"id": 2, "event": "purchase"}
{"id": 3, "event": "signup"}

Q: How would you flatten nested JSON for tabular analysis?

A: This is a classic take-home or whiteboard question. The general approach is a recursive walk: for each key in an object, if the value is a primitive, emit it as a column named by joining the path so far (dot- or underscore-separated); if the value is a nested object, recurse into it with the extended path; if the value is an array, either explode it into one row per element (a join) or serialize it back to a JSON string in a single column, depending on whether the array elements themselves need to be queried individually.

{"user": {"id": 1, "address": {"city": "Berlin"}}}
↓
user_id: 1, user_address_city: "Berlin"

Q: What is JSON Schema, and what is it used for?

A: JSON Schema is itself a JSON document that describes the expected shape of another JSON document — required fields, types, allowed value ranges, string formats, nested structure. It's used to validate incoming data (an API request body, a config file, a message on a queue) before it's trusted, and to generate documentation, TypeScript types, and form UIs from a single source of truth. Try one against real errors located by JSON Pointer in the JSON Schema Validator guide.

Q: JSON is described as "schemaless" — what does that actually mean, and why do teams add JSON Schema anyway?

A: It means the JSON format itself imposes no structure beyond its own syntax — nothing in the spec stops two objects with the same intended meaning from having different keys, types, or nesting. That flexibility is exactly why teams layer JSON Schema on top voluntarily: without an agreed shape, every consumer of an API or message queue would validate assumptions manually and inconsistently. Adding a schema doesn't contradict JSON being schemaless — it's an external contract that constrains what would otherwise be unconstrained, applied at the boundary rather than baked into the format.

Q: Why does JSON.parse throw on a trailing comma?

A: The JSON grammar defines a comma strictly as a separator between elements, not a terminator after the last one — so {"a": 1,}is a syntax error, even though it's legal in a JavaScript object literal. This trips people up constantly moving between hand-written JS objects and real JSON; it's covered in full, with the exact error text browsers and Node produce, in JSON Parse Error: Unexpected Token.

Q: Why can't JSON represent undefined or a JavaScript Datedirectly?

A: Because neither exists in the six JSON data types. JSON.stringify() silently drops object properties whose value is undefined (and omits undefined array elements as null), and it serializes a Date by calling its toJSON() method, which returns an ISO 8601 string — 2026-08-03T00:00:00.000Z — not a native date value. On parse, that string comes back as a plain string; reviving it into a real Dateobject is the caller's job, typically via the reviver parameter of JSON.parse.

Q: Is a duplicate key in a JSON object valid?

A: Syntactically yes — the grammar doesn't forbid it — but semantically it's undefined behavior. The spec doesn't say which value wins, and parsers disagree in practice: most take the last occurrence, but not all, and some validators reject duplicate keys outright. Treat a duplicate key as a bug to fix, not a feature to rely on either way.

Run any of these examples through GenKitLab's JSON Formatter & Validator to see the exact line and column a parser stops at — it's the fastest way to confirm which of these gotchas you're actually looking at instead of guessing from the stack trace.