How long should a junior developer CV be?

One page. Not one and a bit. A reviewer spends between eight and twenty seconds on it, and a second page is almost never read. If you cannot fit it, the problem is usually that you have listed every module you took, or written four bullets per project where three would do.

Should I put projects above experience on my CV?

If your experience is not software-related, yes. Projects are the evidence a reviewer wants, so put them where their eye lands first. Keep a short employment section below — a part-time job while studying full time says something real about your reliability — but do not let it take space from the projects.

Do I need to tailor my CV for every application?

Not fully — that is exhausting and it does not scale. Keep one strong base CV and spend fifteen minutes per application adjusting the summary line and reordering your projects so the most relevant one appears first. That is enough to make the first thing they read the thing they care about.

Should I include a photo on my developer CV?

In the UK, Ireland and the US, no — it is not expected and some employers discard CVs with photos for fairness reasons. In parts of continental Europe it is more common. Check the norm where you are applying; when in doubt, leave it off, because a missing photo is never held against you.

What file name should I use for my CV?

firstname-lastname-cv.pdf. Not CV_final_v3.pdf, not Document1.pdf. Recruiters save these into folders with hundreds of others, and a file named after you is easier to find again — which is a small advantage that costs nothing.

Developer CV Guide — one page, no percentage bars

Short answer

What does a junior developer CV need?

One page. A header with your target role and clickable portfolio and GitHub links; projects at the top with three bullets each following the pattern verb, what, (stack), outcome; a skills list grouped by category with no ratings; and education. Exported as firstname-lastname-cv.pdf.

What actually happens to your CV

A reviewer spends between eight and twenty seconds on a junior CV before deciding whether to keep reading. In that window they are scanning for concrete nouns: technologies, systems, numbers, and verbs that describe building something.

Most student CVs contain none of those. They contain adjectives, a list of modules, and bullets beginning “Worked on”. That is why the CV is where most junior applications end — not because the candidate is weak, but because nothing in the first third of the page gives a reason to continue.

The structure

Section	Space	Job
Header	3 lines	Name, target role, contact, portfolio and GitHub links
Projects	~45% of the page	The evidence. Two or three, three bullets each
Technologies	3–4 lines	What you can be asked about, grouped by category
Education	2–3 lines	Course, university, expected grade, relevant modules only if space allows
Experience	Whatever is left	Technical if you have it; otherwise one or two lines, unembellished

Priya Raman

Back-end developer · Manchester · priyaraman.dev · github.com/priya-raman

Projects

Society Events Platform — Django, Postgres, Redis

· Built event sign-up used by 3 societies for ~400 registrations over one term
· Prevented capacity oversell with a DB constraint after load testing found a race
· Added transactional email and CSV export used by committees each week

Log Analyser — Go, SQLite

· Streamed 2 GB log files line by line, cutting peak memory from 1.2 GB to 40 MB
· Built a query layer with time-range and level filters over 4M parsed records

Technologies

Languages Python, Go, SQL, TypeScript · Data PostgreSQL, Redis, SQLite · Tools Docker, GitHub Actions, Linux

No star ratings. No percentage bars. One page.

The shape, with projects doing the heavy lifting. Constructed for illustration.

Three lines, and one of them is doing all the work:

Priya Raman
Back-end developer · Manchester
priyaraman.dev · github.com/priya-raman · priya@example.com

The role line is the one that matters. “Back-end developer” positions everything below it. “Computer Science Student” describes several hundred thousand people and repeats what your education section already says.

Make the links clickable in the exported PDF. Recruiters open these on screens, and a URL they have to retype is a URL they do not visit. Check this after export — it is a common silent failure.

Project bullets

Three lines per project, each following the same shape: [verb] [what] [(stack)] — [what happened].

Verb. Built, designed, implemented, migrated, diagnosed, deployed. Not “worked on”, “helped with”, “was involved in”.
What. The thing itself, concretely.
Stack. Two or three technologies in brackets. Not ten.
Outcome. A number, a result, or a specific technical detail.

A worked example:

Society Events Platform — Django, PostgreSQL, Redis
Built event sign-up used by 3 university societies for ~400 registrations over one term
Prevented capacity oversell by moving the limit into a database constraint after load testing found a race between concurrent sign-ups
Added transactional email and CSV export, used weekly by committees

A reviewer scanning that in eight seconds picks up real users, a real number, a concurrency problem understood and fixed, and evidence the thing is actually in use. That is a decision to interview.

Six bullets to fix immediately

Instead of	Write
“Worked on a group project using Java”	“Built the authentication service and REST API for a 4-person library system (Java, Spring Boot, Postgres) — 14 endpoints with role-based access”
“Developed a full-stack web application”	“Built a fixture-management app for three amateur football clubs (Next.js, Postgres) — ran a full season, ~120 fixtures”
A ten-technology list in one bullet	The three that matter to this bullet; the rest go in the skills section
“Implemented various features and fixed bugs”	“Diagnosed and fixed a timezone defect where fixtures shifted after DST — migrated storage to UTC and added regression tests”
“Responsible for the front-end design”	“Rebuilt the booking flow as a 3-step form with inline validation, cutting abandoned bookings from 40% to 12%”
“Personal project to learn React”	“Built a spaced-repetition flashcard app implementing the SM-2 algorithm (React, IndexedDB) — works offline, used through two exam periods”

The skills section

Delete the percentage bars and the five-star ratings. Technical reviewers dislike them consistently — “Python — 87%” is not a claim anyone can evaluate, and it invites a question you cannot answer.

Group by category instead:

Languages Python, Go, SQL, TypeScript
Data PostgreSQL, Redis, SQLite
Tools Docker, GitHub Actions, Linux

List only what you would be comfortable being asked about for five minutes. Every item is an invitation to a question, and a technology you added because you watched a course on it is the one that gets picked.

If you want to signal depth honestly, split into “used in a deployed project” and “used in coursework and side projects”.

If you have no professional experience

Restructure rather than pad. Put Projects where Experience normally goes, at the top. Three projects with three lines each fills the space employment would, and it is the section a reviewer wants to read anyway.

Keep a short employment section below it if you have non-technical work. Do not dress it up in software language — a line saying you worked twenty hours a week while studying full time tells a reviewer something real. What it should not do is take space from your projects.

Anything adjacent goes in its own section and is worth more than you think: a hackathon, a group project with an external client, a teaching assistant role, running a society’s website.

What you must not do is invent. Freelance work that did not happen, a startup that was an idea, a “consultant” role for a family business you built one page for. Interviewers ask follow-up questions and the collapse is unrecoverable.

Formatting and applicant tracking systems

Most large employers run CVs through parsing software before a person sees them. The rules are simpler than the folklore suggests:

One column. Two-column layouts parse unpredictably — text from the sidebar interleaves with the main column.
Real text, not images. A CV exported as a picture parses as nothing.
No text inside tables or text boxes if you can avoid it.
Standard section headings. “Experience”, “Education”, “Projects”, “Skills”. Not “My Journey”.
PDF unless the form says otherwise. Some university portals want .docx — follow the instruction where it is given.
Spell technology names correctly. JavaScript, GitHub, Node.js, PostgreSQL. Parsers match on exact strings, and technical readers notice every time.

What does not matter: font choice within reason, whether you use bullets or dashes, and the mythology about keyword-stuffing white text. That last one is detectable and gets applications discarded.

Final check

One page, exported as PDF, named firstname-lastname-cv.pdf
Portfolio and GitHub links are clickable in the exported file — you tested them
The top third says what you build and what you are looking for
Every project bullet starts with a verb and names a technology
At least one real number appears somewhere
No percentage bars, no star ratings
No spelling errors in technology names — “Javascript”, “Github” and “NodeJS” are the usual three
It says the same thing as your portfolio and LinkedIn

Good CV bullets are a compression of something longer. Write the project case study first — problem, users, approach, architecture, challenges, result, lessons — then cut the middle three sections down to three lines. That is one piece of writing doing three jobs: website copy, CV bullets and your interview answer. The case-study template is in the free toolkit.

The Developer CV Guide