Career · 2026-08-08 · 15 min read

Developer, data, and product CV: real stack

How to write a tech CV for developers, data, and product: honest stack, scoped impact, and an ATS-readable PDF. What hiring managers actually scan. ClarCV.

In tech, your CV competes on two fronts: the ATS looks for stack keywords, and the technical interviewer looks for evidence. An endless language list without context is not enough. Neither is a creative design the parser cannot read. You need clarity, proof, and prioritization.

This guide covers software, data, QA, DevOps, and digital product profiles. The principles are shared: scoped achievements, an honest stack, selected projects, and a role-focused summary. Adjust emphasis: a senior backend engineer does not sell the same way as a junior data analyst.

ATS parsing and PDF format are in how to make a CV for ATS filters. The analyst profile (SQL, BI, impact) is in data analyst CV. This page is about stack, achievements, and how a technical hiring manager reads you.

A structure that works in tech

Recommended order: contact (with GitHub/portfolio if it adds value), summary, key technical skills, experience, featured projects (if useful), education, and certifications. Languages and soft skills go last unless the ad marks them as critical.

• Summary: role + years/context + domain (backend, data, mobile…) + one impact line.
• Skills: grouped (languages, cloud, data, tools) without fake proficiency claims.
• Experience: bullets with problem → action → result.
• Projects: 2–4 max, with stack and outcome—not generic tutorials.

Skills: how to list your stack without looking like spam

Before: “Python, Java, C++, Go, Rust, Haskell, COBOL, Excel, Word, PowerPoint…” After: “Python, FastAPI, PostgreSQL, Docker, AWS (ECS, S3), pytest”—tools you actually used in recent roles or strong projects. Everything else can live on LinkedIn or appear only if the ad asks and you can defend it.

Exact spelling matters for ATS: “PostgreSQL,” “Kubernetes,” “TypeScript.” If the ad says “React” and you only write “modern frontend,” you may miss the match even if you know React. Be specific and truthful.

Experience: from tickets to impact

Tech hiring managers dislike bullets that say “participated in the development of…” They prefer ownership and outcome. Include scale when you can: users, requests, dataset size, deploy frequency, incident reduction, build time, conversion, cost savings.

Weak: “Worked on microservices with Java.” Strong: “Designed and shipped a Java/Spring payments service that processed 120k transactions/month and cut reconciliation errors by 40%.” Same person, different signal.

• Name technologies inside bullets when they add context.
• Show collaboration (product, data, support) for hybrid roles.
• Mention practices: CI/CD, code review, on-call, testing, documentation.
• Avoid company secrets; describe impact without confidential figures.

Projects and GitHub: when they truly help

An empty GitHub—or one full of forks with no README—hurts. Prefer 2–3 repos with a clear description, README, and signs of judgment (tests, structure, deploy). On the CV, one line: project name, problem, stack, outcome or link.

If you work in closed-source code, side projects are not mandatory, but a written case study (architecture, trade-offs) can substitute. For data: clean notebooks or anonymized public dashboards. For product: discovery and outcome case studies.

CV by specialty: quick nuances

• Frontend: accessibility, performance, design systems, UI testing.
• Backend: APIs, data, reliability, observability, cost.
• Data: sources, models, business metrics, data quality.
• DevOps/SRE: uptime, automation, IaC, incident response.
• Product: outcomes, research, prioritization, stakeholders, North Star metrics.

ATS and tech hiring portals

Many tech companies use Greenhouse, Lever, Workday, or similar ATS tools. Selectable text and clear sections still win. Tune summary and skills per ad without lying. If they ask for “3 years of Kubernetes” and you have one, do not invent it—show learning + projects + readiness for a technical assessment.

ClarCV helps from your current PDF/Word: clarify achievements, apply an ATS template, and generate a clean version you can iterate per job. In tech, iterating fast matters as much as the first draft.

Common mistakes on tech CVs

• Trend lists (every buzzword of the year) with no evidence.
• Hiding the stack only inside a visual chart.
• Roles without dates or with vague titles (“Ninja,” “Guru”).
• Endless academic projects with no outcome.
• A 4-page CV with every Jira ticket.

Prioritize. A great tech CV looks simple: few sections, lots of proof. If a bullet does not help you tell an interview story, cut it.

Technical assessments, take-homes, and how to reflect them

If you completed a strong take-home or keep a well-documented kata, one line under projects helps: “ETL pipeline take-home (Python/Airflow): processed 2M rows with tests and README.” You do not need to attach code on the CV; the link or mention prepares the conversation.

Avoid narrating rejections or “I passed company X’s test.” You can describe the kinds of problems you know how to solve. The CV sells capability; you will prove it again in the current process.

Seniority: how not to look inflated or undervalued

Senior is not a longer acronym list—it is ownership, mentoring, design decisions, and problem type. A mid with strong impact beats a “senior” who only listed frameworks. In bullets, show decisions (“chose X over Y for latency”) when true.

If you come from a bootcamp or are switching into tech, do not compete by inventing years. Compete with solid projects, clear contributions, and a summary that states real level (“Junior developer with a background in…”). Honesty speeds matches to the right openings.

Bilingual CVs and international remote roles

For remote-first roles, English is often the CV language even if you live in Spain. Keep a Spanish version for local companies. Ensure stack and achievements match on facts. ClarCV lets you start from the same file and generate clear outputs in the language each job asks for.

Include time zone or city when collaboration depends on it. “Madrid (CET) · remote” prevents misunderstandings. If you have work rights in certain countries, a discreet contact line can unlock mobility filters.

When you tailor the CV to a job ad, do not only reorder skills: move up the experience bullet that best proves the ad’s number-one requirement. ATS counts keywords; hiring managers count evidence. You need both layers on the same page.

Metrics that work (and how to estimate them honestly)

If you lack a perfect dashboard, you can still quantify: number of services, release frequency, size of a migrated monolith, new-hire onboarding time, P1 tickets per month, test coverage, cloud cost before/after. Round honestly and be ready to explain the source in interview.

Avoid empty vanity metrics (“I wrote 50,000 lines of code”). Prefer outcomes: fewer incidents, faster delivery, better DX, savings. If impact was shared, say so: “with 3 engineers” does not reduce credit—it adds credibility.

• Latency, error rate, uptime, throughput.
• Internal adoption of a tool or library.
• Build/CI time and flaky tests removed.
• Migrations completed without downtime.
• Mentoring: people, duration, outcome (promotion, autonomy).

A great tech CV fits in one glance: right stack up top, evidence below. If a staff engineer can imagine working with you after reading it, it is ready. If they only see a logo soup, keep editing. ClarCV helps clean structure; honest metrics are your competitive edge.

Keep a private “brag document” of wins each quarter so the next CV rewrite is fast. Tailoring becomes selection, not archaeology. That habit alone separates candidates who update yearly from those who update when opportunity appears.

What technical hiring managers scan in 60 seconds

Recent trajectory, aligned stack, ownership signals, and clear writing. If those four are present, they go deeper. If the CV looks like a course inventory with no impact, they move on. That is why every section must earn its space: less noise, more proof.

Include links only if they load fast and show current work. A down portfolio or a GitHub with no recent commits hurts more than no link. Keep a README on the main repo and a minimal demo if the role is frontend or full-stack.

Close the loop: tailor, export, apply, note feedback. A tech CV is not a monument; it is a continuous-iteration document. ClarCV shortens the formatting cycle so you can invest time in evidence that actually changes outcomes. After every export, confirm the PDF still has selectable text before you apply.