A frontend engineer builds the part of a product people actually touch. Not the picture of it — that is design — and not the data behind it — that is the backend. The frontend is the working thing in between: the screens, what they show at every moment, and what happens when somebody interacts with them.
Job postings describe this badly. They list frameworks. A more useful description is what actually lands in your queue, so that is what this post is.
The job in one sentence
You own the interface: what it shows, what state sits behind it, what it does when the network is slow or the answer is an error, and whether somebody who cannot use a mouse can still get through it.
Notice how little of that is about how it looks. Appearance is roughly the first afternoon of a feature. The rest of the week is the states nobody drew you a picture of.
What you actually own
The states nobody drew
A designer hands you one frame: the menu, populated, on a wide screen. The real list of screens you are responsible for is longer:
- Loading — and specifically whether the layout jumps when the data lands.
- Empty — no results, no orders yet, nothing in the cart. Usually needs its own copy and often a way out.
- Error — the request failed. Say what failed and what they can do.
- Partial — the menu loaded but the prices did not.
- Stale — it worked, but that was ninety seconds ago and it is wrong now.
- Too much — 400 items, or a product name three times longer than the mock.
- Narrow — the same screen at 360px.
Ask about these in a design review and you will be the most useful person in the room.
State, which is most of the job
Nearly every frontend bug you will chase is really the same bug: some value existed in two places and the two disagreed. The cart badge says 3 and the drawer shows 2. The form re-enabled its button but the request is still in flight. You logged out in one tab and the other still thinks you are signed in.
This is why post 6 exists and why interviewers ask about it constantly.
The contract with the backend
Every screen is downstream of an API. You do not own it, but you are the first to find out when it is wrong, and you own what the user sees when it is. That means handling the outcomes that are not the happy one — covered in post 7 — and being able to argue for a better response shape when the one you have makes the UI impossible.
Reading the backend track's post on API design is genuinely worth an hour. Knowing why a backend returns 409 instead of 400 makes you much faster at deciding whether a bug is yours.
Performance, on devices you do not own
Your development machine is the fastest device your app will ever run on, on the fastest network it will ever see. Real users are on mid-range phones with a bad connection. Every kilobyte of JavaScript you ship is downloaded, parsed and executed on that phone before anything works. Post 10.
Whether it can be used at all
Some of your users navigate by keyboard, some use a screen reader, some have tremors, and a lot of them are just outdoors and cannot read low-contrast grey. Accessibility is not a compliance task bolted on at the end — most of it is decisions made while writing the markup, and it is cheap then and expensive later. Also post 10.
Where the line sits
| They own | You own | Where it goes wrong |
|---|---|---|
| Design — layout, type, colour, the intended flow | Making it real, and every state they did not draw | A mock with no error state, no empty state and no 360px width |
| Backend — the data, the rules, the response shape | Rendering it, and what happens on 401, 500 and timeout | A response that needs three more calls to be renderable |
| Product — what gets built and why | Saying what it will cost and what it breaks | An "easy tweak" that is a rewrite of the state model |
| QA — finding it before users do | Making it findable — stable roles and labels to test against | Tests pinned to CSS classes that break on every restyle |
| DevOps — the pipeline and the CDN | The build, the bundle, the cache headers, the SPA fallback | Deep links 404 because the fallback was never configured |
The line moves by company. At a startup you own all of it. At a large company you may own one screen. Both are real frontend jobs.
What a real ticket looks like
"Let customers see their past orders." Here is the actual shape of that work:
| Step | What you do |
|---|---|
| 1 | Read the mock. Write down the states it does not show: loading, no orders yet, request failed, forty orders, an order still being prepared. |
| 2 | Check the API. Is there an endpoint? Does it paginate? Does it return the line items or just ids? If just ids, that is a conversation now, not in three days. |
| 3 | Decide where the data lives — fetched by the page, or in shared state because something else needs it too. |
| 4 | Build the happy path against real data. |
| 5 | Build the other four states. This takes longer than step 4. |
| 6 | Guard the route — signed-out users must not see a flash of the page before the redirect. |
| 7 | Keyboard through it. Tab order sensible, focus visible, headings in order. |
| 8 | Check the bundle did not jump, and that the list does not re-render on every keystroke elsewhere. |
| 9 | Write the test that proves a signed-in user sees their orders and a signed-out one is redirected. |
| 10 | Ship it, then look at whether anyone actually opened it. |
A beginner does step 4 and calls it done. The gap between step 4 and step 10 is the job.
The titles you will see
| Title | What it usually means |
|---|---|
| Frontend engineer | Everything in this track. |
| UI engineer | Heavier on CSS, design systems and component libraries. |
| Full-stack engineer | This track plus the backend one. Common at smaller companies. |
| Web developer | Broad. Can mean this, or can mean WordPress and marketing sites. |
| Mobile engineer | The same discipline against a phone. React Native shares most of this track. |
| Design engineer | Newer. Sits deliberately across the design/frontend line. |
The one thing to take from this post
You are not paid to make the screen in the mock. You are paid for every other screen: the one while it loads, the one when it failed, the one on a narrow phone, and the one somebody navigates without ever seeing it. Get in the habit of asking "what are the other states?" before you write a line, and you will look senior years earlier than you are.