Developer CV: the 5 things tech recruiters actually look at

At Bluecoders, we hear the same remark over and over from our clients' CTOs: "every CV looks the same."

8 years of experience. Python, Go, Kubernetes. Cloud, CI/CD, architecture. One or two good companies on the resume. It's all there, nothing missing, and yet nothing helps decide between 2 candidates.

So we went back to a simple question: what should a developer CV look like today? Not another template, not a layout trick. A reading grid. What we're actually looking for when we open a CV, and what's almost always missing to make us want to pick up the phone.

Here's what we found.

Note: this article focuses on the developer CV, but most of the elements that make the difference to tech recruiters apply to other roles too. Feel free to reuse them.

Key takeaways

• "8 years of experience" says almost nothing until you know what context those years were spent in.
• A developer CV is now read by 2 readers: a human looking for context, and a machine doing the first screen on keywords.
• 5 elements genuinely differentiate 2 profiles: context, ownership, measured impact, contextualized stack, and how you work with AI.
• The stack and keywords are still essential, but in service of the context, not as a replacement for it.
• Star ratings and progress bars now work against candidates.
• At Bluecoders, our median time-to-deal is 22 days across our 2026 placements. The CVs that move fast are the ones that answer these questions before we have to ask.

Why "8 years of experience" doesn't mean much anymore

Take 2 back-end engineers. Same number of years, same declared stack, 2 trajectories with nothing in common.

The first spent 8 years at a staffing agency, on client-site contracts, on 6-month assignments, on legacy code they never had the mandate to rebuild. The second joined a 15-person scale-up and watched it grow to 250, absorbing 3 architecture changes and a regulatory compliance overhaul along the way.

Both will write "8 years of experience." The problems they know how to solve have nothing to do with each other.

Here's what the number alone doesn't tell you:

• the size of the teams they worked across
• the criticality of the product and the bar that comes with it
• the constraints they operated under: regulatory, technical debt, load, deadlines
• the actual decision-making latitude they were given

A year in a dense environment can teach more than 3 years on a stalled project, and the reverse is also true. Without this information, a technical recruiter can only guess.

Same logic applies to the stack. A list of technologies shows what someone has touched, never what problems they can solve with it. Having "Kubernetes" on a CV can mean you led a zero-downtime migration, or that you applied manifests someone else wrote. Those are 2 different jobs.

A developer CV is read by 2 readers today (don't forget the second one!)

Here's what's changed, and what explains most of the contradictory advice floating around.

Your CV is read by 2 readers, and they're not looking for the same thing.

The first is human. The CTO, the VP Engineering, or the technical recruiter. They want to understand the environment you worked in, what you personally owned, and what it produced. They skim, stop on whatever intrigues them, and decide within seconds whether they want to know more.

The second is a machine. An ATS, an internal search engine, an AI assistant plugged into a candidate database. It does the first screen, and it does it on matches: job titles, technologies, years, location. It doesn't understand nuance, it recognizes patterns.

Hence the constant confusion. One camp tells you to stuff your CV with keywords to pass the filters. The other tells you to write for a human and forget the tech laundry list. Both are half right, because they're talking about a different reader.

A good CV doesn't pick one over the other. It gives each reader what they need, where they're looking for it.

Developer CV: the 5 elements that actually differentiate 2 profiles

This is the grid we apply when reading, and the one we recommend applying when writing.

Element 1: context

One line is enough, placed right under the job title: type of company, size, team size, nature of the product, specific constraints.

B2B SaaS scale-up · 250 employees · 8-person Platform team Critical product used by 200 internal teams · Regulated environment

In 2 lines, your reader knows what your day-to-day looked like. It's the single highest-yield piece of information on the whole CV, and it's the one most often missing. It reframes everything that follows.

Element 2: what you personally owned, not what the team did

The most common confusion, and the most costly one at interview stage. Many CVs describe team achievements in an implicit "we," which makes it impossible to locate the real contribution.

Add an explicit "My role" line:

Owned infrastructure and reliability for the document-processing services.

Nobody will hold it against you for having been one contributor among several. But a maintained vagueness always gets called out at the first technical interview, once the precise questions start. Our advice for standing out to IT recruiters all starts from this principle: precision builds more trust than amplification.

Element 3: impact, when it can be measured

Not every project produces a usable number, and nobody expects you to invent one. When a metric exists, it's worth 3 paragraphs of description.

Reworked the API cache, latency cut 3x (450 ms to 140 ms) Set up observability and alerting, MTTR reduced by 40% Reworked the data-processing pipeline, compute time reduced by 40%

When no number is available, describe the problem you solved rather than the task you completed. "Led a zero-downtime Kubernetes migration" contains no percentage and still says a lot.

Element 4: the stack, put back into its context of use

Keep your technologies, but tie them to the experience where you actually used them, at the end of each block:

Stack: Go · Python · Kubernetes · Terraform · AWS · PostgreSQL · Redis

And group the summary by family in a dedicated column: back-end, infra and cloud, data, tools and quality. The human reader immediately sees where your technical center of gravity sits. The machine finds its keywords. Both readers are served without shortchanging the other.

Element 5: how you work with AI

This is the element that didn't exist 2 years ago, and the one that differentiates fastest today.

Almost everyone uses coding assistants now. Writing "Claude Code, Cursor, Copilot" in a tools list teaches nobody anything anymore. What a CTO actually wants to know is what you delegate, what you check, and what you keep in your own hands:

Claude Code and Cursor to explore, prototype, refactor, document, and write tests. Systematic review and testing before merging generated code. AI to compare approaches and speed up execution, never to decide for me. Prefer simple, tested code over an elegant but fragile solution.

4 lines that describe a working method and a relationship to risk. On a senior role, this block is often what triggers the interview.

Should you strip the stack and keywords off your CV?

No. And that's a direct consequence of the double reader.

Removing your keywords to make the CV "more elegant" makes you invisible at the first screen, the one that decides whether a human will ever read you. Plenty of excellent profiles get filtered out at this stage without ever knowing it.

The opposite doesn't work either. An example of a developer CV reduced to a wall of technologies passes the filters and loses the human 3 seconds later, because it tells no story.

The right answer is a matter of placement:

• Keywords in the summary and at the end of each experience block
• Context and impact in the body text

Each reader finds what they're looking for where they're looking for it.

One last point on the first screen: get your job titles right. "Senior Software Engineer" is recognized by every system, while "Code Artisan" is recognized by none. Creativity belongs in the content, not the title.

What does a good developer CV look like today?

Here's the structure we built, applied to a fictional profile of a Senior Software Engineer with 8 years of experience.

Header First Last · Senior Software Engineer · Paris, France · 8 yrs exp. · LinkedIn · GitHub · Portfolio

Summary Back-end and platform engineer, specialized in critical systems and Intelligent Document Processing. I use AI to move faster, without ever letting up on code quality and reliability.

Experience 1 (2023-2026), Senior Software Engineer, Company X Context: B2B SaaS scale-up, 250 employees, 8-person Platform team. Critical product used by 200 internal teams, regulated environment. My role: owned infrastructure and reliability for the document-processing services. Impact: led a zero-downtime Kubernetes migration. Reworked the API cache, latency cut 3x. Diagnosed and resolved production memory spikes by changing the pagination strategy. Set up observability and alerting, MTTR reduced by 40%. Stack: Go · Python · Kubernetes · Terraform · AWS · PostgreSQL · Redis

Experience 2 (2020-2023), Software Engineer, Company Y Context: Data SaaS, 120 employees, 6-person Backend team. Reworked the data-processing pipeline, compute time reduced by 40%. Designed a rules engine for critical data validation. Stack: Python · AWS · Docker · PostgreSQL · Airflow

Experience 3 (2018-2020), Software Engineer, Company Z Context: software vendor, 80 employees, 5-person Product team. Built new features and optimized performance. Stack: Python · Django · AWS · PostgreSQL

In the side column: How I work with AI, Key skills grouped by family, and What I'm looking for.

What each block does

This CV is designed to be read by 2 people: the CTO who wants to understand context and impact, and the AI that does the first screen. Clear, structured, useful.

Length: detail the recent, summarize the old

The 4-page CV remains the most common mistake among experienced profiles, and it comes from a good intention: keep everything, out of fear that the deleted line was exactly the one that mattered.

The rule that works is simple:

• Detail the 2 or 3 experiences most recent or most relevant to the target role, with context, role, and impact
• Compress everything else into 1 or 2 lines

In the example above, the 2023-2026 experience takes 4 impact bullets and a role line. The 2018-2020 one fits on a single line. Nobody is going to grill you on a role you left 6 years ago, and nobody will hold it against you for having summarized it.

2 pages are almost always enough. Beyond that, it's no longer a CV, it's an archive. Our software engineer job profile breaks down what's expected at each seniority level, useful for deciding what deserves detail.

What still gets good profiles filtered out

3 habits survive even though they now work against candidates.

Star ratings or progress bars for self-assessment

They no longer have a place. A "Python 4/5" carries zero informational value, because the scale is yours alone and nobody else knows it.

Worse, it exposes you: the reader remembers the number and calibrates the technical interview against it. A context line and a measured impact are worth infinitely more than a three-quarters-filled bar.

Piling up secondary technologies

Listing 35 tools dilutes the 5 that matter. The reader is looking for your center of gravity, not your completeness.

Keep what you practice regularly, drop what you touched once. This is just as true for a full stack profile, where the temptation to list everything is strongest.

A missing, or dead, portfolio or GitHub

A link to an empty profile does more harm than no link at all. If you include one, make sure it's current and readable: our tips for a great web developer portfolio cover what actually matters to a technical recruiter.

On the company side: what this changes in screening

This grid reads both ways. A CV poor in context doesn't just hurt the candidate. It mostly slows down the hiring company.

When the information is missing, a whole qualification call is needed to reconstruct what should have fit in one line. On a process with 3 or 4 steps, that's an entire step spent filling a gap.

According to our data, our median time-to-deal is 22 days in 2026, from opening the role to the offer being accepted (on the French market). Averages commonly seen on the French market sit between 12 and 15 weeks.

That gap comes from our method and our database of over 200,000 engineering profiles. But it also comes from something simpler: we work this grid with every candidate we present. A CV that answers the CTO's questions in advance saves everyone a week.

To benchmark a profile against the market, our tech and engineering salary barometer gives the ranges observed across our placements.

In summary

A good developer CV isn't trying to impress. It's trying to make a trajectory readable in seconds, for 2 readers with different needs.

Context, ownership, measured impact, contextualized stack, relationship to AI. 5 elements, a few lines each, and 2 profiles that used to look the same finally become comparable.

Looking for your next role? Check out our tech and engineering openings. We support every candidate through the end of their probation period, and it starts with a CV that does you justice.

Hiring for a technical role? Let's talk about your need.

FAQ

What's the right length for a developer CV?

2 pages maximum in the vast majority of cases. Detail the 2 or 3 experiences most recent or most relevant to the target role, with context, role, and impact. Summarize older roles in 1 or 2 lines. A 4-page CV won't be read in full, and the information that matters gets buried.

Should you list your AI skills on a developer CV?

Yes, but not as a list of tools. Mentioning "Copilot" or "Cursor" teaches a recruiter nothing anymore. Instead, describe what you delegate to AI, what you systematically verify, and the decisions you keep in your own hands. It's this description of method that differentiates, especially for senior roles.

Should you rate your level on each technology?

No. Progress bars and star ratings rely on a personal scale nobody else can interpret, and they often become the basis for a technical interview calibrated too high. Replace them with the context of use: on which project, in which team, to solve which problem.

How do you adapt your CV to pass automated filters?

3 habits are enough:

• Use standard, recognizable job titles
• Surface your main technologies in the summary and within each experience
• Avoid complex multi-column layouts or purely graphic elements that interfere with text extraction

These filters look for literal matches, not equivalences.

Should a web developer CV differ from a full stack developer CV?

The structure stays the same. What changes is the center of gravity highlighted in the summary and the order of the skill families. A full stack profile benefits from showing how they moved between front and back on the same product, while a back-end developer profile should lead with reliability, data, and infrastructure.

What do you put down when no result can be quantified?

Describe the problem you solved rather than the task you completed. "Diagnosed and resolved production memory spikes by changing the pagination strategy" contains no percentage and still demonstrates analytical ability. Not every project produces a usable metric, and nobody expects you to invent one.

Do you need a different CV for every application?

Not an entirely different CV, but a reordered one. Keep the same base and adjust the summary, the order of the skill families, and the level of detail in each experience depending on the role. The goal is for the first 3 lines read to match what the company is looking for.