Skip to content

Frontend engineering in a Senior interview

Our frontend questions start from a symptom in a running app: focus escapes a modal, the first client render disagrees with the server's HTML, a cart shows stale data after an update. They ask for the mechanism and for the change that fixes it within the constraints the question states. The browser, React and the HTTP cache each follow their own rules, and a fix that ignores one of them can move the bug somewhere else.

An axis of our Senior fullstack target.

The check comes with every pass, covers all 10 competencies of our Senior fullstack target, and takes about 20 minutes. It reports each one as Ready, Borderline or a Gap for this level. It never predicts a pass.

Patterns our questions are designed to test at Senior

These are the distinctions the questions on this axis are written to separate — our judgement from writing them and having them reviewed, not a measurement of candidates. We have run no study, so nothing here is a statistic and none of it is phrased as one.

  1. 1.

    The declaration mistaken for the mechanism

    aria-modal="true" tells assistive technology that the content outside a dialog is unavailable; on its own it neither traps keyboard focus nor makes the page behind inert. Access-Control-Max-Age: 86400 asks for a day, and the browser keeps the preflight answer only up to its own cap. Our questions put the declaration beside the mechanism and ask which behaviour follows.

  2. 2.

    The server and the browser rendering different things

    A time formatted in the server's time zone can differ from the first client render, and React then reports a hydration error and renders that part again on the client. Props a Server Component passes to a Client Component are serialized into the payload sent to the browser, including the ones the component never displays. Our questions ask what both sides can agree on, and what crosses the boundary.

  3. 3.

    Asynchronous taken to mean off the main thread

    await res.json() waits for the body without blocking, then parses it on the page's thread, and a large body freezes the page while it does. postMessage copies a buffer by structured clone on the sending thread unless the buffer is transferred. The freeze in these questions comes from work that stays expensive behind an asynchronous API.

  4. 4.

    A cache the author forgot

    Between a fetch and the server sit the browser's HTTP cache and, where the app has them, a service worker's cache and a CDN, each with its own freshness rule. A stale answer is often a request answered by one of them: a stale-while-revalidate copy, a service worker whose precache request was itself answered from the HTTP cache, a CDN that keyed on the URL alone and served one origin's CORS header to another.

What a strong answer sounds like: A strong answer names which runtime decides the outcome (the server render, the browser, React, or a cache between them) before it proposes a change.

How the check measures it

3 questions drawn on this axis alone — 2 medium and 1 hard for a Senior target, because the bar is the level. Hard counts for one and a half times a medium, which is what makes the verdict relative:

Medium rightHard rightVerdict
2 of 21 of 1Ready
1 of 21 of 1Ready
2 of 20 of 1Borderline
0 of 21 of 1Borderline
1 of 20 of 1Gap
0 of 20 of 1Gap

Three questions is coarse and the report says so beside every verdict. It is enough to separate this axis from the others in your target, which is what the check is for — there is no total, no percentage and no single number anywhere in the report.

What there is to practise

67 questions on this axis
46 medium, 21 hard. Easy is not drawn for a Senior target.

Every answer cites the source it was checked against.

Drawn from Frontend & React (78).

Practised in the Technical deep dive round
How things actually work and why they fail: networking, concurrency, performance, security, and diagnosing a symptom to its mechanism.

Practice is arranged by interview round rather than by topic, so you can work through it one round at a time.

Questions here most often also test performance, code quality & design, caching and security. Few questions on this axis test it alone, which is why the check reports every competency separately rather than averaging them.

One of them, in full

A question from the free demo, not written for this page. A demo quiz opens with it; the answer, the explanation and the source come when you submit — no account needed.

Frontend engineeringhard

An offline-capable app serves /app.js — the same name every release — and /sw.js, both with Cache-Control: max-age=86400. On install, the service worker calls self.skipWaiting(), opens a cache named for the release, app-v41, and calls cache.addAll(['/app.js']); on activate it deletes every other cache, and it answers fetches cache-first. After release 42 — new app.js, and an sw.js that names app-v42 — users who opened the app the day before are controlled by release 42's worker yet run release 41's code. Which explanation and change are right?

Answer it on the demo

One axis is not the loop

This axis is one of 10 in our Senior fullstack target, and being strong here says nothing about the others. The check covers all of them in one sitting and reports each separately, so what comes back is a profile rather than a score.