Should I list every programming language on my CV?

No. List the languages you can work in comfortably and are prepared to discuss in depth. A wall of language logos signals 'collected keywords' rather than real depth. Group them by proficiency if it helps: expert, comfortable, familiar. And never list something you learned once and wouldn't confidently use in a take-home test.

Do software engineers need a portfolio link on their CV?

A GitHub profile is worth including if it has meaningful, maintained projects. A portfolio site is useful for front-end and product-adjacent roles where design and presentation matter. Neither is mandatory — a strong work history and well-described projects in the CV itself carry more weight than a sparse or unmaintained portfolio.

How long should a software engineer's CV be?

One to two pages. Junior engineers: one page. Mid-level and senior: one to two. Staff+ and above: two is fine if the content justifies it. The tech industry skews slightly more tolerant of longer CVs than other fields, but padding with technology lists, skills matrices, and proficiency bars adds length without adding value.

2026-08-01 · Daniel Zambrano

CV Tips for Software Engineers: What Hiring Managers Actually Look For

A dev CV packed with framework names and no measurable outcomes will get filtered out before a human ever reads it. Hiring managers want to know what you shipped, what changed because of it, and whether you can operate at the level the role demands — not which technologies you’ve touched.

Software engineers are often worse at writing CVs than people in less technical fields. That’s not an insult — it’s a structural problem. Engineers spend their careers describing what systems do, not what they personally accomplished. When it comes time to write a CV, that habit shows up in the worst possible way.

Here’s what separates the CVs that get interviews from the ones that don’t.

The mistake most dev CVs make

The single most common error on engineer CVs is listing technology instead of impact. It looks like this:

Used React to build frontend components
Worked with PostgreSQL and Redis
Implemented REST APIs using FastAPI

Every candidate applying for that role has “used React.” That bullet tells a hiring manager nothing about you specifically. It doesn’t differentiate you from the other 80 applicants who also listed React.

Compare it to this: “Rebuilt the customer dashboard in React, reducing average page load time from 4.8s to 1.9s and increasing daily active usage by 34%.”

Same technology. Completely different signal. The second version tells the hiring manager that you shipped something, it worked, and you measured the outcome. That’s what they’re actually hiring for.

The formula is simple: what you did + what technology + what changed. Not every bullet will have a hard metric, but most can. Dig into your memory. What did the system do before? What did it do after? How many users? How much time saved? Even rough numbers are better than none.

Skills section done right

The skills section of a dev CV is both essential and frequently embarrassing. Two failure modes are common.

The wall of logos: listing every language, framework, database, tool, and cloud provider you’ve ever typed in. It reads as filler, and it raises immediate questions. Do you actually know all of these? At what depth?

The lie: listing things you once used in a tutorial six years ago, or that you’d fail a basic technical screen on. Don’t do this. Interviewers will ask about your skills. If you can’t talk to something intelligently, take it off.

The right approach is to group skills by category and be honest about proficiency where it matters:

Languages: Python (primary), Go (proficient), TypeScript (working knowledge)
Frameworks: FastAPI, Django, React
Databases: PostgreSQL, Redis, BigQuery
Infrastructure: AWS (EC2, S3, RDS), Docker, Terraform

Honest proficiency indicators are a feature, not a weakness. They show self-awareness, which is a trait every senior engineer needs.

Describing your projects

Side projects, open source contributions, and personal work can add real signal to a dev CV — but only if you describe them correctly.

For each project, answer three questions:

What does it do? One sentence. No jargon. If you can’t explain it simply, you don’t understand it well enough to present it.
What did you specifically build? Not the project overall — your contribution. The auth system, the data pipeline, the deploy tooling.
Does it handle anything at scale? If it processes real data, serves real users, or runs under load — say so. Numbers are compelling.

One important note on GitHub links: only include them if the repository is maintained and readable. A link to a private repo, a repo with a single commit from 2019, or a repo with no README does not help your application. If the code isn’t something you’d be comfortable walking through in an interview, leave the link out.

Impact over tech stack

Hiring managers are trying to answer one question: what will this person contribute? They are not checking off framework names. They are asking whether you make things better.

“Led migration from monolith to microservices” is interesting. “Led migration from monolith to microservices, reducing deployment time from 45 minutes to 8 minutes and enabling independent scaling of the payments service, which was under highest load” is a hire.

For each role on your CV, ask yourself: what was different because I was there? If you can’t answer that, you probably haven’t dug deep enough. Talk to the outcomes, not the inputs.

Some examples of the shift:

From: “Wrote unit tests for backend services” → To: “Increased test coverage from 34% to 81%, catching a class of regression bugs that had previously reached production quarterly”
From: “Worked on CI/CD pipeline” → To: “Rebuilt CI/CD pipeline, cutting average build time by 60% and unblocking the team from a daily bottleneck”
From: “Contributed to API design” → To: “Designed public API consumed by 12 enterprise clients; kept backward-compatible through three major product iterations”

AU and US differences for tech roles

If you’re applying in both markets — or switching between them — there are a few differences worth knowing.

Length: US tech roles typically expect a one-page CV for engineers with under ten years of experience. Australian employers are more flexible; two pages is standard and accepted even at the five-year mark. Don’t try to compress a rich career history into one page for an Australian audience.

GitHub and portfolio links: More expected in the US, especially for product and startup roles. Australian job ads are less likely to ask for them explicitly, but including a strong profile doesn’t hurt. Make sure it’s maintained if you include it.

References: In Australia, “References available upon request” is still a common closing line. In the US, this line is considered outdated and is typically omitted — employers assume you can produce references and will ask when they want them.

Personal details: Neither market expects photos, date of birth, or marital status. If you’re adapting a CV from Germany, Japan, or the Middle East, strip those sections entirely.

Where QuillCV fits in

QuillCV generates CVs that are tailored to a specific job description — which means the impact language, keywords, and structure are matched to what that particular employer is looking for. For engineers, this is especially useful because most dev CVs are written once and applied everywhere. The job description is where the signal lives. Using it to shape your CV is the whole point.

You can also select your target country, and QuillCV applies the right format automatically — so you’re not sending a US-style one-pager to an Australian employer or a German Lebenslauf format to a startup in San Francisco.

The technology you know is table stakes. What you did with it is the story. Make sure your CV tells it.