React

React is the interface library behind most commercial front-end work. The library itself is small; the difficulty is state — deciding what the interface needs to remember, where that memory should live, and what has to happen everywhere else when it changes.

What the work consists of

Breaking a screen into pieces that can be reasoned about separately, then wiring data through them without creating a web where every change touches everything. Done well it is invisible. Done badly it produces the application nobody wants to modify, which is most applications.

What employers screen for

Where you put state, and whether you can explain the choice. Almost every hard front-end bug is state kept in the wrong place or duplicated in two places that drift apart. Interviews find this out by asking you to walk through something you built and defend a decision.

• The difference between state that belongs to a component and state that belongs to the page
• Why a list needs stable keys, explained in terms of what actually goes wrong without them
• When not to reach for a state-management library, which is more often than most juniors assume
• Rendering behaviour: what causes a re-render, and why that usually does not matter

What the evidence looks like

One application with genuine complexity — authentication, data that changes, an error state, something that persists — beats five tutorials rebuilt from a video. Reviewers can recognise a tutorial project instantly, and a portfolio of them reads as absence of independent work rather than as practice.

The honest limit

Knowing one interface library well is worth considerably more than knowing three badly, because the hard parts transfer and the syntax does not. An employer screening for a named framework is usually screening for how fast you will be productive, not for commitment to it — and saying "I have used Vue, the state model is the same, I will be useful in a week" is a better answer than pretending.