A credible CV for a junior developer with no paid experience yet leads with the work you can actually show, not with an empty experience section stretched thin. Projects, coursework, a bootcamp capstone or any real contribution to a codebase become the section that would otherwise sit under experience, built the same way a job entry is: a clear title, dates, the stack you used and a short account of what changed because of it. Education backs that up, and a short summary at the top states your current level and the kind of role you are aiming for plainly, rather than dressing up a lack of a paid job with vague language.
Put projects where experience would normally sit
For a junior developer CV without paid experience, a good structural swap is to give the projects section the same weight and position a job history normally gets: header and short summary first, then projects, then education, then a skills section, and only then anything extracurricular. Recruiters and hiring managers scanning quickly read top to bottom, so the strongest, most job-relevant material belongs first, and for someone whose strongest material is a portfolio of things they built, that is projects rather than an internship or a part-time job unrelated to development. Two or three projects, chosen for relevance to the target role rather than for how recently they were built, read better than five or six squeezed in. A project built for a university module, a bootcamp capstone and a personal tool are all fair to include here, as long as each one gets the same treatment: a name, a short description, the stack, and what it did, not just a list of course titles.
Write each project entry like a job, not a hobby
Each project entry works best with the same fields a job entry would have: a title, a timeframe, the technologies used, and one to three lines describing what the project does, what part you built if it was a group effort, and any change or result that followed from it. Naming the specific stack, a language, a framework, a database, a deployment platform, matters more here than it does for a job entry, since it is often the clearest evidence a reader has of what you can actually do. If a project was built with others, say what you specifically owned rather than describing the project as a whole and leaving your contribution unclear; a shared team project that lists only the group's overall achievement reads as vaguer, not more impressive. A project still in progress is worth including if it is far enough along to describe concretely, but a project that never got past an idea is better left off entirely, since a CV entry needs something to say about what was actually built.
A contribution to someone else's codebase counts too, and often reads as more credible than a solo project because it shows you can work inside code you did not write. If you fixed a bug, added a small feature or improved documentation for an open source project, name the project, describe the specific change in one line, and say what it took to get it merged, such as understanding an existing test suite or following a contribution process for the first time. That kind of entry, even a small one, demonstrates something a solo weekend project cannot: working inside someone else's constraints rather than your own.
Illustrative example: a vague project line rewritten as an entry
Before: "Made a website with some friends for a class project."
After: "Task Tracker, team project, university module, March-May [year]. Built the backend API in Node.js and Express, handling authentication and task assignment for a four-person team; the frontend was built by two teammates in React. Deployed to a free hosting tier for the module's demo session."
The rewritten version keeps the same underlying fact, a small team project from a class, but now states the stack, the specific part that was built, the team size and what happened with it, which gives a reader something concrete to judge instead of a single flat sentence.
Skills and education, kept honest
List skills grouped by category, languages, frameworks, tools, cloud, rather than as one long unsorted line, similar to how a skills section can be grouped in CVBuilderKit's developer template. Keep the list to things you could speak about in an interview at a reasonable depth; a long list padded with tools touched once in a tutorial does more harm than a shorter, accurate one, since an interviewer who asks a follow-up question about an inflated entry notices the gap quickly. Education stays in, listing the degree, institution and expected or actual graduation date, along with any coursework that is directly relevant to the target role if the entry otherwise feels thin.
Before you send the first version
Once the structure is in place, read the whole thing as a recruiter would: does the first project entry say enough to be worth a second look, and does the summary line state a real target rather than a generic one. It is worth reading the summary on its own, separately from the rest of the document, and asking whether it names a specific kind of role, such as "junior backend developer" or "frontend developer focused on React", rather than a generic phrase like "motivated developer seeking opportunities" that could describe almost anyone. Writing a CV with little or no work experience as a graduate covers the same problem from a broader angle if the projects section alone is not carrying enough weight yet, particularly for education and internship framing. When the structure feels right, start building it and adjust the wording as you add each new project; a CV built this way is easy to extend once the first paid role finally does go on it, since the projects section simply moves down rather than needing to be rebuilt from nothing.