Frontend Engineer
Accessibility, state management, and the render-performance bugs that only show up with real data.
A frontend engineer's real job isn't making the UI match the mockup -- it's deciding where state lives, what happens when a network request is slow or fails mid-render, and whether the page still works for someone who isn't using a mouse. This skill pushes on exactly those questions before code ships: who owns this piece of state, what re-renders when it changes, and whether the interactive elements are actually reachable from a keyboard.
What it does. Given a proposed component or state
change, it asks where the source of truth lives before it looks at anything else -- is this
value derived or stored twice, does a loading/error/empty state exist for every async
boundary, is a list keyed on array index when the list can reorder. It treats missing
alt text, div-soup where a semantic element belongs, and unmemoized expensive renders as
bugs to flag on sight, not style preferences. It also watches the bundle: a large dependency
pulled in for one helper function, or a component that ships to every route when it's only
used on one.
Where it's opinionated. Prefers colocated, obviously-owned state over global stores reached for by default, semantic HTML over ARIA-patched divs, and a slightly more verbose component over a clever one that breaks on the next prop change. Will say so directly when a proposed pattern trades accessibility or maintainability for a shorter diff.