Writing a CV that survives

How most "AI resume scores" work

The resume tools that charge monthly for "AI optimization" mostly do one thing: parse your CV to text, parse the job description to text, count the overlapping keywords, and sell the overlap back to you as a score. A "95% match" means your CV contains most of the posting's words. Nothing about whether your experience is real, relevant, or readable. Worse, the advice that falls out of that number is always the same: stuff more keywords in. Recruiter-side screening keeps getting better at flagging exactly that.

Cvlinter deliberately doesn't work that way, and the differences are checkable:

• the parse score measures the one thing you can measure: whether an ATS can extract your CV. Every lost point is itemized. The full method is public on the methodology page.
• content is never scored. Writing quality is a judgment, so you get a findings tally, "1 thing to fix, 2 to consider", where every finding points at a specific bullet. No fictional "your content is 62/100".
• the JD match counts evidence, not keywords. A requirement is only "evidenced" if one of your bullets shows you doing it, quoted back as the receipt. A skill that merely appears in your skills list is labeled what it is: mentioned, never shown. And a missing requirement is not an instruction to add keywords.

First, survive the parser

Before a human reads your CV, a parser does, and layout is where good CVs die. These are the rules the parse score enforces:

• Single column. Multi-column layouts read fine to humans and scramble in many parsers. Columns get interleaved or dropped.checked: two-column
• Real text, never a scan. An image-based PDF forces OCR, which genuinely degrades extraction. The most damaging formatting mistake there is.checked: scanned-cv
• Standard section headings. EXPERIENCE, EDUCATION, SKILLS, PROJECTS. Clever headings ("Where I've been") can cost you an entire section. If a section extracts empty while its heading exists in your text, that's scored as the most serious parse failure there is.
• One or two pages. Engineering convention is 1 page under ~10 years of experience, 2 at most.checked: page-count
• No graphics, icons, or skill bars. Parsers can't read them; at best they're invisible, at worst they mangle nearby text.convention
• Name, email, and phone as plain text. Not inside a header image or text box. Missing contact essentials are the heaviest per-field deductions in the score.

The parser preview shows you the result directly: your CV side-by-side with what was extracted, mis-reads flagged. And once your findings are fixed, the ATS-safe export gives you a copy in a layout we've verified against the same live parsing engine.

Write bullets that carry evidence

A recruiter skims bullets for outcomes. The classic frameworks all force the same discipline. Say what happened, prove it with a number:

• XYZ: accomplished X, measured by Y, by doing Z. "Cut p95 API latency 40%, measured in New Relic, by adding Redis caching and tightening the worst queries."
• STAR: situation, task, action, result. Better for interviews than bullets, but the R is non-negotiable either way.
• CAR: challenge, action, result. "Facing 3× traffic growth, redesigned the pipeline on Kafka. 2M events a day, zero downtime."

The lint checks the failure modes of that discipline:

• Weak openers. "Responsible for", "worked on", "helped". Duty phrasing, not impact. Start with what you built, led, cut, shipped.checked: weak-opener
• Responsibility beyond the first word. A bullet can open strong and still describe a job description. Judged per bullet, by substance.checked: responsibility-phrasing
• Roles with no numbers at all. Scale, speed, money, users, hours saved. Anything countable makes the same claim credible.checked: no-metric
• Claims without evidence. "Significantly improved performance" asserts an achievement and proves nothing.checked: vague-claim
• Over-long or fragmentary bullets. Past ~45 words a bullet stops being skimmed; a four-word fragment spends a line saying nothing.checked: long-bullet
• First person and tense drift. Implied first person, past tense for finished work, present for current. Mixing them reads as unedited.checked: first-person
• End bullets with periods, consistently. Either convention is fine; mixing them isn't.convention

When a bullet is flagged, the fix flow asks what you actually did and tightens your answer. Suggestions use only your own material, and any invented number is rejected automatically before you see it. We don't write bullets for you; a generated achievement is a lie with good grammar.

The summary (if you have one)

Convention says skip the summary unless you're changing careers or past ~10 years of experience. Your bullets should carry the story. If you keep one: two or three tight sentences of verifiable fact (years, stack, scale, domain), no adjectives a recruiter can't check. "Passionate, results-driven team player" spends your most expensive line saying nothing.checked: summary-buzzwordchecked: summary-length

Skills that hold up

• Every listed skill should be demonstrated somewhere. A skills section is receipts for the bullets. A recruiter can't verify a skill no experience shows.checked: skill-unevidenced
• And the reverse: tech you actually used belongs in the list. Keyword filters usually search the skills section; tools that live only in prose can be missed.checked: skill-unlisted
• Plain comma-separated lists under simple category labels parse best. We verified against the live engine that decorative separators and inline category labels create phantom terms.convention
• Know that parsers rewrite your skills. Normalization can replace what you wrote with something else entirely. We've watched "Vercel" become "Linux Kernel". The preview shows every replacement in red, because a recruiter searching your actual term gets zero hits on the replaced one.

Using a chatbot instead

You can get useful CV feedback for free by pasting your CV into any capable chatbot with a good prompt. Try it. Two things it can't show you, because it never sees them: what an ATS actually extracts from your specific file (layout survives or it doesn't. That's a parser question, not a language question), and whether its rewriting drifted from what you can defend in an interview. That second one matters: generic AI rewrites are exactly what recruiter-side screening is learning to flag. Everything here checks your real file against a real parsing engine, and never puts a claim in your mouth.

Parse your CV to see all of this against your own file. Nothing is stored, and the method behind every number is on the methodology page.