Skip to content
tezvyn:

Write a fetch call and log JSON from the Response

Source: developer.mozilla.orgEasyHow cards are made

Write a fetch call and log JSON from the Response

This tests async HTTP literacy and fetch's two-stage promise resolution. A strong answer awaits fetch, then awaits response.json(), logs result, and notes fetch does not throw on 4xx/5xx.

What's really being asked

Even senior engineers are expected to fluently handle the modern Fetch API without hesitation. This question probes three specific things: first, whether you know fetch returns a Promise that resolves to a Response object rather than the data itself; second, whether you understand that Response body methods like json() are themselves asynchronous and return Promises; third, whether you recognize that fetch does not reject on HTTP error statuses such as 404 or 500, which is a common source of bugs in production code. Interviewers use this as a calibration question to see if you write robust async code or copy-paste snippets without understanding the underlying semantics.

The full answer

A good answer hits four things in order. First, wrap the call in an async function so you can use await. Second, await fetch(url) to get the Response object. Third, validate the response by checking response.ok or checking that response.status is in the 200 range before attempting to parse, because fetch treats 4xx and 5xx as resolved promises. Fourth, await response.json() to extract and parse the body, then log the result. Mentioning that json() returns a Promise and not the actual JSON shows you have internalized the two-stage resolution model.

The mistakes people make

The biggest red flag is writing response.json without calling it as a function or without awaiting it, such as console.log(response.json) or const data = response.json(). Another red flag is treating the Response object as the final data, for example logging response directly instead of the parsed body. Some candidates also forget error handling entirely or assume a try-catch around fetch will catch HTTP 404 errors, which it will not unless they explicitly check response.ok and throw. Writing callback-style .then() chains is not wrong, but sticking to async/await is generally preferred in modern TypeScript and JavaScript codebases.

What usually comes next

If you answer cleanly, expect the interviewer to ask how you would handle network timeouts, since fetch does not support timeout natively and requires an AbortController. They might also ask how you would type the JSON payload in TypeScript, or how to handle non-JSON responses gracefully. Another common follow-up is asking how to cancel an in-flight request, or how to set custom headers and method options in the second fetch argument.

A concrete example

Here is a concise, production-aware snippet. Write: async function loadData() { try { const response = await fetch('https://api.example.com/data'); if (!response.ok) { throw new Error('HTTP ' + response.status); } const data = await response.json(); console.log(data); } catch (err) { console.error('Fetch failed:', err); } }. This demonstrates the two awaits, the explicit ok check, and proper error propagation.

Interview question

Which pattern correctly uses fetch to retrieve JSON while handling the API's two-stage promise resolution and HTTP error behavior?

  • a.Await fetch(url), then set const data = res.json() and log it without a second await
  • b.Await fetch(url), check res.ok, then await res.json() and log the parsed resultCorrect
  • c.Await fetch(url), then log the Response object directly, since it contains the parsed JSON payload
  • d.Wrap fetch in try/catch so that HTTP 404 responses automatically reject into the catch block
Why?

fetch resolves with a Response object rather than the final data, and it does not reject on HTTP 4xx/5xx statuses, so you must check res.ok and then await res.json() to parse the body. The most tempting distractor assumes try/catch handles HTTP errors, but fetch only rejects on network failures, not on bad response statuses.

Just read this? Test yourself on what you have been reading.

Read the original → developer.mozilla.org

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles