Technical CV Optimization for Software Developers and Engineers: GitHub, Projects, and Competencies

A software developer CV has three readers. The applicant tracking system extracts the text into fields. A recruiter, who may not write code, searches those fields for the terms in the job ad. Then an engineer reads the CV to judge what you have actually built. Each of them needs something different, and a good developer CV serves all three without tricks.

Group the skills section

A single comma-separated line of twenty technologies is hard to scan. Group them by area instead, and spell each one the way the job ad spells it. In the CV it can look like this:

• Languages: TypeScript, Python, Go
• Frontend: React, Next.js, Tailwind CSS
• Backend and data: Node.js, PostgreSQL, Redis
• Infrastructure: Docker, Kubernetes, GitHub Actions, AWS

A few rules keep the list honest and searchable:

• If the ad says "PostgreSQL", do not write only "Postgres". A word-for-word search does not know they are the same thing.
• Write an abbreviation out once where the ad does: "Continuous Integration (CI)".
• List what you could discuss in a technical interview. A tool you tried once in a tutorial invites questions you cannot answer.
• Use words, not logos or rating bars. A parser cannot read a logo, and an engineer cannot tell what "four dots out of five" means.

Show links as visible text

GitHub, a portfolio site or a published package is often the strongest evidence a developer has. Do not hide the address behind a word like "GitHub" or "Portfolio". When text is extracted from a PDF, the clickable link sits on a separate layer that some tools drop, and what remains is the bare word with nowhere to go. Write the address itself, short and without "https://":

• github.com/yourname
• yourname.dev

Put these lines in the contact block in the body of the page, not in a header. The parser view shows field by field whether your links were found.

Projects an engineer can check

For each project that matters, give one line on what it does, the stack, your part and a link. One project with a short README that explains how to run it says more than a long list of repositories nobody will open.

Example:

invoice-parser · Open source, 2025 · github.com/yourname/invoice-parser

• Command-line tool that turns PDF invoices into CSV; Python, pdfplumber, pytest
• Wrote the table-detection module and the test suite; two outside contributors have since added features

Bullets: your part, the change, the evidence

Software is built in teams, so the CV has to make clear which part was yours. Start with a verb that names your own action (built, migrated, refactored, automated), say what changed, and add a measurement if you have one.

If you have no number, describe the scope: how many services, users or teams were affected. Our guide to quantifying achievements on a CV covers where to find figures you can stand behind.

Match the ad without stuffing it

Read the job ad, list the technologies it names as required, and check that each one you genuinely have appears in a bullet as well as in the skills list. Pulling keywords from a job description walks through that step. The matching modes on this site then compare your CV and the ad three ways: strict, normalized and semantic. The difference between them shows which terms a word-for-word search would miss, for example "JS" in your CV against "JavaScript" in the ad.

Checklist before you send it

• One column, real selectable text, no skill bars or logos
• Skills grouped and spelled as in the ad
• GitHub and portfolio written out as visible addresses
• Three to five bullets per role, each naming your part and its result
• Two or three projects with the stack, your part and a link
• Dates in one consistent format, newest first