Role: Frontend Developer, product UIFull interview loop

The hire this loop is looking for builds customer-facing features in the browser from end to end: the component, the data it waits on, how it behaves on a phone, and what it does with text other people wrote. It is written for a product team rather than a platform team, and two assumptions sit underneath it — the team works in a component framework (the plans use React, as most teams do, and each says what changes if yours does not), and there is a design system the hire uses and sometimes contributes to without owning.

Two of the rounds put something already broken in front of the candidate: a search box whose results race the input, fixed and tested in code, and a category page that scores 98 in the lab and responds slowly on phones, read from field data and a trace. The other two ask for judgment on something not yet merged or built: a pull request adding a dialog to the design system, and a draft design for comments that strangers write on product pages. All four are set in the same online shop, so interviewers comparing notes are talking about one product.

Nearly every candidate can list semantic HTML, ARIA and keyboard support; far fewer have decided where focus should land once the element it came from has been deleted. That distance between a fluent answer and an interface that works is why accessibility gets three reads, more than anything else, and each comes at it differently: a widget built to work by keyboard and screen reader, a large performance win weighed against what it hides from assistive technology, and focus designed into an API that other teams will call. Async UI state and web performance get two reads each, one in something already broken and one in the design that is not yet built.

Component API design and browser security are nice-to-haves, and each costs something. A candidate who is strong on the must-haves but has never designed a component for other teams can get through; for a design-system or platform hire that is a mistake, and the fix is to make Component API design a must with a second read — asking for round one's search box as a reusable component is the obvious place for it. Browser security gets one read because frameworks escape text by default, which leaves the risk at a few seams — HTML from markdown or a CMS, URLs, third-party scripts — and round four checks whether the candidate knows where they are. A product that renders a lot of user-written content should make it a must.

There is no competency called coding. Every round has the candidate reading or writing browser code, and a score for the code apart from what it does to the people using it would mostly be a score for style. Nothing here reads visual craft or how the candidate works with designers either; if the job is mainly turning design files into interfaces, add a round for that rather than stretching these four.