Write a CV that proves you shipped, not just used
Structure your stack so parsers read it, turn commits and incidents into numbers, and keep your links from breaking the file.
Why strong engineers get filtered out early
Plenty of engineering CVs fail before a human ever opens them. Not because the work is weak, but because the file was built for a designer's eye rather than a parser. A two-column layout, a skills matrix with rating dots, contact details tucked inside the page header: each one is a place where your text arrives scrambled, or never arrives at all.
The second filter is a person skimming for evidence. A line saying you worked with Kubernetes, Terraform and Go tells them nothing about scale, ownership, or whether you were the one carrying the pager at 3am. A line saying what broke, what you changed, and what the graph did afterwards answers all three in one breath.
So the job is small and specific: make the file machine readable, then make every line earn its space. Keep one master CV with your full history, then rewrite the top third for each ad so your stack order and first two bullets mirror the words that team actually used. HRLens builds that tailored version from your existing file, so it costs minutes rather than a whole evening.
Three things that decide whether you get read
A stack section a parser can follow
Grouped, labelled lines: languages, frameworks, data, cloud, testing. No tables, no rating dots, no three-column grid.
Bullets that open with the outcome
Latency, error rate, deploy frequency, cost. Say what moved first, then name the stack that moved it.
Links that survive the export
GitHub and portfolio in the body as plain text, never buried in a header a parser quietly drops.
How to rewrite a role in four passes
Start with what shipped, not what you were assigned
Drop "responsible for" and "worked on". Name the feature, the migration, the service you owned end to end.
Mine your incidents for evidence
One line per incident class: what broke, what you shipped, what stopped it coming back. On-call is ownership.
Borrow the ad's vocabulary, exactly
If they write Postgres, don't write PostgreSQL 15 in a footnote. Match spelling and casing where it's honestly true.
Cut anything a reader has to guess at
Internal project codenames, tools you touched once, and duties lifted straight from an old job description.
Before and after
Same experience, two very different files
| Section | What most engineers write | What clears the first screen |
|---|---|---|
| Tech stack | One paragraph of forty comma-separated tools | Short labelled lines by category, ordered to match the ad |
| Experience bullet | "Worked with React and Node in an agile team" | "Cut checkout load time from 4.1s to 1.3s by code-splitting the React bundle" |
| On-call and incidents | Left out completely | What broke, what you shipped, what stopped repeating |
| GitHub link | Pasted into the page header, sometimes as an image | Plain text in the contact block, full address visible |
| File | Design tool export or a .pages file | Text-based PDF exported from the source document |
| Tailoring | One CV sent to sixty openings | Title, stack order and top bullets rewritten per ad |
Rewrite it for the job you actually want
Bring your current CV. Get an ATS-safe version tailored to the ad in front of you, with the stack section fixed.
Questions engineers ask us
How do I list my tech stack so an ATS reads it correctly?
Use one plain heading, Skills or Tech Stack, then short labelled lines: Languages, Frameworks, Data, Cloud, Testing. Separate items with commas. Skip tables, text boxes and multi-column layouts, because parsers often read those out of order. Spell each tool the way the job ad spells it, and leave off anything you would not want to be interviewed on.
Should I put my GitHub link on my CV?
Yes, if the profile shows recent, readable work. Put it in the contact block as plain text with the full address visible, not hidden behind the word portfolio and not inside a page header or footer, where some parsers drop it. Two links is plenty: GitHub plus one portfolio or professional profile. A dead or empty repo list hurts more than no link.
How do I write measurable bullets when the work was internal?
Internal work still has numbers. Reach for build times, deploy frequency, error rates, p95 latency, test coverage, ticket volume, on-call pages, or infrastructure cost. Write outcome first, method second: what changed, by how much, and what you shipped to change it. If a figure is genuinely confidential, name the scale instead: users served, services owned, requests per second, team size.
How long should a software engineer CV be?
One page for your first few years, two once you have several roles of shipped work behind you. Two pages is completely normal at senior and staff level. Length is rarely what sinks you. Filler is: certifications nobody asked for, every library you have ever imported, and responsibilities copied word for word from an old job description.
What file format should I send?
Export a text-based PDF from your source document. Word is fine when the ad asks for it. Avoid design tool exports that store text as shapes, .pages files, and anything scanned. Quick test: open the PDF, select all, paste into a plain text editor. If the order reads oddly to you, the parser sees the same mess.
Do I really need a different CV for every job ad?
You need a different top third. Keep one master CV with your full history, then reorder the stack line, adjust your title, and rewrite the first two bullets so they echo the ad's language. That is the difference between keyword-adjacent and keyword-matched, and with the HRLens CV builder it takes minutes per application rather than an evening.