We spend most of our time on this site helping people pass interviews — but a truth worth stating plainly: most rejections happen before any interview. A recruiter spends seconds on a first skim, and at many companies an applicant tracking system (ATS) filters CVs before a human sees them at all. Here is how to write a developer CV that survives both, based on what recruiters and hiring engineers consistently say gets a candidate through.

The structure that works

One page for under ~8 years of experience; two pages maximum after that. In order:

  1. Header: name, city/timezone, email, phone, GitHub, LinkedIn. No photo, no date of birth, no full street address — they add bias risk and zero signal.
  2. Summary (2–3 lines, optional): only if it says something specific — "Laravel developer with 4 years building e-commerce platforms; led migration serving 2M requests/day" — never "hard-working team player passionate about technology."
  3. Skills: a short grouped list of what you can actually be interviewed on. Every keyword here is a promise; interviewers pick their questions from this section.
  4. Experience: the section that decides everything (details below).
  5. Projects: essential for juniors, useful for everyone if the projects are real and linkable.
  6. Education: brief; degree, institution, year.

Experience bullets: actions and numbers, not duties

The single biggest difference between a weak CV and a strong one is the shape of the experience bullets. Weak bullets describe duties; strong ones describe outcomes:

  • Weak: "Responsible for maintaining the company website and fixing bugs."
  • Strong: "Cut page load time from 4.1s to 1.3s by moving image processing to a queue and adding response caching — bounce rate dropped 22%."

The formula: verb + what you did + measurable result. Not every bullet will have a number, but a CV with zero numbers reads as a CV of someone who never measured anything. If you don't track metrics at work, start now — your future CV depends on it. Three to five bullets per role; your most recent role gets the most detail.

Getting past the ATS

ATS software matches your CV text against the job description. Practical consequences:

  • Use the job posting's exact terms. If it says "PostgreSQL" and your CV says "Postgres," some systems miss the match. Mirror the posting's vocabulary for skills you genuinely have.
  • Keep the layout machine-readable: single column, standard headings ("Experience", "Education"), no tables, no text in images, exported as a text-based PDF (select-and-copy a line to verify).
  • Skip the graphics. Skill bars showing "JavaScript 80%" convey nothing (80% of what?) and parse as noise. The space is better spent on one more concrete bullet.

Projects: the junior developer's experience section

If you lack professional experience, projects carry your CV — but only real ones. A tutorial to-do app signals you followed a tutorial. What signals ability: a project that is deployed and linkable, solves a problem you actually had, and has a README explaining the decisions. One genuinely finished project outweighs five clones. Describe it like a job: "Built and deployed an inventory tracker used by my family's shop — Laravel, MySQL, deployed on a VPS; reduced monthly stock-count time from 6 hours to 40 minutes."

The mistakes that filter strong candidates out

  • Listing every technology ever touched. Twenty-five skills means the interviewer picks your weakest. List what you can defend under questioning; cut the rest.
  • Unexplained gaps handled by silence. A one-line honest explanation ("2024: family responsibilities / freelance projects") beats letting the reader guess.
  • One generic CV for every application. You don't need a rewrite per job — but reorder skills and swap two or three bullets to match each posting. Ten minutes of tailoring visibly changes response rates.
  • Typos in a document claiming attention to detail. Read it aloud once; have someone else read it once. This filters the most preventable rejection there is.
  • Lying. Inflated titles and invented experience surface in the first ten minutes of a technical interview, and the interview ends there — politely, but it ends.

Before you send it

A final pass worth doing every time: read your CV as the interviewer will. Every line you wrote is a question they can ask. "Optimized database performance" invites "how, exactly?" — if the honest answer is "I added one index a senior suggested," soften the claim or be ready to own the real story. The best CV is not the most impressive one; it's the one whose every line you're glad to be asked about. Then pair it with a structured interview preparation plan — because the CV's only job is to get you into the room.