Engineering CVs fail in two predictable ways: bullets that describe the codebase instead of your effect on it, and skills sections that list every technology ever touched. Recruiters spend their first pass matching your last two titles and your stack against the specification, whether the vacancy sits in a London fintech, a Manchester scale-up or a remote-first product company. The example below is organised around exactly that pass, and everything on this page, from the personal statement variants to the keyword list, exists to make that match instant and honest.
The strongest engineering bullets follow one shape: what you built or changed, in what stack, and what moved because of it (latency, cost, revenue, incidents). If you cannot name the metric, name the scale: requests per day, services owned, engineers unblocked. "Rewrote the reconciliation engine" is a task. "Cut nightly reconciliation from 4 hours to 35 minutes by rewriting the diff engine with batched SQL" is a hire. The same discipline applies to money: "reduced cloud spend £140K a year" earns an interview in a market where every engineering leader has a cost-reduction objective this year.
Section order matters more for engineers than for most jobs. With any professional experience at all, the order is: a header with links, a three-line personal statement, experience, projects only if they add signal, skills grouped by category, education last. Recent graduates invert the bottom half: education and projects climb above experience, because a solid final-year project or open-source contribution outweighs a retail job, and a strong classification (a first or a 2:1) is still worth stating within a few years of graduating. What never works is the alphabet-soup skills block at the top of the page; it pushes your actual work below the fold of the first screen and reads as padding to anyone technical. And since this is a UK CV: no photo, no date of birth, no marital status, and no "references available on request", because every reader already assumes it.
Understand who reads the CV in what order. A recruiter or sourcer goes first, and they are pattern-matching: title trajectory, stack overlap with the specification, recognisable companies or scale markers. The hiring manager reads second and differently: they look for ownership verbs (own, led, designed, drove) versus participation verbs (helped, assisted, was involved in), for judgement calls, and for whether the bullets sound like someone who has actually carried a pager. Write the top third of the page for the recruiter and the bullets for the manager, and both passes go your way. Applicant tracking systems (ATS) sit in front of both readers at almost every mid-size-plus employer, so the layout that survives parsing (single column, standard headings, a clean PDF) is not optional; you can see exactly what a parser keeps from your own CV with our ATS check.
Write the experience section as a story of growing scope. Titles and dates carry more weight than engineers expect: a promotion inside one company outranks two lateral hops, so make promotions visible as separate entries under the same employer. Give your current role three to five bullets and open with a scope statement (services owned, traffic handled, domain), because the reader needs the denominator before your wins mean anything. Every bullet after that earns its line with a change you caused: a number moved, a system replaced, an incident class eliminated, a team unblocked. Duties belong in the job advert, not in your history.
Group skills so a human can scan them in five seconds. Three or four labelled lines (languages, infrastructure, practices) beat one comma wall, and the labels themselves communicate architecture literacy. Order each line by strength rather than alphabetically, because readers assume the first items are your daily drivers, and leave out anything you touched once in a tutorial: the skills block is a menu of interview topics you are offering, and the interviewer will order from it. Keep education short once you have shipped production code: degree, university, year, and the classification if it helps. A current cloud certification can matter for platform-heavy roles; a stack of short-course certificates mostly signals anxiety rather than ability. If a bootcamp is your formal training, list it exactly like a degree, with the course length and the stack it covered, and let your projects section do the proving.
Know the failure modes before you submit. The recurring ones on engineering CVs: vague verbs (worked on, helped with, was responsible for) where owned, built or led would be true; frameworks listed that the candidate cannot discuss for five minutes; bullets that describe the team's achievement without stating the candidate's part in it; and stale artefacts (an objective from five years ago, an expired certification, a dead portfolio link) that make the whole document feel unmaintained. Most of these take minutes to fix and cost interviews when left in. The 2026 wrinkle is AI-assisted development: using coding assistants is now assumed, so listing one as a skill says nothing, while a bullet about review standards, evaluation harnesses or test-coverage gates you set for AI-assisted changes reads as engineering leadership. The same applies to the CV itself: AI-drafted documents converge on the same adjectives and rhythm, and screeners have learned the sound of them. Draft from your real work and cut any sentence you could not defend line by line at interview.
Tailoring is not rewriting your history for every advert; it is reordering emphasis. Read the specification, circle the three requirements it repeats or lists first, and make sure each one is visible in your personal statement or your top four bullets, in the advert's own words where they are honestly yours. If the advert says "event-driven architecture" and your bullet says "queue migration", say both, because keyword filters are literal. Use this page in that spirit: the CV below is a complete, realistic example rendered by our actual template engine, not a cropped screenshot. Open it in the builder with one click, replace Dan's history with yours, then raid the bullet bank, check the keyword list against your target advert, and read the extraction at the bottom to see literally what a parser gets from this layout.
Frequently asked questions
- Should I include personal projects with 4+ years of experience?
- Only if they add signal your job bullets cannot: open-source adoption, a different stack you are targeting, or scale. One strong project beats four toy apps, and a pinned repo with real users beats both. The test is whether the project produces a bullet with an object and a number, like "800+ stars, used in production by 3 companies"; if the best you can write is "built a weather app with React", the line is costing you space that a work bullet would spend better. There are two exceptions worth knowing. First, stack transitions: if you are a Java engineer targeting Go roles, a substantial Go project is your only evidence, so it earns a place above its weight. Second, seniority signalling: maintaining a library, reviewing external PRs and cutting releases demonstrates ownership that some day jobs never offer. Under two years of experience the calculus flips entirely and projects are often your best section. Format matters too: give a project a one-line heading with a link, then one or two bullets in the same outcome shape as your work experience, and keep the whole section under a quarter of the page.
- One page or two for a software engineer in the UK?
- One page up to roughly 8 to 10 years unless you have patents, publications or deep open-source work; two pages of A4 is the hard ceiling either way, and UK recruiters are noticeably tolerant of a tight two-pager where US convention pushes one. Recruiters consistently read dense one-pagers as senior, not junior, and the discipline of cutting to one page forces the prioritisation that makes the remaining bullets stronger. The practical method: keep 3 to 5 bullets for your current role, 2 or 3 for the previous one, and one or two lines for anything older; delete whole roles from more than a decade ago unless the company name itself opens doors. If you genuinely fill two pages with distinct, quantified impact, take the second page, but make page one self-sufficient, because plenty of readers never reach page two. What never earns its space: a skills matrix with self-assessed ratings, a references line, or coursework once you have shipped production code. And fonts are not a length strategy: shrinking to nine-point type to fake a one-pager reads instantly as what it is. Cut content instead; the exercise itself improves what remains.
- How do I handle a stack mismatch with the job advert?
- Lead with transferable architecture experience: queues, caching, API design, schema migrations and observability are stack-agnostic, and hiring managers know that an engineer who has done a zero-downtime cutover in Python can do one in Go. Move any real exposure to the target stack (a project, a migration, a service you touched) into your top three bullets so it is visible on the first pass, and name the overlap explicitly in your personal statement: "Backend engineer, 6 years Python, now shipping Go in production via an open-source CLI." Where the advert and your history use different words for the same thing, use both forms once, because the keyword filter will not infer that "message broker" covers "Kafka". The hard line: never list a technology you cannot interview on. A padded skills list gets you an interview loop designed for someone else, and failing it burns the company for future applications. A near-miss stack with honest framing beats a perfect-match list you cannot back up. And if keyword filters keep screening you out before a human ever reads the page, route around them: referrals and direct applications to hiring managers let a person weigh transferable architecture the way a literal string match never will.
- What if my real metrics are confidential?
- You can almost always share the shape of the number without the number. Percentages and multiples travel safely where absolute figures do not: "cut infrastructure spend 30%" discloses nothing about the budget, and "halved p99 latency" says nothing a competitor can use. When even ratios feel risky, use scale markers instead: requests per day, number of services owned, team size, rollout duration, incident count. "Owned the pricing path for a top-3 marketplace in its category" communicates weight with zero leakage. What you should not do is invent plausible-sounding figures; interviewers probe the numbers you print, and an unverifiable claim that wobbles under two follow-up questions costs more than a vague one. If a former employer's policy is strict, anchor bullets to public facts (launches, published engineering-blog posts, conference talks) and keep the private maths for the interview room, where you can characterise it verbally. One more safe pattern: relative baselines, like "halved build times" or "took flaky-test rate from double digits to under 2%", which describe your effect precisely without exposing anything about the system behind it.
- How should contracting and IR35 history appear on a UK engineering CV?
- List contract roles exactly like permanent ones, with "(contract)" after the title, the client named where the engagement allows it, and the same outcome-shaped bullets; a run of six-month contracts with shipped, quantified work reads as strength, not instability, to anyone who knows the UK market. Group very short engagements under your limited company or umbrella as one heading with client sub-lines, the same way agency work is grouped in other fields, so the page does not read as job-hopping. Two practical points. First, do not put day rates, IR35 status or the inside/outside distinction on the CV itself: those are commercial terms for the conversation with the agent, not screening information, and printing them costs negotiating room. Second, if you are moving from contracting back to permanent employment, expect the motivation question and answer it in the personal statement before it is asked: "returning to a permanent seat for product ownership over breadth" reframes the history as deliberate. The reverse move needs no explanation at all. Whichever direction you are moving, keep the technical evidence identical in shape: scope statement first, then the numbers you moved, because a hiring manager evaluates a contractor's bullets exactly the way they evaluate anyone else's.
- How should I handle AI coding tools on my CV in 2026?
- Listing "Copilot" or "Claude" in a skills section is like listing "Google": using assistants is assumed, so the line adds nothing and can read as filler. What differentiates candidates is evidence of judgement around the tools, expressed as outcomes like any other bullet: review standards you set for AI-assisted changes, evaluation harnesses you built, test-coverage gates that held while throughput rose, or an internal tool that made the assistants materially more useful for your team. Those are engineering-leadership bullets that happen to involve AI, and they age well. Two cautions. First, do not let a model write the CV itself unsupervised: AI-drafted CVs converge on the same adjectives and cadence, and screeners have developed an ear for it; draft from your real work and keep every sentence defensible. Second, be ready for interviewers to ask exactly how you use assistants day to day, because it has become a standard probe for depth: an answer that shows where you trust them and where you do not is worth more than any line on the page. If an advert explicitly names AI-assisted development among its requirements, mirror the phrase once where it is honestly true for you, inside an outcome bullet, and let the interview carry the depth.