Most solutions here go straight for a recursive-descent parser, and the interview answer usually stops at "handle the literals, objects, arrays, strings, numbers". Worth saying out loud why that shape is the right one, because it generalises well past this problem.
Why a hand-written recursive-descent parser keeps winning for small grammars:
<ol>
<li>
The grammar is the call graph. <code>parseValue</code> dispatching on the first character into <code>parseObject</code> / <code>parseArray</code> / <code>parseString</code> / <code>parseNumber</code> maps one-to-one onto the JSON railroad diagram. When a test fails you already know which function to open.
</li>
<li>
Error position comes free. Because you carry an index rather than consuming a stream, throwing "Unexpected token at i" is one line. Regex-based approaches lose the position the moment they backtrack.
</li>
<li>
The nasty cases all live in <code>parseString</code> and <code>parseNumber</code>, not in the structure. Surrogate pairs in \uXXXX escapes, rejecting literal control characters below 0x20, rejecting leading zeros and a leading plus, rejecting <code>.5</code> and <code>5.</code> — that is where the real spec is, and it is where most submissions in this thread quietly differ from the native implementation.
</li>
</ol>
A better way to check your version than eyeballing a few literals: round-trip a large corpus and <code>deepStrictEqual</code> against <code>JSON.parse</code>. The disagreements are almost always numbers.
Why I care: I ended up writing a similar hand-rolled parser for <a href="https://pdf2md.me">pdf2md</a>, which converts PDF to Markdown entirely in the browser. A PDF has no table object at all — it is just glyphs at coordinates — so rebuilding rows and columns is exactly this kind of problem: a small grammar, position-sensitive errors, and all the pain concentrated in two leaf functions. Same shape as <code>parseString</code>, only with geometry instead of characters.
If anyone has a cleaner way to handle surrogate pairs than the two-step <code>charCodeAt</code> check, I would like to see it.

Why the recursive-descent version is worth writing even though JSON.parse exists

This is a follow-up on 21. implement JSON.stringify(). Believe you are already familiar with JSON.parse(), could you implement your own version? In ca…