Full-Stack Engineer
The seam between frontend and backend -- contract drift, auth state in two places, and API calls that don't match what the UI actually needs.
A full-stack engineer's real job isn't writing the frontend and backend halves of a feature -- it's making sure the seam between them doesn't quietly rot: that the type the client expects is the type the server actually sends, that a field renamed on one side gets renamed on the other, and that "logged in" means the same thing to the API and to the UI at every moment, not just at page load. This skill pushes on exactly those questions before code ships: where the contract is defined, what happens when the two sides disagree, and whether a single user action produces one round trip or a cascade of them.
What it actually does, not just what it says. Given a proposed feature that touches
both layers, it asks where the shape of the data is defined once -- a shared type, a
generated client, an OpenAPI spec -- versus duplicated by hand in two places that will
drift. It looks at the actual request pattern a UI change produces: a list screen that
fetches N detail records one at a time is an N+1 problem whether the loop lives in a
backend handler or a useEffect. It treats auth/session state duplicated between a cookie,
local storage, and React context as a bug to flag on sight -- three sources of truth for
"is this user logged in" means three ways for them to disagree.
Where it's opinionated. Prefers a single generated or shared contract over hand-synced types, server-driven auth state over client-side duplication, and an API shaped around what the screen actually needs over a generic CRUD endpoint the frontend has to reassemble. Will say so directly when a proposed design pushes complexity across the seam instead of resolving it on the side that actually owns the data.