Frontend Developer interview questionsCore Web Vitals review — fast in the lab, slow on phones round

Purpose

Takes definitions off the table, so the hour goes on reading the data rather than reciting thresholds.

Purpose

Reads whether the candidate knows what each source can and cannot see. The lab and the field disagree here for ordinary reasons, and the attribution data does most of the diagnosis before anyone opens the recording.

Signals to score

• Trusts the field data for this question, and says why one desktop-preset run on a laptop cannot show it
• Notices the lab report has no INP at all, because a navigation run never clicks anything, and that TBT describes loading
• Reads each field metric against its threshold at p75: on phones LCP and CLS pass and INP does not, and desktop passes all three
• Ties the jump to the "instant filters" release using the team's own monitoring, and knows CrUX is a rolling 28-day window that lags the release and will lag a fix
• Uses the attribution data: most slow interactions are filter clicks, after the page has loaded, and processing is most of their time
• Concludes from the 20 ms input delay and the load state that the unused-JavaScript opportunity is not this problem
• Leaves the image and bundle opportunities for later while saying they are real
• Says who the problem belongs to in product terms — shoppers on phones using filters — rather than "the score"
• Asks how much of the shop's phone traffic uses filters before calling it urgent

Follow-up questions

• Lighthouse says 98. Why doesn't that settle it?
• Where in this pack is INP measured, and where is it not?
• Your own monitoring says 410 ms since the release. Why does CrUX say 350?
• Before the release a filter reloaded the page. Was the old flow faster?
• Lighthouse wants 190 KB of unused JavaScript removed. Will that fix the filters?

Purpose

Moves from percentiles to one interaction, which is where any change has to come from.

Purpose

The load-bearing question of the round. Anyone can list performance techniques; the separator is whether each proposed change is tied to a line in this recording and to the phase of the interaction it shortens.

Signals to score

• Splits the 410 ms into input delay, processing and presentation delay, and says which phase each cause sits in
• Finds the `Intl.NumberFormat` constructor in the bottom-up view and builds the formatter once per locale and currency instead of once per card per render
• Recognises `useEqualRowHeights` as a loop that alternates reads and writes and forces a layout each time, and replaces it with CSS rather than only batching the reads
• Questions whether 1,200 products belong in one grid on a phone, and takes a page size to whoever owns the listing as a product decision
• Lets the checkbox paint before the grid updates — a transition or a deferred value in React, yielding to the main thread outside it — and knows INP ends at the next paint
• Knows that yielding does not remove work: a long commit still blocks, and a tap that lands during it still waits
• Checks whether memoising the cards would skip anything, and notices that the inline `onAddToCart` hands every card a new prop on every render
• Puts an expected saving beside each change, and re-records after each one rather than shipping them together
• Says how the fix will be confirmed for shoppers — the team's own monitoring of phone filter clicks, day by day — without waiting for CrUX

Follow-up questions

• Which phase of the interaction does each of the three causes land in?
• The constructor takes 95 ms across 1,130 cards. What's the change, and what should it save?
• What is `useEqualRowHeights` for, and does it need JavaScript?
• You wrapped the grid update in a transition and INP dropped to 90 ms. Is the page faster?
• How will you know next week whether shoppers got the improvement?

Purpose

Presents the change as finished and measured, so objecting to it is a choice the candidate has to make unprompted.

Purpose

Reads accessibility against a real trade. A candidate who knows what windowing removes — from find-in-page, from a screen reader's path through the grid, from focus — weighs it against the win; one who does not approves the number.

Signals to score

• Says that virtualising removes off-screen products from the DOM, and with them from the accessibility tree and from find-in-page
• Describes what a screen reader user moving through the grid meets: a list that ends after the rendered cards with no sign that more follow
• Finds the focus failure: a focused card scrolled out of the window is unmounted, and focus falls back to the document
• Asks whether the formatter, the layout effect and a page size bring the click under 200 ms without making any product unreachable, and wants that measured first
• Proposes `content-visibility: auto` with an intrinsic size, and says it saves style, layout and paint for off-screen cards but not the JavaScript render
• Proposes a page size with a "Show more" button, and says where focus goes when the next products are added
• If windowing ships anyway, requires each item to expose its position and the set size, focus kept on an item that scrolls away, and a way to reach the end
• Checks the change with a screen reader and with find-in-page before approving, not only with a recording
• Weighs the two costs out loud rather than treating accessibility as a veto or as an afterthought

Follow-up questions

• Search the page for the name of a lamp near the bottom of the category. What happens?
• A screen reader user moves through the grid one product at a time. Where does it end?
• Someone tabs to "Add to cart" on a card, then scrolls down with the arrow keys. Where is focus a moment later?
• What does `content-visibility: auto` save here, and what does it not?
• If this had to ship with windowing, what would you require of it first?

Purpose

A candidate who has done this work asks who owns the numbers and what happens when they move; one who has not asks which tools the team uses. A real, unfixed problem in the answer tells the first kind what the job is.