Software engineer CV that gets past an ATS

Developer CVs fail in a specific and avoidable way: they are designed like a portfolio and read like a wall. Here is what actually happens to one on the way to a hiring manager.

The skills wall works against you

Most engineering CVs open with sixty technologies in a grid. It feels comprehensive. To a recruiter it is unreadable, and to a parser it is sixty keywords with no evidence attached.

Group them, cap them, and put the strongest first:

`` Languages Python, JavaScript, Go Backend Django, FastAPI, PostgreSQL, Redis Frontend React, TypeScript, Tailwind Infra Docker, GitHub Actions, AWS (EC2, S3, RDS) ``

Eight to twenty named technologies you could be interviewed on. Listing a language you used once in a tutorial is a trap you set for yourself.

Write bullets a parser and a human both survive

The pattern that works: verb, what you built, what changed.

• "Built the payments reconciliation service that settles daily transaction volume across three merchant banks."
• "Cut p95 API latency from 800ms to 190ms by adding a read replica and removing an N+1 query in the order endpoint."
• "Migrated a Django monolith to six services with no customer-facing downtime."

Note what these avoid: no "responsible for", no adjectives, and no number that did not come from a real measurement.

Spell out the acronyms once

Parsers match on strings. "CI/CD" and "continuous integration" are different strings, and a job description might use either. Write "continuous integration (CI/CD)" the first time and the short form afterwards.

Same for "PostgreSQL" rather than "Postgres", "JavaScript" rather than "JS", "Kubernetes" rather than "K8s".

Your GitHub link is a liability if you do not curate it

A recruiter who follows the link and lands on forty repositories — thirty of them tutorial follow-alongs with no README — learns something you did not want to tell them.

Before you link it: pin four repositories, write a README for each one that says what the project does and what you built, and archive the rest. If you are not going to do that, leave the link off. A missing GitHub is neutral; a messy one is not.

Projects section: three, described properly

For each: name, stack, one line on what it does, one or two lines on what you built. Not a list of features — a statement of your contribution.

If you are early in your career this section carries more weight than your employment history, so put it above Experience.

Two-column layouts are a real risk here

Developer templates love a dark sidebar. It looks good, and it interleaves when flattened to plain text, which is what a parser reads. If you are applying through a large employer's careers portal, use a single column.

The Terminal template is the two-column developer layout for direct applications and referrals. The Classic template is the single-column version for portals. Keep both.

Let the tool write the project bullets

If you connect GitHub in the builder, we read the repositories you select — README, languages, your share of the commits — and draft résumé bullets from them. It will not invent numbers that are not in your data, so a repository with no README produces a short honest bullet rather than an impressive false one. Edit everything it writes.