How many pages should a developer CV be? What to cut and what to expand

One page or two? Information density matters more

One page is a useful constraint for an early-career candidate or when only part of the work history is relevant to the target role. It is not a universal rule that justifies tiny type, cramped layout or removing important projects.

A second page is useful when it contains distinct evidence: progression, harder problems, broader responsibility or experience that matters to the role. If it contains only two verbose bullets about standard duties, improve their density before fighting the page break itself.

A concise, concrete bullet can be enough

A CV does not need a complete case study for every project. ‘Extracted the payments module from the monolith into a separate service’ is short, but it names a concrete change and creates a useful starting point for an interview. It does not yet explain the decision, but it does show what the candidate did.

That is different from ‘designed a microservices architecture’, which could mean almost anything. A bullet is not weak merely because it is short. It should name an action and object precisely enough for the reader to ask a meaningful follow-up question.

Expand the bullets that need to prove seniority

Not every bullet needs to reveal the complete reasoning process. In each important role, choose two or three pieces of evidence that should most strongly support the candidate's level. Those are the places where extra space can create real value.

A compact version might say: ‘Extracted the payments module from the monolith into a separate service.’ An evidence-rich version may add that the choice followed analysis of dependencies, deployment risk or independent scaling needs. The longer version shows seniority more clearly, but the compact version can still be correct when the document is already dense or the reasoning is better explored in an interview.

Expansion is valuable when it reveals an individual contribution: a decision, constraint, risk, trade-off or rollout responsibility. Merely adding ‘in collaboration with the backend team’ usually contributes little because that collaboration is a normal part of frontend work and remains undefined.

A number does not explain the difficulty

A metric can confirm an outcome, but it does not explain how difficult the work was. Improving LCP from 4.2 to 2.1 seconds looks attractive, yet the starting point might have been a severely misconfigured application fixed by one obvious change. Without the mechanism, it is hard to know what the result proves about the candidate.

The diagnosis may reveal more: identifying that the main bundle blocked rendering, separating the critical path and loading the remaining code asynchronously. When space permits, combine the method with the result. When it does not, keep the part that best demonstrates the competence relevant to the target role.

How to cut length without losing evidence

Start with information already implied by the role or repeated in every position: generic collaboration claims, lists of standard duties and technologies already present in the skills section. Merge bullets that describe the same problem and move the strongest evidence to the beginning of each role.

Do not remove decisions, outcomes and constraints while preserving only technology names. Those details distinguish one person's experience from hundreds of similar profiles. When you must choose, keep the line that could not be copied unchanged by almost every developer working in the same stack.

The right length follows priorities, not a rule

There is no single correct page count for a junior, a senior and someone changing specialisation. There is a useful quality check: every extra bullet should add context, evidence or an important condition of fit for the role.

Keep compact facts where a concrete action creates a good interview hook. Expand a few points that genuinely need to prove level, decision-making or impact. Then a second page is not evidence of poor editing; it is a consequence of relevant experience that still matters to the reader.