A CV for a junior developer role gets scanned in seconds before anyone decides whether to read it properly. It needs to be structured for that fast pass, not written as a complete life history.
Naming a project tells a reader almost nothing. Describing what it does and what you built tells them a great deal, in the same space.
| Weak | Better |
|---|---|
| To-do App (React) | Task manager with drag-to-reorder and local storage persistence — built solo, deployed |
| E-commerce site | Product listing site with search, filtering, and a cart — connects to a REST API I also built |
| Portfolio website | Personal site built to learn responsive layout — fully mobile-optimised, deployed with a custom domain |
A junior candidate with limited work history rarely has enough genuine content to justify more than one page, and a padded two-page CV reads as padding, not substance. Cut before you add.
Only list what you can defend
Do not list a technology you cannot discuss for two minutes. Interviewers frequently ask about whatever is on the CV, and a listed skill you can't actually speak to does more damage than leaving it off entirely — it turns your own CV into a trap.
Larger companies often run CVs through automated keyword screening before a person ever sees them. Plain, clearly labelled sections, standard headings, and no information hidden inside images or unusual formatting all survive that step better. Elaborate visual design is not required and can actively work against you here.
A CV that obviously was not adjusted at all for the specific role reads as a low-effort mass application, and is often treated as one. It does not need a rewrite for every application — but the summary line and the order projects appear in are worth adjusting to what the specific role actually asks for.