How to Write a CV for a Tech Job (Software Engineers, Developers, Data)

The tech CV is read differently — what changes

Before the tactics, the structural difference. Tech CVs are evaluated through a different lens than corporate CVs, and the difference shapes every section:

• The engineering hiring manager reads the CV alongside (or after) a quick scan of your GitHub, your personal site if you have one, and your LinkedIn. The CV is not the only signal; it is one signal in a multi-source evaluation
• The technical skills section is read first by both recruiters and engineers, but they are looking for different things. Recruiters scan for keyword matches against the JD; engineers scan for whether the depth and breadth match the role's seniority
• Projects often matter more than job history at the junior and mid levels. A self-driven project that shipped something real signals initiative and execution in a way that an internship or first job cannot
• Work history is read for scope, impact and seniority of context — not just for company names. Working on the auth team at a 50-person startup is different from working on the auth team at a 50,000-person enterprise; the CV should make the scope readable
• GitHub presence is checked. A candidate with an active GitHub profile (real commits, multiple repositories, contribution graph showing recent activity) is treated as a more credible engineer than one without — even if the underlying skill is identical
• The CV is one page until it cannot be. Two pages are acceptable for engineers with 8+ years of experience, but the second page should contain real substance, not padding
• Education matters at the junior level (especially for new graduates), becomes less important at the mid level and becomes near-irrelevant at the senior+ level. Adjust prominence accordingly
• Certifications matter for specific cloud roles (AWS, GCP, Azure) and specific specialties (security, networking) but are largely irrelevant for general software engineering roles

The rest of this guide is built around these structural facts. Each section addresses what to write, how to organize it, what to emphasize and what to cut — calibrated specifically for engineering roles rather than generic corporate roles.

The technical skills section — how to organize it

The technical skills section is the most-scanned section on a tech CV. Both recruiters and engineers look at it first. How it is organized determines whether it transmits competence or noise:

• Organize by category, not as a single flat list. Languages, frameworks, databases, infrastructure/cloud, tools, methodologies — each as its own group. A wall of 40 comma-separated technologies reads as a buzzword dump; the same 40 organized by category reads as a structured competency map
• List technologies you can confidently discuss in a technical interview. The interviewer will pick from this section to design technical questions; if you list Rust because you used it for a tutorial three years ago, you will fail the interview
• Order each category by genuine proficiency, not by what you wish was true. If you are strongest in Python and weakest in Go, put Python first — the order is read as a confidence signal
• Avoid skill-level labels (Beginner / Intermediate / Expert / 8 out of 10). They are subjective, often inaccurate and create awkward questions in interviews. Either list a technology because you can discuss it confidently, or leave it off
• Match the technical vocabulary in the job description. If the JD says 'React, Node.js, PostgreSQL, AWS', use those exact terms — not 'JavaScript frameworks, web servers, relational databases, cloud platforms'. The ATS keyword matching is literal
• List versions or specific dialects when relevant: 'Python 3.x', 'PostgreSQL 14+', 'React 18 with hooks'. Specificity signals depth
• Skip the basics that everyone is assumed to have. Listing 'HTML, CSS, Git, command line' on a senior engineer CV is filler that crowds out real signal
• If you have specialized expertise (compilers, distributed systems, ML infrastructure, real-time systems), create a separate 'specialties' or 'domains' line that surfaces it. Specialization is more valuable than breadth at the senior level

The test for the technical skills section: an engineer reading it should be able to predict what your day-to-day work has actually looked like. If the section is a generic word cloud that could match any candidate, it is failing. If it is organized, calibrated and honest, it does most of the work of the technical screen before the technical screen even happens.

Showing projects — when projects matter more than jobs

Tech CVs often include a Projects section in addition to Work Experience. For some candidates the Projects section is the strongest part of the CV. When to include one and how to use it:

• Junior engineers and new graduates: Projects section is essential. With limited work history, projects are the primary evidence that you can ship code. Place this section above or right after Education
• Career changers entering engineering: Projects section is essential. It is the bridge between your prior experience and your engineering capability — and the only proof that you have actually built something
• Mid-level engineers with strong work history: Projects section is optional. Include it if you have side projects that demonstrate skills your work history does not (open source, ML side-experiments, a published library, a popular Chrome extension)
• Senior engineers and above: Projects section is usually unnecessary. Work history at this level should carry the weight. Exception: notable open source maintainership, well-known published work or significant community contributions
• Each project entry should have: project name (with link to repo or live URL), one-line description of what it does, the tech stack used, and 1-2 bullet points on what was non-trivial about building it
• Prefer 2-4 strong projects over 8 weak ones. A tutorial-following todo app does not help; a project that solved a real problem and that you can discuss in depth does
• If the project is a clone or follow-along of a tutorial, do not list it as a project. List it as 'learning exercise' if at all, or omit
• Live links matter more than repo links for user-facing projects. A deployed site that the hiring manager can click through to is dramatically more compelling than a repo they have to clone
• If the project had collaborators, name them and your specific role. 'Built backend API and database layer for 4-person team project' is honest and specific; claiming sole authorship of a team project is the kind of thing that gets caught in the interview

The strongest tech CV at the junior/mid level often has 2-3 substantial projects that the candidate can speak to in depth, with live demos. This often outweighs a longer but less differentiated work history. Build the projects deliberately to be your CV's strongest evidence.

GitHub, portfolio, and demonstrable work

The links you include on your tech CV are read as evidence that you are a working engineer rather than a credential-holder. Which links to include and how to present them:

• GitHub: include for almost all engineering roles. Make sure the profile you link to is real (recent commits, multiple repos, populated profile readme). An empty or stale GitHub linked on your CV is worse than no link
• Personal site: include if you have one and it is current. The site does not need to be fancy; a simple portfolio with links to projects, a short bio and contact information is enough. A broken or 2019-era site is worse than no site
• LinkedIn: include. Even if you think LinkedIn is mostly noise, recruiters check it and an empty profile signals lack of professionalism
• Stack Overflow profile: include only if you have meaningful reputation and high-quality answers. A 50-reputation profile signals nothing; a 50,000-reputation profile signals real expertise
• Personal blog or technical writing: include if you write technical content regularly. Engineering blog posts demonstrate communication ability, technical depth and a habit of reflection — all signals hiring managers value
• Conference talks, podcasts, video appearances: include if you have any. They function as third-party validation that you can communicate technical ideas
• Make all links clickable in the PDF (Word and Google Docs both support this when you 'Insert hyperlink'). Recruiters will click; broken or unclickable links cost you the click-through
• Curate before linking. Before adding your GitHub link, look at your profile from a fresh eyes perspective. Pin your best 4-6 repos to the profile. Make sure repo READMEs are written. Delete or archive repositories that exist only as half-finished tutorials. The hiring manager will form an impression in 30 seconds of looking at your profile — make sure it is the impression you want

Each link on your tech CV is a promise — clicking it will reveal more evidence of your engineering capability. If clicking reveals less than the CV suggested, the candidacy weakens. The links are net-positive only if the underlying material lives up to what the CV implies.

ATS for tech roles — the keyword matching that matters

Most large-company tech hiring still funnels through ATS systems that filter on keywords. The dynamics of ATS matching for engineering roles:

• ATS for tech roles often runs literal keyword matching against the JD. If the JD says 'React' and your CV says 'React.js', some systems will not match. Use the exact spelling from the JD where possible
• List technologies in multiple sections, not just the Skills section. A senior engineer who used Kubernetes in production at three different companies should have 'Kubernetes' appear in those three job descriptions plus the Skills section — the matching algorithm weights occurrences
• Specific frameworks and tools matter more than general categories. 'React, Vue, Angular' is better than 'JavaScript frameworks'. 'PostgreSQL, MongoDB, Redis' is better than 'databases'
• Acronyms and full forms: include both. 'Machine Learning (ML)' covers both 'ML' and 'machine learning' search queries. 'Continuous Integration (CI/CD)' does the same
• Common variations: 'Node.js' and 'Nodejs' and 'Node' are all the same technology but ATS systems may not know that. If the JD says 'Node.js', match that exact form
• Industry-specific certifications and frameworks: include if relevant. 'PCI DSS', 'HIPAA', 'SOC 2', 'GDPR' if you have worked with them. 'Agile', 'Scrum', 'Kanban' if you have run these processes
• Avoid keyword-stuffing that breaks readability. The CV is read by humans after passing ATS; if the human reader sees a wall of technology names without context, the candidacy fails at the human screen even if it passed the ATS screen
• Tailor per application. The keyword list that gets a CV through Google's ATS is different from the keyword list that gets it through a startup's Greenhouse. Match the specific JD

ATS matching is a necessary first hurdle for tech roles at most large companies. Treat it as a literal matching exercise: match the JD's vocabulary, list technologies in context (in job descriptions, not just the Skills list), and assume the matching is dumb. Once past ATS, the human reader takes over and content matters more than keyword density.

Quantifying engineering impact

Tech CVs often suffer from the same generic-claims problem as corporate CVs: 'developed features', 'improved performance', 'worked on the platform'. Specific quantified impact is what separates a strong tech CV from a generic one:

• Performance: 'reduced API p99 latency from 850ms to 120ms' beats 'improved API performance'. Specific numbers are credible; vague claims are not
• Scale: 'handled 50K req/sec at peak' or 'processed 2B events/day' grounds the work in real scale. Without numbers, the reader has to imagine; with numbers, they understand
• Cost: 'reduced AWS infrastructure cost by $180K/year through database optimization and tier-rightsizing' is the language that lands with engineering leadership. Cost reduction is often the highest-leverage engineering metric
• Reliability: 'reduced production incident rate from 8/month to 1/month' or 'improved service SLO from 99.5 % to 99.95 %' are concrete reliability metrics
• Team and scope: 'tech lead for 6-engineer team' or 'owned end-to-end design and implementation of payments service' tells the reader your scope of responsibility. Without this, the work could be anything from 'wrote one feature' to 'designed the entire system'
• Delivery: 'shipped 12 production releases in 18 months with zero major incidents' or 'delivered project 3 weeks ahead of schedule by parallelizing infrastructure and feature work' tells a delivery story
• Adoption: 'internal library used by 15+ teams' or 'open source project with 8K GitHub stars' quantifies the impact of work that does not have customer-facing metrics
• When you do not have specific numbers, give specific descriptions. 'Migrated the payment service from monolith to event-driven architecture, with zero downtime during the cutover' is concrete even without a number

The pattern: every bullet should answer 'so what?' If a bullet says 'developed features', the so-what is invisible. If it says 'developed checkout flow that drove the conversion lift from 2.1 % to 3.2 % over the 6-week experiment', the so-what is right there. Rewrite generic bullets until they have either a number or a concrete specific outcome.

Open source, side projects, hackathons

Engineering hiring values contributions outside paid work as evidence of genuine engagement with the craft. How to handle these in the CV:

• Open source contributions: include if substantive. 'Maintainer of X (project description, 8K stars)' is high signal. 'Contributed bug fix to popular library Y' is medium signal. 'Submitted PR to project Z' is low signal unless the PR was substantial
• List the nature of the contribution: maintainer, regular contributor, occasional contributor, one-time contributor. The distinction matters and the honest framing builds credibility
• If you have created a popular open source library or tool, lead with it on the CV. A widely-used open source project is one of the strongest possible signals of engineering capability
• Side projects: include 2-3 of the strongest in a Projects section. Skip side projects that are tutorial follow-alongs, half-finished or only exist as private repos
• Hackathons: include only if you won or placed at a notable one. A 2nd place at a major university or industry hackathon is worth listing; participation in a college hackathon is not unless you are very junior
• Internal company projects: usually do not count as 'open source' even if discussed publicly. Include them under work experience instead
• Community involvement: meetup organizer, conference speaker, podcast guest, technical writer — include these if substantive. They signal an engineer who engages with the broader community rather than just doing their job
• Be honest about scope. 'Contributed to React' could mean 'opened one issue that was closed without a PR' or 'wrote 30 PRs that shipped'. The CV claim and the GitHub evidence have to match

The role of open source and side projects shifts with seniority. At the junior level, they are essential evidence of being a working engineer. At the mid level, they differentiate. At the senior level, they signal continued engagement with the craft beyond the day job. Calibrate prominence to your career stage.

Education and certifications — what matters

Tech roles weight education and certifications very differently from other industries. The current landscape:

• Junior engineers (0-2 years): education matters. Computer Science or related degree from a known institution carries weight. List education prominently, near the top of the CV
• Mid-level engineers (3-7 years): education matters less. Work history is the primary signal. Move education to the bottom of the CV unless you have a particularly notable degree (top-tier school, advanced degree in relevant field)
• Senior engineers (8+ years): education is near-irrelevant for most roles. A one-line entry at the bottom is sufficient. The exception is roles that explicitly value academic credentials (research engineering, certain ML/AI roles)
• Bootcamp graduates: list the bootcamp. The hiring market for bootcamp grads has matured; reputable bootcamps (Hack Reactor, App Academy, Lambda School historically) are recognized. Pair with strong projects to compensate for shorter learning time
• Self-taught engineers without formal CS education: lead with projects and work history. List self-directed learning ('self-taught, focusing on full-stack web development since 2019') honestly. Do not invent credentials, but do not feel obligated to list any if you do not have them
• AWS / GCP / Azure certifications: matter for cloud-focused roles (DevOps, SRE, cloud architect, infrastructure engineering). List the specific certification level (Associate, Professional, etc.)
• Security certifications (CISSP, OSCP, CEH): matter for security roles. List with date earned
• General software certifications (Oracle Java, Microsoft .NET): largely ignored. Listing them on a senior engineer CV is filler
• Online course completions (Coursera, Udemy, edX): generally do not list. They signal that you can complete a course, not that you can do the work. Exception: completing a specialized program (Stanford ML, Andrew Ng's deep learning specialization) might warrant a single-line mention
• PhD: list at the top if recent and relevant; move down with seniority. PhD is a strong signal for research-oriented roles and a neutral signal (sometimes mildly negative for 'too academic' perception) for product engineering roles

The pattern: education is a junior-engineer signal that fades over time. Certifications are specialized-role signals that matter when they are relevant and are filler when they are not. Calibrate the prominence of these sections to where you are in your career.

Remote-friendly tech CV — the new norm

A significant share of engineering roles in 2026 are remote or hybrid. The CV should signal remote-readiness, which is now a hiring consideration in itself:

• If you have remote work experience, mark it: 'Senior Engineer (remote), Acme Corp, 2022-2025'. Recruiters scan for this; remote experience is a positive signal for remote roles
• Location: include current city and country, but signal flexibility if relevant. 'Berlin, Germany (open to remote, EU time zones)' or 'San Francisco, CA (open to remote within US)'. Vague 'open to relocation' is weaker than specific availability
• Time zone: list it if applying for remote roles in a different geography. 'Time zone: CET (UTC+1)' makes scheduling clearer
• Communication tools experience: in a remote-relevant context, mentioning experience with Slack, Notion, Linear, Figma, video-based pair programming and async-first workflows signals fit for remote engineering culture
• Self-direction language: 'led the project end-to-end from spec through deployment' signals the autonomy that remote work requires. 'Worked with the team to deliver X' is neutral; 'drove X from concept to launch independently' is stronger for remote
• Documentation and writing: highlight any technical writing, design doc authoring or RFC contributions. Remote teams over-rely on written communication; engineers who write well are easier to hire remotely
• Time zone overlap signals: if you have explicitly worked across time zones (a US engineer working with a Berlin team, or vice versa), mention it. The skill of asynchronous collaboration is non-trivial
• Avoid signaling remote-only inflexibility if you are open to onsite. The bias still exists at some companies; if you are flexible, signal flexibility

Remote-friendliness has shifted from being a candidate preference to being a hiring criterion. Showing on the CV that you have worked remotely, communicated asynchronously, and operated with self-direction is now part of the CV's job — not just for fully-remote roles but for hybrid and even some onsite roles where remote-readiness is treated as a quality signal.

CVs for junior vs mid vs senior vs staff/principal

Engineering CV emphasis shifts dramatically across career stages. What works for a junior CV will sink a staff CV, and vice versa:

The summary statement for technical roles

The summary statement at the top of a tech CV is optional for junior roles and increasingly important from mid-level upward. How to write one that does work:

• Length: 3-5 lines. Long enough to frame your specialty, short enough that the reader actually reads it
• Lead with years of experience and primary specialty: 'Backend engineer with 7 years of experience designing high-scale distributed systems, primarily in Go and Python.' This is the first thing the reader sees and it should anchor the whole CV
• Follow with a sentence on the type of work you do well: 'I focus on the boundary between API design and infrastructure, with deep experience in event-driven architectures and database internals.'
• End with what you are looking for: 'Looking for senior+ roles where I can lead the design of a critical backend system and grow into staff-level scope over the next 2 years.'
• Avoid generic descriptors: 'passionate', 'results-driven', 'detail-oriented'. These are zero-signal and read as filler
• Avoid summarizing the rest of the CV. The summary should add information the reader cannot get from scanning the rest — specifically your specialty area, your career direction and what makes you a coherent candidate
• Tailor per application. The summary is the easiest place to signal that the CV is targeted at this specific role. A summary written for a backend infrastructure role at a database company should read differently from the same person's summary written for a backend product role at a SaaS company
• Skip the summary entirely if you are a junior engineer. At that career stage, the summary risks padding without adding signal; let your work speak for itself

The summary statement is high-leverage real estate at the top of the CV. Used well, it tells the reader who you are as an engineer in 3-5 lines and frames everything that follows. Used badly (generic adjectives, vague aspirations), it is filler that crowds out real signal.

Tech CV format choices — one page vs two pages

The one-page vs two-page question is more nuanced for tech CVs than for other industries. The framework:

• One page: junior engineers (0-3 years), most mid-level engineers (3-7 years) and engineers in markets where one-page is the cultural norm (most of the US tech industry)
• Two pages: senior engineers with substantial experience (8+ years), staff/principal engineers with significant scope to communicate, engineers in markets where two pages is normal (most of Europe, especially Germany, France, UK)
• Never three pages. If you cannot fit your CV in two pages, the issue is editing, not space. Cut older roles to one-line summaries, cut detail from earlier-career roles, trim less-relevant projects
• If you have a longer CV-style document (academic style, with publications, talks, patents), keep that separate. The CV is the recruiter-facing summary; the longer document is for follow-up requests
• Format: single column or two column? Single column is safer for ATS. If you use two columns (sidebar for skills/contact, main column for experience), test the parsing by running the PDF through an online resume parser before submitting
• Font: stick to standard fonts (Calibri, Helvetica, Arial, Source Sans, Inter). Designer-y fonts can break ATS parsing. 10-11pt body text, 12-14pt headings
• Color: minimal. One accent color for section headings is fine; full-color design is unnecessary and can break ATS. The content is the signal, not the design
• Photo: not in US tech CVs. In European countries where photos are normal (Germany, France), include a professional headshot
• File format: PDF. Always PDF. Word documents reflow on different machines and look broken; PDFs render consistently. Name the file consistently: 'FirstName-LastName-CV.pdf' or 'FirstName-LastName-SeniorEngineer-CV.pdf'

Format decisions should serve the content, not distract from it. A tech CV that uses standard fonts, simple structure and modest color is more readable than one that tries to look like a design portfolio. The exception is design engineering or front-end roles where some visual sophistication on the CV itself is a relevant signal — but even there, restraint reads as confidence.

Coordinating CV, LinkedIn, GitHub and personal site

The tech CV is one document in a coordinated online presence. Engineering hiring managers will look at multiple surfaces, and inconsistency between them is a negative signal. The coordination playbook:

• LinkedIn: should tell the same story as the CV in terms of roles, dates and scope. The headline can be more aspirational ('Senior Backend Engineer interested in distributed systems and developer tooling'), but the substance should match. A LinkedIn that contradicts the CV (different dates, different titles, different scope) destroys trust
• GitHub: should be alive. Recent commits, populated profile readme, 4-6 pinned repositories that represent your best work, clean repo READMEs. An empty GitHub linked from the CV is worse than no link. If GitHub is sparse, invest a weekend in cleaning it up before sending the CV
• Personal site: optional but powerful when done well. A simple page with a one-paragraph bio, project highlights, a CV download link and contact info is enough. Avoid Flash, broken contact forms, dead links, last-updated dates from 2020
• Consistency of name and identity: use the same name and headshot across CV, LinkedIn, GitHub, personal site. Recruiters cross-reference; a 'James Smith' on the CV who is 'Jim Smith' on LinkedIn creates friction
• Email address: consistent across all surfaces. Use a professional email (yourname@yourdomain.com or firstname.lastname@gmail.com), not a college email or a username from 2005
• Phone number, location and time zone: consistent across surfaces. Conflicting location signals look like inattention
• If you have a portfolio of published work (technical blog posts, talks, papers), link from the CV to the canonical source — your personal site or a centralized profile, rather than 10 separate links
• Audit before applying. Before sending the CV out, click every link on it as if you were a recruiter. Look at the LinkedIn profile fresh-eyes. Browse the GitHub. If you find anything that contradicts or undermines the CV, fix it before applying

The hiring manager builds a single impression of you from the coordinated surfaces, not separate impressions from each. The CV that points at a coherent online presence reads as more credible than one with a strong CV and a weak or contradictory LinkedIn/GitHub. The thirty minutes of cleanup across surfaces is one of the highest-leverage uses of time in a tech job search.