Legible
Real example
Real example, anonymised
Senior Backend Engineer. Seven years across four companies in Copenhagen. Thirty-plus applications sent, zero callbacks. Below is the full diagnosis: what the review found, the interview questions that unlocked the missing evidence, and what the CV looked like before and after.
Main problem found
The right background for the role is there. The problem is that the CV does not prove it fast enough for a recruiter to trust the level. Every role describes what was done, but none of them show what changed because of it. Without outcomes, seniority cannot be confirmed from the page.
Bullets like "Contributed to improving system performance" and "Worked on improving data processing reliability" describe involvement, not ownership. They could have been written by a graduate or a staff engineer. The level is invisible.
A recruiter screening for a senior backend role needs to confirm seniority fast. Without at least one result per role — latency, error rate, deployment count, scale — there is nothing to anchor against. The CV gets set aside, not rejected.
The experience was real and significant. A core API endpoint cut from ~500ms to ~270ms. A fragile data pipeline reduced from 5–10% failure rate to under 1%. Deployment failures at CloudOps cut from 15–20% to 5–8%. None of it appeared on the CV.
Lead every role with one quantified result. The exact number matters less than having a number at all. "Reduced API latency by 45%" is immediately useful. "Contributed to performance improvements" is not.
Three immediate actions
What happened next
After the diagnosis, a short interview worked through each role in sequence — pushing past the vague descriptions to find the actual results underneath. The rewrite did not add anything. It made what was already true legible. Below are three exchanges that shaped the rebuilt CV directly.
Legible: "I need the actual numbers. What was the response time before, and what did it drop to?"
Alex: "Before: around 450–500ms on average, with spikes well above that under load. After: 250–300ms consistently. Roughly 40–45% reduction, and a lot less tail latency too."
Legible: "What were the failure rates before and after, roughly?"
Alex: "Before: roughly 5–10% of jobs had issues — a lot required manual intervention. After: under 1%, and most were auto-recovered. Manual fixes went from daily to maybe a couple of times a week."
Legible: "What changed in practice — how many deployments were failing before, and what happened after your changes?"
Alex: "Before: roughly 15–20% of deployments had some failure. After: 5–8%, and most were caught earlier in the pipeline before hitting production."
Ready to start
Submit your CV and the role you are targeting. You get one named problem, one explanation, and the first things to fix, free, no payment needed.