Frontend Developer interview loops

Whether the job ad says frontend developer, front-end engineer or UI engineer, the work is the one part of a product that runs on hardware nobody at the company chose. The phone is slower than the laptop the page was built on, the connection drops in a lift, the person using it may be on a keyboard or listening to a screen reader rather than looking, and some of the text on the page was written by strangers. What a team needs is an interface that stays correct and usable under all of that, so the competencies below describe what happens to UI after it leaves the developer's machine, and none of them names a framework.

The failures worth hiring against rarely show up in a clean demo. A response lands after the one that replaced it; focus drops to the top of the page when a row is deleted; a tap takes 400 ms on a mid-range phone and a fraction of that on the laptop that built it; a comment runs code. Questions about lifecycle methods or how a virtual DOM diffs cannot surface any of that, and mostly reward whoever read about them last. In the loop below, every round starts instead from something the interviewer builds beforehand and puts in front of the candidate: a component with known bugs, field data and a trace, a pull request, a design doc.

A loop is a set of round plans in order. Each round scores one to three competencies, every must-have is scored in at least two rounds, and the debrief goes competency by competency rather than interviewer by interviewer, so no single conversation decides the hire. How these plans work covers the rest of the method.