Software Engineer Resume: Samples for New Grads and Seniors

A good software engineer resume does one thing for one posting: it shows, in the posting's own terms, that you have built the kind of software the team builds, at a scale close to theirs, and that you can name the result. Below are three complete samples, a new grad, an engineer three years in and a senior engineer, each printed beside an excerpt of the posting it was written for, with notes on which lines answer which requirement. After them come the bullet formulas behind every line, how to present projects and links, and which skills to list. Every person, company and posting in this post is invented, and the samples are labelled as samples.

What reviewers look for first

The most specific public advice comes from Google's own recruiters. Their resume videos and articles, summarized by Inc. in September 2019, come down to a short list for technical applicants:

• A tailored resume for every position. "You should write a new, tailored resume for every position you apply for."
• A GitHub link, or equivalent, at the top with your contact information.
• Programming languages listed prominently, and named again for each project or job where you used them.
• Accomplishments, not duties, written with the formula Google describes as "Accomplished [X] as measured by [Y], by doing [Z]."
• Education before experience if you are a student or recent graduate, experience first after that.
• One page, with an exception: a technical applicant with many relevant projects can go onto a second.

The Tech Interview Handbook agrees on most of it, and sets the education cut at under three years of experience.

What none of the advice can change is how crowded the pile is. Ashby's 2026 recruiter productivity report puts the share of technical applications that reached an interview at about 3.6% in the first quarter of 2026, against roughly 7 to 8% for all applications in 2021. At 3.6%, that is about one interview for every 28 applications (our arithmetic). A resume that a reader can match to the posting in one pass is the part of that number you control.

The market these resumes are sent into

Two things follow. New grads in computing face a harder start than most majors: in the New York Fed's data, computer science and computer engineering are two of the five majors, out of 74 it tracks, with the highest unemployment for graduates aged 22 to 27, even though the wage for those who land is among the highest. And because software roles are remote or hybrid at more than three times the overall rate, many postings draw applicants from everywhere, which raises the value of matching each one closely.

Sample: new grad

Sample posting (invented): Software Engineer I, New Grad, Quillfield Payments.

• R1: "Build and maintain backend services in Java or Go."
• R2: "Write tests and take part in code review."
• R3: "Experience with SQL databases and REST APIs, through internships or projects."

AVERY OKAFOR
Columbus, OH | (555) 010-2201 | avery.okafor@example.com
linkedin.com/in/example | github.com/example

EDUCATION
BS Computer Science, Buckeye State University | May 2026 | GPA 3.6
Coursework: Distributed Systems, Databases, Operating Systems, Algorithms

EXPERIENCE
Software Engineering Intern, Ridgeline Freight, Columbus, OH | May 2025 to Aug 2025
- Built a REST endpoint in Java (Spring Boot) that serves shipment ETAs to the
  customer app; launched behind a feature flag and rolled out to all users
- Cut the integration test suite from 14 minutes to 6 by giving each test class
  its own PostgreSQL container instead of one shared database
- Opened 22 pull requests, all reviewed and merged; reviewed 15 for teammates

Teaching Assistant, Data Structures, Buckeye State University | Aug 2024 to May 2026
- Wrote Python autograder tests for 6 assignments used by 120 students a term

PROJECTS
Ledgerlite | Go, PostgreSQL, Docker | github.com/example/ledgerlite
- Double-entry bookkeeping API with idempotent transfers; 85% test coverage;
  load-tested at 500 requests per second on a laptop

Course Planner | TypeScript, React, Node.js | github.com/example/planner
- Prerequisite planner used by about 300 students over two semesters

SKILLS
Languages: Java, Go, Python, TypeScript, SQL
Tools: Spring Boot, PostgreSQL, Docker, Git, GitHub Actions, React

Line by line:

• Education first, with the coursework the posting's work touches. This follows both Google's and the Tech Interview Handbook's advice for anyone still in school or just out.
• Internship bullet 1 answers R1 and R3 at once: a backend service, Java, REST. "Rolled out to all users" is scope; a new grad's scope is a feature.
• Internship bullets 2 and 3 answer R2. Test speed is a real result, and pull requests reviewed for others shows code review from both sides.
• Ledgerlite is first among the projects because it is the closest to a payments team's work: transfers, idempotency, a database. Go appears here, so both languages from R1 are backed by something a reviewer can open.

Sample: three years in

Sample posting (invented): Software Engineer II, Northpine Analytics.

• R1: "Own features end to end across our Python (Django) backend and React frontend."
• R2: "Run services on AWS; experience with observability tools such as Datadog."
• R3: "3+ years of professional experience shipping production software."

SAM RIVERA
Denver, CO | (555) 010-3302 | sam.rivera@example.com | github.com/example

EXPERIENCE
Software Engineer II, Copperleaf Reporting, Denver, CO | Jan 2025 to present
Software Engineer I, Copperleaf Reporting | Jul 2023 to Dec 2024
- Owned the billing settings feature end to end, from the Django schema
  migration to the React UI; adopted by 3,000 customer accounts in its first quarter
- Moved report exports off the web servers to Celery workers writing to S3;
  p95 page load on the reports screen fell from 2.4 s to 600 ms
- Added Datadog tracing and alerts to 14 API endpoints; the team's monthly
  on-call pages fell from about 20 to 6
- Wrote the design doc for multi-currency invoices, reviewed by 3 teams; shipped
  in 2 releases without a rollback

Software Engineering Intern, Copperleaf Reporting | Jun 2022 to Aug 2022
- Built a CSV import tool in Django used by the support team for onboarding

EDUCATION
BS Computer Science, Front Range University | 2023

SKILLS
Languages: Python, TypeScript, JavaScript, SQL
Frameworks: Django, Celery, React
Infrastructure: AWS (S3, RDS, ECS), PostgreSQL, Redis, Datadog, Docker, Terraform

Line by line:

• Experience first. After three years the work carries the page, so education drops to one line at the bottom.
• The promotion is shown as two titles under one employer. The bullets sit under both, which avoids repeating the company and makes the step up visible.
• Bullet 1 uses the posting's own phrase, "end to end", and names both halves of the stack from R1. Adoption by 3,000 accounts is the result.
• Bullets 2 and 3 answer R2 with AWS services and Datadog by name, and each has a before and after number.
• Bullet 4 is the one that moves this engineer toward the next level: a design doc read by other teams. Mid-level scope is a feature or a service owned from start to finish.

Sample: senior engineer

Sample posting (invented): Senior Software Engineer, Platform, Brambleway.

• R1: "Lead the design of distributed systems on Kubernetes; Go, Kafka and PostgreSQL."
• R2: "Drive technical decisions across teams and raise the bar on reliability."
• R3: "Mentor engineers and take part in hiring."

JORDAN MBEKI
Remote (Chicago, IL) | (555) 010-4404 | jordan.mbeki@example.com | github.com/example

SUMMARY
Senior software engineer with 9 years building distributed backend systems in Go,
Kafka and PostgreSQL, the last 4 leading platform work across product teams.

EXPERIENCE
Senior Software Engineer, Platform, Saltmarsh Logistics | Mar 2022 to present
- Led the design and rollout of an event bus on Kafka that replaced point-to-point
  calls between 40 services; adopted by 6 product teams over 3 quarters
- Moved 120 Go services from VMs to Kubernetes with a migration playbook other
  teams ran themselves; cut compute spend 28% in the first year
- Set up error budgets and a weekly reliability review across 6 teams; customer-facing
  incidents fell from 11 a quarter to 4
- Wrote or reviewed 30 design docs a year; chaired the platform architecture review
- Mentored 5 engineers, 2 promoted to senior; ran 60+ interviews and trained
  8 new interviewers

Software Engineer, Fernway Commerce | Jun 2017 to Feb 2022
- Built the order pipeline in Go and PostgreSQL, scaling from 5,000 to 80,000
  orders a day without a rewrite
- Led the on-call rotation redesign that cut median time to resolve from
  90 minutes to 35

Software Engineer, Pikeview Media | Jul 2016 to May 2017
- Built internal tools in Python for the ad operations team

EDUCATION
BS Computer Engineering, Lakefront Institute of Technology | 2016

SKILLS
Languages: Go, Python, SQL
Systems: Kafka, PostgreSQL, Kubernetes, Terraform, AWS, gRPC, Prometheus

Line by line:

• A two-line summary earns its place here. With nine years across three employers, the summary does the arithmetic for the reader: years, the posting's three named technologies, and the leadership scope.
• Every bullet in the current role is cross-team. "Adopted by 6 product teams", "a playbook other teams ran", "a weekly review across 6 teams". Senior scope is a system, and a decision that other people followed.
• R3 has its own bullet with numbers: people mentored, promotions, interviews run. Senior candidates often leave this out.
• Length. This fits on one page with tight margins, and running onto a second would be fine. Laszlo Bock's rule of thumb, from when he ran people operations at Google, was "one page of resume for every 10 years of work experience". Our post on the one page resume covers the trade-off.

Bullets that show scope and results

Every bullet above follows the same shape, a variation on Google's X-Y-Z:

[Verb] [what you built or changed] [for whom, or at what scale] [with which tools], [result, with a number and what it was measured against].

The part most engineering resumes skip is scope. Results are easier to find than people think, but scope is what tells a reader which level you work at.

Before and after (samples):

Where to find numbers when you have no dashboard. Pull request counts, test suite runtimes, request volumes and latency from your logs or monitoring, the number of users or teams who used the thing, incident counts before and after, and money where someone told you the figure. If you estimate, write "about" and be ready to explain how you got it. Every number on the page is a likely interview question.

For more verbs sorted by what they prove, see our list of action verbs for a resume.

Projects, open source and links

Projects carry a new grad resume and still help a career changer or anyone whose day job is under a non-disclosure agreement. Make each one checkable.

• Link the code. Google's recruiters want the GitHub link at the top, and the Tech Interview Handbook asks for each project to link to a viewable source.
• Name the stack on the project line, as Google advises, so a reader can match it to the posting without opening the repository.
• Give the project a result, the same as a job bullet: users, requests per second, test coverage, a benchmark.
• Write a README that says what the project does and how to run it.
• For open source, link the merged pull request, not the project's home page. "Merged a fix for connection pool leaks in an open source Go database driver" with a link proves more than a list of repositories you starred.
• Pin the two or three repositories you want seen on your profile.

Two projects that match the posting beat six that do not. If you are still building experience, our guide on how to get an internship covers the step before the first job.

Skills: which to list

Group skills by category, the posting's items first, and list only what you could be interviewed on today. The Tech Interview Handbook suggests grouping by languages, frameworks and databases. Google's recruiters want languages prominent, and named again on each project.

For a sense of what is common, here are the most used languages and databases in Stack Overflow's 2026 Developer Survey, which drew more than 30,000 responses:

Popularity is context, not a shopping list. The posting decides what is relevant. Rules that hold up:

• Use the posting's spelling. "PostgreSQL" if the posting says PostgreSQL. Write out an abbreviation once if it is uncommon, so a search for either form finds it.
• Back the important ones in a bullet. A language on the skills line is a claim. The same language in a bullet with a result is evidence.
• Cut the filler and the skill bars. Microsoft Word adds nothing, and a parser cannot read four stars in Kubernetes.

Our guide to hard skills for a resume covers pulling skills out of any posting and proving each in a single line.

Format, length and LaTeX

• Simple formatting and a PDF. Google's recruiters ask for a PDF and a clean, consistent font; the Tech Interview Handbook adds standard fonts at 10 point or larger and no graphic design tools. A single column with standard section headings keeps the text in reading order. Our post on ATS friendly resume format covers the paste test that checks this.
• One page until the work clearly needs two. The new grad and mid-level samples above fit on one. The senior one could run to two.
• LaTeX is fine if the PDF's text pastes out in the right order, though the Tech Interview Handbook recommends building the resume in Microsoft Word or Google Docs instead. Our LaTeX resume guide goes deeper.

One posting at a time

The three samples share a method more than a layout: start from the posting's main requirements, answer each with a bullet that has scope and a number, and leave out what does not serve that posting. Our guide to tailoring a resume walks through the edit itself.

ApplyEze, the product this blog belongs to, writes a resume for every posting it applies to, and a cover letter when the form asks for one. It brings the posting's named skills and tools onto your skills line, even when your own record does not list them. There is no step to remove one before a live run, so use a dry run to see what it writes, and be ready to discuss anything on the page.