Software engineer resume examples: entry, mid and senior

Entry-level software engineer resume example

Junior software engineer · 0–2 years

Example bullets:

• Built a Flask endpoint for an internal tool used by 25 support staff, with unit tests covering the main paths.
• Fixed 18 bugs across two sprints of a four-month internship, each with a regression test and a reviewed pull request.
• Cut a nightly data import from 40 minutes to 12 by batching database writes.
• Built a scheduling app with a team of four and kept it running on AWS for 60 student users.
• Added GitHub Actions checks that ran tests and a linter on every pull request.
• Wrote setup docs that cut a new teammate's first-day environment setup from half a day to one hour.

The numbers are examples of the shape a strong line takes, not benchmarks to match.

Mid-level software engineer resume example

Software engineer · 2–5 years

Example bullets:

• Built and owned a payments reconciliation service in Go that processed 200,000 transactions a day with an error rate under 0.1%.
• Reduced p95 response time on a search endpoint from 900 ms to 250 ms with a new index and a short-lived cache.
• Cut deploy time from 35 minutes to 10 by splitting the pipeline and caching build layers.
• Carried the pager one week in six and halved repeat alerts through better thresholds and two permanent fixes.
• Migrated a 12-table schema to a newer PostgreSQL version with a dual-write period and no lost records.
• Reviewed about 15 pull requests a week and wrote a short style guide that a team of six adopted.

Senior software engineer resume example

Senior software engineer · 5+ years

Example bullets:

• Wrote the design for a shared Kafka event pipeline that five teams adopted, replacing four separate polling jobs.
• Led six engineers through a nine-month move from a monolith to services, with no customer-facing downtime.
• Set service-level objectives for 12 services and cut customer-facing incidents from 11 to 4 per quarter.
• Reduced monthly cloud spend by about 20% through right-sizing, storage tiering and retiring idle resources.
• Cut mean time to recovery (MTTR) from 75 minutes to 25 with runbooks, dashboards and one-command rollbacks.
• Mentored four engineers, two of whom were promoted within 18 months.

Skills and keywords software engineer postings commonly list

These are terms commonly listed in software engineer postings. Put one on your resume only when a bullet backs it, and match the exact spelling the posting uses.

• Languages: Python, Java, JavaScript, TypeScript, Go, C#, C++, SQL
• Frameworks: React, Node.js, Spring Boot, Django, .NET
• Data and cloud: PostgreSQL, MySQL, Redis, Kafka, AWS, Azure, Google Cloud, Docker, Kubernetes, Terraform
• Practices: REST APIs, Microservices, CI/CD, Unit testing, Integration testing, Code review, System design, Agile

The title line, contact block and links

Write the title under your name the way a job posting would write it: Senior software engineer, not a nickname or a stack of buzzwords. If the posting says backend engineer and you have spent four years on backend work, your plain title still works, and the first words of your summary can say backend.

The contact block needs an email address, a phone number, a city and two links at most. A city and province or country is enough, because nobody needs your street. Use a professional email address and a LinkedIn address shortened to your name.

Link GitHub only when the profile helps you. A useful profile has two or three maintained repositories with a readable README, a clear commit history and tests. A profile of forty abandoned tutorial forks does the opposite. If your best work lives in a private repository, describe it in a bullet and skip the link. Pin the repositories you want read, and be ready to explain each one: what it does, what you would change and why you chose its design.

A summary that names your lane

Engineering is wide, so the summary's first job is to say which part of it you do. Backend, mobile, data and platform postings ask for different strengths, and a summary that says only "software engineer" leaves the reader to guess.

Use two sentences. The first gives your lane, your main languages and your years. The second names what you care about getting right: latency, reliability, clean APIs, test coverage or developer experience. Daniel's example reads: backend and platform engineer with seven years building Go and Python services on AWS, focused on latency, reliability and cost.

Leave the long tool list for the skills section, and leave out any years you cannot back with dates below. A new graduate can say what they have built instead: "Computer engineering graduate with two internships and a deployed scheduling app" gives the reader something concrete to picture. For more patterns, see these professional summary examples.

Experience bullets: what engineers can honestly measure

Engineering work leaves measurable traces if you know where to look. Choose the measures your team actually watched, because a claim you can back with a dashboard is stronger than a claim you half remember.

• Latency percentiles. p95 or p99 response time, before and after. Averages hide slow requests, so engineers reading your resume trust percentiles more.
• Error rate and availability. Failed requests as a share of all requests, or uptime against a target.
• Incidents and recovery. Incidents per quarter, and mean time to recovery (MTTR), the average time from an alert to a fix.
• Deploy frequency and build time. How often you shipped and how long a pipeline took before and after your change.
• Cloud cost. Monthly spend on a service, and the change you made to it.
• Scale. Requests a day, records processed, users served, services owned.
• Test health. Coverage alone is a weak number. Flaky tests removed, or the time the suite takes to run, says more.

Give each bullet four parts in order: a verb, what you changed, the number and the method. "Cut p95 latency from 420 ms to 140 ms with Redis caching and three rewritten PostgreSQL queries" has all four. Without the method, the number looks borrowed from someone else's work.

Showing scope, and impact when numbers are confidential

Scope tells the reader how big the job was. State what you owned and the team around it: "Owned three Go services and their on-call rotation for a team of eight." Owned means you decided how the service worked and carried the pager when it broke. Contributed to means you wrote part of it. Choose the honest verb, because an interviewer will test it with follow-up questions.

Many employers treat revenue, customer counts and internal traffic as confidential. You can still show impact without them. Three honest ways:

• Relative change. "Halved nightly batch time" or "cut the error rate by two thirds" reveals no absolute figure.
• Scale words. "A service handling millions of requests a day" gives the order of magnitude without the exact count.
• Engineering-side numbers. Build time, the number of services, team size and migration length are usually safe to share, but check with a former manager if you are unsure.

When no number is allowed, describe the change in plain terms: "Replaced four polling jobs with one event pipeline that five teams now use." A reader can picture that without a metric. Do not invent a figure to fill the gap, because an interview question will find it.

Skills grouped the way engineers read them

A flat list of thirty tools is hard to scan and hard to defend. Group your skills the way an engineer reading your resume would think about them:

• Languages: Go, Python, SQL
• Frameworks: Django, FastAPI, React
• Data: PostgreSQL, Redis, Kafka
• Cloud and infrastructure: AWS, Docker, Kubernetes, Terraform
• Practices: CI/CD, code review, system design, on-call

The builder's skills section is a single comma-separated line, so order matters. Put the language you use most first, because a reader will assume the first name is the one you reach for.

Apply one test to every entry: could you answer questions on it in an interview tomorrow? If you used Java once in a university course, leave it off. A list that claims ten languages above a history that shows two raises doubts about the other eight. Each skill should also appear in at least one bullet. Daniel lists Kubernetes because a bullet says he moved services onto it, and that link between skill and evidence makes the list believable. The top tech skills for 2026 are worth reading before you decide what to learn next.

Projects for juniors and career changers

Without a job history, projects are your experience section. Give each one a name, one line on what it does, the stack and one result. Two or three is plenty.

Choose projects that look like work: something deployed, something with users, something with tests. A to-do app from a tutorial shows that you can follow instructions. A scheduling tool that a student club used every week shows that you can ship.

A line that works: "Built a rota-planning app in Python and React for a 40-member volunteer group; deployed on AWS with automated tests and used weekly for six months." It names real users and a duration, and it says what the stack was.

Career changers can use the same format for earlier work. A former teacher who wrote a grading script in Python has a real bullet. A bootcamp capstone belongs on the page with its link, followed by whatever you built after graduating. Open-source contributions count once they are merged. A documentation fix is a fair first step, and a merged bug fix is better. For more on this approach, read about the portfolio resume strategy.

Education and cloud certificates

After a few years in the field, education shrinks to one line: degree, school, year. Daniel's reads BASc Computer Engineering, University of Waterloo, 2018. Add a GPA only if you are a recent graduate and the number is strong, then drop it after your first role.

Cloud certificates, such as an associate-level exam from AWS, Azure or Google Cloud, help most when your shipped work is thin or when you are moving toward infrastructure. They supplement shipped work and do not replace it. Write the full certificate name, the issuer and the year. Check the issuer's site for how long the certificate stays valid, because many need renewing.

The builder has four sections, with no separate one for certificates. Add the certificate as an Education entry, with the certificate name in the degree field and the issuer in the school field, or name it in your skills line. If your own resume tool allows a certifications section, a short one under Education works well. Our post on certifications on a resume covers how to choose which to list.

Mistakes that weaken an engineering resume

Responsibility statements. A line like "Responsible for backend services" describes the seat, not what you did in it.

Tool soup. A bullet that names nine technologies does not say which one mattered. Name the one or two that carried the result.

Team credit with no part of yours. "Our team shipped a new search" leaves the reader asking what you did. Say which piece was yours: the indexing job, the API or the ranking tests.

A catalogue of old work. Fifteen years in the field calls for a page built on the last ten. Cut the first job on a platform that no longer exists.

Two pages for four years. One page is the right length through the middle of a career, and the example above fits on one. Add a second page only when a long senior history has several distinct systems to describe.

Tailoring to backend, front-end, full-stack and platform postings

You do not need four resumes. You need one honest resume with a summary and a skills order you can change in five minutes.

• Backend: move APIs, databases, queues, latency and data modeling to the top, and start the skills line with languages and datastores.
• Front end: lead with the framework, load-time measures, accessibility work and design-system contributions.
• Full stack: show one bullet of each kind per role, and name the layer you know best so the reader does not assume equal depth.
• Platform and infrastructure: lead with cloud, containers, infrastructure as code, deploy pipelines, reliability targets and cost.

Then read the posting for the phrases it uses. If it asks for event-driven design and you built a Kafka pipeline, borrow the posting's wording in that bullet. If it names a tool you have not used, leave it off and describe the closest thing you have actually done. Paste the posting into our ATS checker to compare keywords, and keep only the matches you can back.

Note which version you sent where in the job application tracker, so you can see which one earns replies. If you are heading toward analytics work next, the data analyst resume examples show how the same experience reads for that role, and how to ace the tech interview covers the rounds that follow.

Frequently asked questions

How long should a software engineer resume be?
One page is enough for an engineer with up to around ten years of experience, and a first role or internship fits on one. Use the space for your latest two or three roles, with the strongest bullets first. A second page is reasonable only when a long senior history has several distinct systems worth describing, and the first page should still carry your best material.

Should I put GitHub on my software engineer resume?
Add it when the profile shows maintained work you can explain, such as two or three repositories with a clear README, a readable history and tests. Skip it if the profile is mostly tutorial forks or abandoned experiments. If your best work is private, describe it in a bullet instead and let the numbers speak.

How do I show impact if my company metrics are confidential?
Use relative change, such as halving a batch job or cutting errors by two thirds, or scale words like millions of requests a day. Engineering numbers such as build time, number of services, team size and migration length are usually safe, but check with a former manager if you are unsure. Never invent a figure to fill the gap.

Should I list every programming language I know?
No. List the languages you could answer interview questions on tomorrow, and put the one you use most first. A long list above a work history that shows only two languages raises doubts about the rest. Each language should appear in at least one bullet or project, so the skills line is backed by evidence.