Software Engineer CV Guide: Skills and Projects

Your profile is the first filter. It should give the reader a clear technical position before they reach your skills list.

Avoid opening with soft claims such as “enthusiastic software engineer” or “hard-working developer”. They do not tell the reader what you can build. Start with your engineering scope, your strongest technical environment and the kind of contribution you make.

A good profile usually covers four things in 3-5 lines:

• Your role level or years of relevant experience.
• The products, systems or services you work on.
• Your core stack or technical strengths.
• The practical value you bring, such as improving reliability, shipping features, automating workflows or supporting users.

For example:

Software engineer with four years’ experience building customer-facing SaaS features using TypeScript, React, Node.js and PostgreSQL. Confident working across API design, automated testing and release support, with recent work reducing manual onboarding steps and improving dashboard load performance for account teams.

That profile works because every phrase earns its place. It names the role, stack, product context, engineering activities and outcomes. It also leaves room for the experience section to prove the details.

For a junior software engineer CV, the profile can focus on training, projects and contribution style:

Junior software engineer with a computer science background, commercial placement experience and project work in Python, JavaScript and SQL. Comfortable writing tested features, debugging issues with support from senior engineers and using GitHub workflows to document changes clearly.

For a senior software engineer CV, the profile should show scope and judgement rather than just years:

Senior software engineer experienced in designing backend services, mentoring engineers and improving reliability across cloud-hosted products. Strong Python, AWS, PostgreSQL and CI/CD background, with a track record of simplifying legacy services and turning ambiguous product requirements into maintainable technical plans.

Do not make the profile too broad. If you claim every stack, every domain and every delivery style, the reader has no reason to remember you. If the role advert is for a generalist software engineer, stay balanced. If it leans heavily towards backend, frontend, platform, mobile or data, adjust the first line and highlighted stack to match.

A software engineer skills section should help the reader confirm your fit quickly. It should not become a keyword dump.

Group skills so the page is easy to scan. You might use categories such as languages, frameworks, cloud and DevOps, testing, databases, ways of working and product collaboration. Keep each group selective. A short, relevant list is stronger than a long list that includes tools you would not want to discuss in interview.

A balanced skills section might look like this:

• Languages: TypeScript, JavaScript, Python, SQL
• Frameworks: React, Node.js, Express
• Data and storage: PostgreSQL, Redis, REST APIs
• Cloud and delivery: AWS, Docker, GitHub Actions, CI/CD
• Quality: Jest, Cypress, unit testing, code review, observability basics
• Collaboration: Agile delivery, technical documentation, product discovery support

The best skills are usually echoed in your experience. If you list Docker, show where you used it. If you list accessibility, mention a feature, audit or design-system contribution. If you list AWS, name the service or deployment context where you can do so honestly.

You can include AI coding tools, but handle them carefully. Many engineering teams now expect developers to use AI assistants responsibly, but they still want evidence of review, testing and ownership. If you mention AI-assisted development, frame it around safe workflow habits: generating test ideas, speeding up documentation, exploring unfamiliar APIs or reviewing repetitive code with human oversight. Do not make it sound like the tool did the engineering for you.

For early-career candidates, include fundamentals as well as tools. Data structures, debugging, version control, testing and web basics can be more useful than a crowded framework list. For senior candidates, include architecture, observability, security, performance, mentoring and technical planning where those are part of your real work.

Your work experience section should not read like a job description. Software engineer employers already know you wrote code, attended stand-ups and fixed bugs. They want to know what you built, how you contributed and why it mattered.

A useful bullet usually combines four ingredients:

1. The problem or delivery context.
2. The technical action you took.
3. The tools, system or practice involved.
4. The outcome or evidence of quality.

Weak bullet:

• Worked on backend APIs using Node.js and PostgreSQL.

Better bullet:

• Built and documented Node.js API endpoints for a customer onboarding workflow, reducing manual account setup steps and giving support teams clearer error states in the admin dashboard.

Weak bullet:

• Fixed bugs and improved performance.

Better bullet:

• Investigated slow dashboard queries, added database indexes and refactored repeated API calls, cutting key report load times from 9 seconds to under 3 seconds during peak usage.

Weak bullet:

• Participated in Agile development.

Better bullet:

• Worked with product and QA to split a complex billing feature into releasable increments, reducing release risk and allowing customer feedback before the final integration phase.

You do not need a number in every bullet. Numbers help when they are credible, but forced metrics can sound invented. Strong non-numeric evidence includes scope, technical constraints, release frequency, user group, team size, service criticality, security requirements, migration complexity or production support responsibility.

For each recent role, aim for 4-6 bullets. Put the most relevant engineering evidence first. If the job advert asks for API design, cloud services and automated testing, do not bury those points below generic collaboration bullets. If the advert is for a product-led team, give more space to user-facing features, product trade-offs and cross-functional work.

Older roles can be shorter. If you were a helpdesk analyst before becoming a software engineer, keep the parts that support your story: troubleshooting, scripting, user empathy, technical support or stakeholder communication. Remove duties that distract from the software engineering target.

Projects are valuable on a Software Engineer CV, especially when your commercial experience is thin, your strongest work is outside your job title, or you are moving into a different stack. The mistake is listing projects as if the reader will click every GitHub link and work out the value for themselves.

Treat each project like a small case study. Explain the problem, the stack, your contribution and what the project proves.

A useful project entry might include:

• Project name and short context.
• Stack used.
• Two or three bullet points about technical choices, testing, deployment, usability or learning outcome.
• A GitHub, portfolio or live link if it is safe, maintained and relevant.

For example:

Shift Planner API Personal project using Python, FastAPI, PostgreSQL and Docker to model staff availability and rota constraints.

• Designed REST endpoints for employees, shifts and availability rules, with validation for overlapping bookings.
• Added pytest coverage for core scheduling logic and documented local setup in the README.
• Deployed a small demo environment to show API behaviour and error handling.

That is stronger than “Built rota app in Python” because it gives the interviewer something specific to ask about. It also proves skills beyond writing code: data modelling, testing, documentation and deployment.

For commercial projects, avoid exposing confidential details. You can describe the type of system and the impact without naming clients, revenue or internal architecture. Write “customer onboarding service for a B2B SaaS platform” rather than revealing sensitive information.

For senior engineers, projects can include migrations, design-system work, service extraction, observability improvements, security remediation or technical debt reduction. These are not always glamorous, but they often show the judgement that senior roles require.

The title “software engineer” can mean different things depending on the company. A start-up may expect you to move across product features, infrastructure and support. A larger company may use the same title for a narrower backend, frontend, mobile or platform role. Your CV should flex without losing its core story.

For a frontend-leaning role, bring interface evidence forward. Mention React, TypeScript, accessibility, component libraries, state management, testing and collaboration with design. Show user-facing outcomes such as clearer journeys, faster page loads, improved conversion, better accessibility compliance or reduced support questions. Link to the Frontend Developer CV Guide and the Frontend Developer CV example if the page needs a more specialist version.

For a backend-leaning role, highlight APIs, services, databases, messaging, reliability, monitoring and secure design. Explain the scale or criticality of the systems you touched. Mention database design, performance work, integration patterns, cloud services and incident learning where appropriate. Use the Backend Developer CV Guide and Backend Developer CV example when the job clearly wants backend depth.

For a full-stack software engineer role, prove that you can move across layers without being shallow. Show at least one example where you understood the user-facing need and the underlying service, data or integration work. The Full Stack Developer CV example can help you compare how much space to give each layer.

For DevOps-heavy or platform roles, be careful with the title. If the advert is really asking for deployment pipelines, infrastructure-as-code, observability and incident response, you may need to adapt towards the DevOps Engineer CV example. A software engineer CV can include cloud and CI/CD evidence, but it should not pretend to be a platform engineering CV unless your experience supports it.

Seniority changes what the CV needs to prove.

A junior software engineer CV should show learning speed, fundamentals and reliable contribution. Employers know you may not own architecture decisions yet. They are looking for evidence that you can write readable code, accept feedback, test your work, debug problems and communicate clearly. Include internships, apprenticeships, bootcamp projects, university projects, open-source contributions or internal tools if they show relevant practice.

Good junior bullets include:

• Built a React and Node.js project as part of a team of four, using Git branches, pull requests and peer review to manage changes.
• Wrote unit tests for form validation logic and documented setup steps so other students could run the project locally.
• Fixed support tickets during a placement by reproducing bugs, tracing logs and escalating unclear root causes with concise notes.

A mid-level software engineer CV should show independence. You should prove that you can take a feature from requirement to release, make sensible trade-offs, review code, estimate work and collaborate beyond your immediate task. Show examples of reducing defects, improving performance, supporting releases, mentoring juniors informally or spotting risks before they become production problems.

A senior software engineer CV should show technical ownership. That does not mean filling the page with architecture jargon. It means showing how you influence the shape, quality and maintainability of software. Include design decisions, cross-team collaboration, mentoring, incident prevention, migration strategy, security thinking and stakeholder translation. Your bullets should make clear where you led, advised or raised the engineering standard.

Good senior bullets include:

• Led the technical plan for splitting a legacy monolith workflow into service-owned components, agreeing migration stages with product, support and platform teams.
• Introduced review guidelines and test coverage expectations for a payments squad, reducing repeated regression issues during release cycles.
• Mentored two junior engineers through pairing, code review and design discussions, helping them take ownership of their first production features.

Do not overclaim seniority. If you have not led architecture, do not write as if you have. It is better to show credible mid-level independence than inflated leadership language that collapses in interview.

Software engineer education can come from degrees, apprenticeships, bootcamps, self-directed study, vendor training or commercial experience. The CV should make the route clear without letting education dominate the page once you have strong work evidence.

For graduates and juniors, include modules, projects or dissertations that support the target role. Data structures, software engineering methods, web development, databases, distributed systems, machine learning, cybersecurity and human-computer interaction can all be relevant if the job asks for them. Keep the detail practical.

For example:

BSc Computer Science, University of Leeds Relevant modules: software engineering, databases, algorithms, cloud computing Final-year project: built a booking application using React, Node.js and PostgreSQL, with automated tests for core booking rules.

For apprentices, name the apprenticeship level and the workplace evidence you built. UK employers understand routes such as Level 3, Level 4 and degree apprenticeships, but they still need to see what you can do.

For experienced engineers, keep education short unless it is unusually relevant. Certifications can help when they support the job target, especially cloud, security or Agile delivery. AWS, Azure, GCP, Kubernetes, security or testing certifications can be useful, but they should not replace evidence of applying the knowledge.

Short courses belong if they are recent and relevant. Remove old online certificates that make the CV look like a learning log rather than a hiring document.

A technical CV still has to pass a fast scan. Fancy formatting can work against you if it hides the stack, splits bullets awkwardly or makes the CV difficult to parse.

Use a clean structure:

1. Name and contact details.
2. Profile.
3. Key technical skills.
4. Work experience.
5. Projects, if useful.
6. Education and certifications.
7. Optional links, publications or open-source work.

Keep the layout simple. Use clear headings, consistent dates, normal bullet points and enough spacing. Avoid skill bars, icons, unusual columns and graphics that make the content harder to read. If your CV is two pages, make the first page carry the strongest evidence. If you are early-career and one page is enough, do not stretch it.

Use role-specific keywords from the advert, but only where they are true. Applicant tracking systems may help filter applications, but a keyword-stuffed CV still has to satisfy a human reader. For broader formatting guidance, use the CV structure guide, skills on CV guide and ATS-friendly CV guide.

Links can help if they are tidy. Include GitHub, GitLab, a portfolio, a deployed project or a LinkedIn profile when it strengthens the application. Check permissions, remove broken projects, update README files and avoid linking to code you would not want an interviewer to inspect.

The first common mistake is listing technologies with no proof. A stack list tells the reader what you have touched; experience bullets tell them what you can do. Make sure your most important tools appear in context.

The second mistake is writing bullets that sound like ticket labels. “Implemented feature X” is not enough. Explain why the feature mattered, what technical constraint you handled or what improved after the work shipped.

The third mistake is ignoring quality. Testing, code review, security, accessibility, observability and documentation may not feel as exciting as new features, but they show the habits that make engineers safe to hire.

The fourth mistake is using the same CV for every engineering vacancy. A general baseline is useful, but the top third should change. Move the most relevant stack, project and impact evidence closer to the top for each role.

The fifth mistake is overloading the page with old or low-value tools. If you used jQuery once in 2018 and never want to use it again, it probably does not belong near the top of a 2026 software engineer CV.

The sixth mistake is making senior claims without senior evidence. Phrases such as “architected solutions” or “led technical strategy” need proof. If your actual contribution was proposing a design option, reviewing implementation risks or leading a feature area, say that clearly.

The seventh mistake is hiding business or user impact. Engineering managers care about maintainable code, but they also care whether the work solved a real problem. Add enough context for the reader to understand why the change mattered.

Use examples to test whether your own bullets are specific enough.

Profile example for a mid-level software engineer:

Software engineer with five years’ experience building SaaS products across TypeScript, React, Node.js and PostgreSQL. Comfortable working from product discovery through release support, with recent evidence in API design, automated testing and dashboard performance improvements.

Experience bullet examples:

• Delivered a self-service account management feature using React, Node.js and PostgreSQL, reducing support requests linked to plan changes during the first release month.
• Refactored repeated data-fetching logic into shared service utilities, improving maintainability and reducing duplicated code across three dashboard areas.
• Added automated regression tests for billing edge cases, helping the squad release pricing changes with fewer manual QA checks.
• Worked with design and product to improve form validation, error messaging and accessibility across a high-traffic onboarding flow.
• Supported a legacy PHP-to-Node migration by documenting endpoint behaviour, writing integration tests and flagging compatibility risks before release.
• Investigated production incidents through logs and monitoring dashboards, then documented root causes and follow-up actions for the squad.

Project bullet examples:

• Built a portfolio task-tracking app with TypeScript, React, Express and PostgreSQL, including authentication, REST endpoints and deployment notes.
• Added Cypress tests for the main user journey and documented known limitations in the README.
• Used GitHub Actions to run linting and tests on pull requests, showing basic CI/CD understanding.

These examples are not scripts to copy word for word. Use their structure: action, technology, context and outcome. Replace the details with evidence you can defend in an interview.