How to write a developer CV that actually gets read

One page is enough if you have under five years of experience. Two pages is fine for more. A third page almost never helps, because the reader stops long before it.

If your CV is long, the fix is rarely smaller fonts. Cut the oldest jobs down to one line, remove skills you no longer use, and delete anything that does not help with the role you are applying for.

Right under your name, write two lines that say who you are and what you are good at. Name your main stack and your level, and mention the kind of work you have done.

A good example: Full stack developer with four years of experience building web applications in React, Node.js and PostgreSQL. Shipped customer-facing products for two startups and maintained a payments integration used daily.

A weak example: Passionate team player looking for a challenging opportunity. It could describe anyone, so it tells the reader nothing.

Most CVs list duties: responsible for the backend, worked on the dashboard, handled bug fixes. Duties tell a reader what your job title was. Results tell them what you can do.

For each role, write three to five short bullets that describe something you built or improved, and the effect it had. Numbers help when you have them, but do not invent them.

• Weak: Worked on the checkout page.
• Better: Rebuilt the checkout page in React, which cut the average load time from about six seconds to under two.
• Weak: Responsible for database maintenance.
• Better: Added indexes and rewrote three slow queries, so the monthly report that used to time out now runs in under a minute.

If you cannot measure the effect, describe the scale or the difficulty instead: how many users, how big the codebase, how many services, how tight the deadline.

A skills section should help a reader match you to the job description at a glance. Group the items so they are easy to scan: languages, frameworks, databases, tools and cloud.

Only list what you could discuss in an interview. If you used a tool once in a tutorial, leave it out. Interviewers often pick one item from your list and ask about it, and a skill you cannot talk about costs you more than a missing one.

Put the skills the job asks for near the top of the list. This is not dishonest. It is simply ordering your real skills by relevance.

If you are early in your career, or switching fields, projects matter more than job history. Give each project one line on what it does, one line on the stack, and a link to the code or a live version.

Make sure the links work and the repositories are readable. A short README that says what the project does and how to run it is worth more than a large unfinished codebase.

• Send a PDF unless the application asks for another format. Fonts and spacing survive in a PDF.
• Name the file clearly, for example Ayesha-Khan-Frontend-Developer-CV.pdf, not final-final-2.pdf.
• Use a plain layout with one column. Fancy templates with icons, skill bars and graphics often break when software reads them, and recruiters use that software.
• Put your email, phone number, location or time zone, and links to your GitHub or portfolio at the top.

• A photo, date of birth or marital status. They do not help for most remote tech jobs.
• Spelling and formatting slips. Read the whole thing aloud once. Then ask a friend to read it.
• Skill bars and ratings like Python 80%. Nobody knows what 80% means.
• A different CV every time with no tailoring. Change the summary and the order of your bullets to match the role. It takes ten minutes.
• Long paragraphs. Short bullets are far easier to scan.

Open the job post next to your CV and underline the requirements. For each one, ask whether a reader could find proof of it in your CV within thirty seconds. If not, move it up, rewrite the bullet, or add a project that shows it.

Then send it. A good CV sent today beats a perfect one sent next month.