Frontend developer roadmap

Most self-taught frontend developers are weakest in CSS and do not know it, because a utility framework hides the gap until something does not lay out the way they expected and there is no class for it.

Learn the layout model itself: flow, the box model, stacking contexts, flexbox and grid, and why a position or overflow property on an ancestor changed something three levels down. This is what separates someone who styles from someone who can be handed a design and reproduce it.

Utility frameworks are not the problem and are worth using. The problem is treating them as a replacement for the model rather than a shorthand for it, which works until the first time the answer is not a class name.

• Flexbox and grid until you reach for the right one without thinking
• Stacking contexts and why z-index "does not work"
• Containing blocks, and how position interacts with them
• Responsive layout driven by content, not by breakpoints alone
• Modern selectors and custom properties

Frameworks change; the language does not. Closures, prototypes, the event loop, promises and modules explain nearly every confusing behaviour you will hit, and they are what a technical interview probes when it wants to know whether you understand or memorise.

The event loop in particular pays for itself repeatedly. Knowing why something logged in the wrong order, why a state update did not appear immediately, or why a long task froze the page all come from the same understanding.

Closures are the other high-return concept, because they underlie stale values in callbacks, event handlers capturing old state, and most of the confusing behaviour people attribute to their framework being unpredictable.

Choose one and go deep enough to explain its model, not just its API. How rendering and state updates actually work, when effects run, what causes a re-render, where the server/client boundary sits in a modern app.

Depth transfers. A developer who genuinely understands one framework picks up another in weeks; someone who knows three superficially starts over each time and interviews poorly in all of them.

The server and client boundary deserves specific study now that it is central to modern frameworks. Knowing which code runs where, what can cross the boundary and what that costs is one of the most commonly probed areas and one of the least well understood.

Accessibility has moved from a nice-to-have to a procurement and legal question, and it appears in interviews far more than it used to. The basics are not hard and their absence is immediately visible to anyone who checks.

Semantic HTML does most of the work for free. A real button is focusable, keyboard-operable and announced correctly; a div with a click handler is none of those and has to have all of it rebuilt by hand.

The fastest way to build the instinct is to put your mouse aside and operate your own interface with the keyboard for ten minutes. Every place you get stuck, every control you cannot reach, and every point where focus vanishes is a real defect you would otherwise never have noticed.

• Semantic elements before ARIA — ARIA is a patch, not a foundation
• Keyboard navigation through every interactive path
• Visible focus states, and never removing the outline without a replacement
• Labels tied to inputs, and errors announced rather than only coloured
• Colour contrast that meets the standard

Users experience your bundle size on a mid-range phone on a poor connection, not on your laptop. Understanding what ships, what blocks rendering and what causes layout shift is a differentiator, because most candidates have never measured it.

Learn to read a performance trace and connect a number to a cause. Being able to say "the largest contentful paint is the hero image because it is not preloaded and it is a 900KB PNG" is worth more in an interview than naming ten optimisation techniques.

Throttle your own connection and processor in the browser devtools and use your site that way once. It is uncomfortable and it converts performance from an abstract score into something you have actually experienced.

Something with real state and real data — filtering, pagination, optimistic updates, error and empty states. Interfaces that only render happy-path data are the most common portfolio weakness, because every hard frontend problem lives in the other states.

Deploy it, run a performance audit, and fix what it finds. Being able to point at a real measurement you improved says more than another clone project.

Handle the unglamorous cases deliberately and mention them in the README. What the screen shows while loading, what it shows when there is nothing, what happens when the request fails and the user retries — those three decisions demonstrate more frontend judgement than any amount of styling.