Resume sample Software Engineer

A software engineer resume differs from most others in one fundamental way: its first reader is usually not a person. It passes through an applicant tracking system, then takes thirty seconds of a non-technical recruiter’s attention, and only on the third pass reaches someone who can read your code. That means one document has to work for three very different audiences at once. This page sets out what an engineer’s resume has to prove, which keywords genuinely matter, how experience statements should be written, and which common mistakes keep resumes with real skill behind them from ever being seen.

What this resume has to prove

  • That your code reached actual users

    The gap between knowing a language and having shipped something with it is the single most important thing a technical resume conveys. Instead of listing tools, write what you built, how many people used it, and what changed as a result.

  • Depth in one area, not a surface across ten

    A resume listing fifteen languages and twenty frameworks in one row tells the reader you took none of them seriously. Pick the one or two areas where you genuinely have depth, and move the rest to a separate line labelled as familiarity.

  • That you have worked alongside other people’s code

    Code review, documentation, working with version control in a multi-person team, and shipping on a regular cadence are things hiring managers care about and resumes routinely omit. Their absence reads as having only ever worked alone.

  • The effect of your work on something the business cares about

    Load time, error rate, server cost, the duration of a manual process you automated. One number showing your work moved any of these is stronger than any qualitative description.

  • A link that actually opens

    An active repository, a visible project, or a live portfolio is worth more than any claim in the body text. If you include a link, make sure it resolves and that what sits behind it is tidy.

Keywords the ATS scans for

Use these only where they are genuinely true of you. A keyword you cannot back up surfaces in the interview.

  • JavaScript
  • TypeScript
  • Python
  • React
  • Node.js
  • REST API
  • Git
  • SQL
  • Docker
  • CI/CD
  • unit testing
  • code review
  • Agile
  • microservices
  • version control

Experience statement examples

Each line says what was done and what changed as a result — a pattern you can rewrite for your own work.

  • Cut home page load time from 4.2s to 1.1s by rewriting the data layer and adding server-side caching.
  • Extracted the payment service from the monolith into a standalone microservice, taking payment-related deploys from weekly to twice daily.
  • Raised unit test coverage on the order module from 18% to 76%, reducing production bug reports by 40% over three months.
  • Redesigned the CI pipeline, cutting run time from 22 minutes to 6 and shortening the feedback loop on every pull request.
  • Replaced a manual monthly reporting process with a scheduled script, freeing roughly 10 hours of human work per month.

Resume sample

Sara Rostami

Senior Backend Engineer

  • Tehran
  • [email protected]
  • +98 900 000 0000
  • github.com/example-handle
  • linkedin.com/in/example-handle

Summary

Backend engineer with five years on high-traffic e-commerce services. Focused on API design, service reliability and shortening the deploy cycle. Has led a three-person team technically.

Experience

  1. Senior Backend Engineer2023 to present
    A mid-sized online retailer
    • Extracted the order service from the monolith, taking deploy time for order changes from 40 minutes to 7.
    • Reduced search page response time by 65% by adding caching and rewriting the heaviest queries.
    • Documented and made code review mandatory for the team; production bugs halved over two quarters.
  2. Backend Engineer2020 to 2023
    A logistics startup
    • Designed and built the public shipment tracking API, serving roughly 200,000 requests a day by the end of its first year.
    • Took routing service test coverage from zero to 70%, making weekly deploys possible without rollbacks.

Skills

  • TypeScript
  • Node.js
  • PostgreSQL
  • Redis
  • Docker
  • REST API
  • Git
  • CI/CD
  • unit testing

Education

  • BSc Computer EngineeringA public university2016 to 2020

This sample is entirely fictional. The name, contact details and history belong to no real person.

Common mistakes that get resumes rejected

  • Listing every technology you have ever encountered

    A twenty-item row of tool names conveys nothing, because the reader cannot tell which you saw once in a tutorial and which you ran in production for two years. State the level of proficiency, or drop the tool.

  • Writing job descriptions instead of achievements

    "Developed and maintained the backend" is the job posting, not your work. Every line should say what you did and what changed because of it. If a sentence could be pasted into a teammate’s resume unchanged, it says nothing about you.

  • Multi-column graphic templates the ATS cannot parse

    Two- and three-column layouts, text inside floating boxes, and icons standing in for section headings all scramble during text extraction. A single-column structure with plain text headings dramatically improves the odds of clearing the filter.

  • Personal projects with no context

    A project name with no explanation of the problem it solved, the significant technical decision you made, or whether anyone used it takes up space without adding anything. Two lines of context make an ordinary project worth discussing in an interview.

  • One resume for every posting

    When the posting emphasises TypeScript and testing but your resume opens with PHP experience, both the ATS match score and the recruiter’s first few seconds work against you. Change the ordering and the emphasis for each application.

Frequently asked questions

One page if you have under eight years of experience. A second page is only justified when it carries as much relevant content as the first. Cut old and unrelated roles rather than compressing the text, because shrinking type to fit makes the document unreadable.

Personal projects, open-source contributions and small freelance jobs are all legitimate experience when written like experience: the problem, what you did, the result. What does not work is listing course names with nothing you actually built alongside them.

Yes, but only ones that open and are tidy. A single repository with a real readme and a meaningful commit history is worth more than three half-finished ones. A link resolving to an empty page or a 404 actively counts against you.

It depends on the market. For Iranian companies Persian reads more naturally, and technical names stay in Latin script anyway. International remote roles need English. If you are targeting both, keep two separate versions rather than one mixed bilingual document.

In the posting itself. The job title, the required skills section, and any technology repeated more than once are exactly what the filter scans for. Use them with the spelling the posting uses, but only where they are genuinely true of you.

Build your own resume on these principles

Add your resume and see how well it matches the posting you are targeting, then get a tailored, send-ready version.

Related resume samples