Writing your CV is like writing production code — it should be simple, clean and readable. The single goal of your CV is to persuade someone that you’re worth 30 minutes of their time for an interview.
Here’s what I’ve learned from reviewing software developer resumes, interviewing candidates, and helping devs prepare for roles in tech.
First Principles
Your CV isn’t a memoir. It’s a spec sheet. Its only job is to get you past the first hurdle and into the interview.
That means:
- No long blocks of text.
- No filler (“hardworking, detail-oriented team player” — cool, same).
- No fancy and colourful designs.
You need to prioritise clarity and relevance – and wherever possible, quantify your business impact.
The Anatomy of a Good CV
1. Top section (the signal zone)
This is the bit people actually read. It should take 3 seconds to figure out:
- Your name.
- Some contact details (use a professional email address, not bugsbunny345@gmail.com).
- A concise 1-2 sentence summary of what you do and what makes you tick.
2. Experience (reverse chronological)
Next up is your experience.
Unless you have no experience, this always comes first and starts with your current role.
Each job entry should be structured the same way using concise bullet points:
- Built [X] that helped [Y] do [Z].
- Led a team of N engineers to launch [feature/project], increasing [outcome] by [X].
- Introduced [technology/process], improving [outcome] by [X].
Tip
Use active verbs, measurable impact, and real context. If all your bullet points start with “Responsible for…” — refactor.
Here’s what it looks like in practice:
- Led 3 developers in migrating a Java monolith to 4 new Go microservices, improving scalability by cutting response times by 80% to under 50ms.
It covers specific skills, exactly how you used them, and quantifies the impact your work had.
Contrast that to this:
- Led migration of Java monolith to Go microservices, improving overall website scalability.
See the difference a few numbers add?
3. Education
This can go below your experience.
The main things you want to cover are:
- Degree, university name, grade
- Dates
- Any standout detail like highly relevant projects
Short and sweet is best here when you have experience under your belt.
Tip
If you’re entry-level, you should flesh this section out a bit more. Education plus projects is what will set you apart from other candidates in absence of experience.
4. Projects (if relevant)
Only include personal projects if they’re:
- Well built or interesting
- Open source, shipped, or live
- Relevant to the roles you want
Link to GitHub, deployed demos, or blog posts. Briefly say what it is and why it matters.
5. Skills
Some devs prefer to skip this and highlight skills in their experience section. If you’re targeting a specific tech stack though, a skills section can be useful.
Keep your skills high signal, structure them nicely and ensure they’re relevant to the job:
- Frontend: React, Next.js, Tailwind
- Backend: Go, PostgreSQL, Redis
- Tools: Docker, GitHub Actions, AWS
This makes it easy for the recruiter or hiring manager to see at a glance that your stack is the right fit for the job.
The Worst Red Flags
Sometimes I’ve looked at a CV and died a bit inside.
Here are some things you should avoid to stop the hiring manager suffering the same fate:
- Don’t include photos.
- Don’t use those fancy and colourful two-column designs you found online.
- Don’t write “References available on request". Everyone knows.
- Don’t lie — tech interviews are good at finding gaps.
Format & Length
- 1 page is ideal for junior–mid devs.
- 2 pages is fine if you’ve got some more experience.
- Always export to PDF so the formatting stays in-tact.
- Use real file names:
john-smith-cv.pdf, notMyCV-final-V3-actual-real-one.pdf
Final Thoughts
Want to skip the formatting and just get started?
Download my CV template here – it’s based on my own, so it’s tried and tested and regularly updated.
Ready to land your next role?
Head over to findatechjob.dev to search across thousands of high-quality tech jobs.