What is a Service Worker's role and key PWA capability?
Tests understanding of the Service Worker as a network proxy and its core PWA benefit. A strong answer states it intercepts requests as a proxy and enables offline use via granular caching. Red flag: confusing it with Web Workers or DOM manipulation.
What's really being asked
The interviewer wants to know if you understand the architectural role of a Service Worker as a programmable network proxy and its relationship to Progressive Web Apps. This is foundational for modern web performance and reliability. They are checking whether you can distinguish it from other worker types and whether you grasp why HTTPS is required.
The full answer
A good answer hits four things in order. First, define the Service Worker as a JavaScript file that acts as a proxy between your web application, the browser, and the network. Second, explain that its primary power is intercepting network requests and deciding how to respond, which enables offline experiences through granular caching strategies. Third, mention that it unlocks specific PWA capabilities such as push notifications and background sync. Fourth, note the constraints: it runs in a worker context with no DOM access, is fully asynchronous and non-blocking, and only works in secure contexts like HTTPS or localhost.
The mistakes people make
Red flags to avoid include confusing a Service Worker with a standard Web Worker or claiming it can manipulate the DOM directly. Another mistake is describing it only as a cache layer without mentioning the proxy interception model. Saying it enables offline mode magically without explaining request interception is also weak. Finally, forgetting that it requires a secure context shows a lack of production awareness.
What usually comes next
Expect the interviewer to ask how you would implement a cache-first versus network-first strategy, how to handle Service Worker updates and activation, or how the lifecycle events like install and activate work. They might also ask about the Cache Storage API versus browser HTTP cache, or how to test Service Workers during local development given the HTTPS requirement.
A concrete example
Imagine a news PWA where a user opens an article. The Service Worker intercepts the fetch request for the article HTML and assets. If the network is available, it fetches fresh content and updates the cache. If the user is on a subway with no connection, the Service Worker serves the cached article from the previous visit, allowing the user to keep reading. This same worker could also register for push notifications to alert the user when a breaking story publishes, and use background sync to retry a failed comment submission once connectivity returns.
Interview question
In a news PWA, a user opens a previously visited article while offline. How does the Service Worker make this possible?
- a.It runs a background thread that silently pre-downloads articles for later use.
- b.It upgrades the browser's default HTTP cache to keep all visited pages automatically.
- c.It intercepts the article fetch request and returns the matching cached response.Correct
- d.It accesses the page DOM to inject previously rendered HTML when the network fails.
Why? this is the answer
The Service Worker acts as a programmable network proxy that intercepts fetch requests and can decide to return cached assets when the network is unavailable. Option D is a common misconception because Service Workers run in a separate worker context and cannot manipulate the DOM directly.
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.
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