A software engineer résumé example, and what a parser makes of it

One complete backend engineer résumé, written out in full. The person is invented. The reading, the score and the screenshots are real.

ConxfolioPublished 2026-09-12

— structure first. the wording is the easy half.

Most résumé examples are a picture of a finished page and a paragraph of encouragement. This one is written out in full, so you can read the lines, and then put through the two tools on this site so you can see what software makes of it. The candidate is invented. Ada Fennimore does not exist, Northwind Pay does not exist, and every figure below was chosen to demonstrate a shape.

The example, in full

Why the lines are built this way

Seven achievement lines, every one of them beginning with a verb, and five of them carrying a figure. The figures are the part candidates skip and the part that does the work: "improved reconciliation" and "cut reconciliation from 40 minutes to 6" describe the same afternoon and only one of them can be argued about at an interview. Where a number genuinely does not exist, the line says what changed instead, as the runbook line does.

The two roles are not balanced on purpose. Four lines on the current job and three on the previous one is the right slope: the further back a role sits, the less of it a reader needs. The summary is two sentences and names a domain, which is what a summary is for. There is no objective, no skills bar chart and no photograph, because none of those survive extraction as information.

What the readers made of it

We pasted the text above into the résumé builder and let it read. The review screen is the point of the exercise: everything the file produced is shown beside where it came from, before a word of it enters the editor.

It read two roles, one degree and nine skills, and it asked one question: whether the senior role should be listed as a project rather than as experience. That question is the whole design of the reader. A parser that guesses is a parser that silently moves your current job into a section nobody reads. The readers here may quote the document and may re-map a section the rules could not name, and where they are unsure they ask, with nothing applied until you answer.

Nothing here involves a language model. The readers are deterministic functions over the lines of one section, each with its own rule and its own confidence, and every string one of them emits is checked in code to be a span of your document. A field that fails that check is dropped and counted rather than kept.

What the checker scored it

Ninety-seven out of 100, with one improvement remaining. The full arithmetic is in the article on how the score is made, but the interesting part for an example is the one point it lost: readable volume. At 162 words this résumé is short, and the volume rule pays out gradually rather than at a threshold, so it collected 12 of its 20 points there.

That is worth sitting with. A short, well-structured, evidenced page scores higher than a long one with a sidebar, and the remaining points are cheap to buy with a third role or two more lines. The checker prints what each remaining fix is worth, so you can decide whether 3.2 points is worth your evening.

Take the shape, leave the sentences

Open the builder, paste your own résumé into the import, and correct what it read. Then compare your page against the shape above: verb-first lines, a figure where a figure exists, a slope from recent to old, and a summary that names a domain rather than a temperament. The design gallery holds 37 layouts and the words do not change when the paper does, so the structure is the only part of this example worth borrowing.