A software engineer resume for remote jobs has to do three things on one page: survive the applicant tracking system’s parser, show what changed because of your work, and make it obvious you can work well with a team you rarely see in person. Use a simple single-column layout, write bullets around outcomes instead of duties, and put your time zone and async habits where a recruiter will notice them.
Below you’ll find the structure, the ATS basics that actually matter, a bullet formula with before-and-after examples, how to signal remote readiness, a one-page outline you can copy, and the mistakes that get resumes skipped.
The one-page structure
Keep it to one page unless you have many years of directly relevant experience. Remote roles draw applicants from many countries, and in my view a dense two-page resume from a junior or mid-level developer reads as unfocused next to a tight one-pager. Use this order:
- Header: name, target title, location with time zone, email, and links to GitHub, your portfolio, and LinkedIn.
- Summary: two or three lines. Optional, but useful for career changers and remote applicants.
- Skills: grouped by type, limited to what you’d be comfortable being interviewed on.
- Experience: reverse chronological, three to five bullets per role.
- Projects: two or three, with links. Move this section above Experience if you don’t have professional experience yet.
- Education and certifications: short. Students and recent graduates can move it higher.
ATS basics, without the myths
An applicant tracking system is mostly a database and workflow tool. It stores your application, tries to parse your resume into fields such as employers, dates, and skills, and lets recruiters search and filter candidates. The practical risks are a parser scrambling your resume so it never shows up in a recruiter’s search, and knockout questions on the application form that screen you out automatically.
So the rules are mostly about being easy to parse:
- Use a single-column layout. Tables, text boxes, and multi-column templates often parse out of order.
- Keep contact details in the body of the page, not in the document header or footer.
- Use standard section headings: Experience, Projects, Skills, Education.
- Submit a PDF with selectable text, exported from a word processor or LaTeX, not a scanned image or a graphic design export.
- Run the plain-text test: open your PDF, select everything, and paste it into a plain text editor. If the order is scrambled or text is missing, a parser will struggle too.
- Spell out important acronyms once, such as “Amazon Web Services (AWS)”, so either form matches a search.
- Answer application-form questions as carefully as you write the resume. Sometimes they’re the only part anyone screens.
The Tech Interview Handbook’s resume guide covers these formatting rules in more depth and is worth reading in full.
Keywords matter, but use them honestly. If the posting asks for TypeScript, PostgreSQL, and CI/CD and you’ve used them, those words should appear in your experience bullets, backed by context, not only in a skills list. Don’t add terms you can’t discuss in an interview.
The bullet formula: action, scope, result
Weak resumes list duties (“responsible for…”). Strong ones show what you did and what changed because of it. A formula that works:
[Strong verb] + [what you built or changed] + [how, including the key technology] + [the result, with a number or an observable effect]
Here’s how that changes typical bullets. The values in square brackets are placeholders: replace them with numbers you actually measured, or drop them.
| Before | After |
|---|---|
| Responsible for the backend API. | Built the booking API in Node.js and PostgreSQL used by the web and mobile apps, adding input validation and integration tests that caught [3] breaking changes before release. |
| Worked on app performance. | Cut Android cold-start time from [4.1 s] to [1.8 s] by lazy-loading the home feed and removing [2] blocking network calls at launch. |
| Helped with the payment feature. | Integrated a payment provider’s checkout and webhooks with idempotent order updates, so duplicate webhook deliveries stopped creating double charges. |
| Did code reviews. | Reviewed [5 to 10] pull requests a week for a team spread across [3] time zones, and wrote the review checklist the team now uses for new hires. |
| Made a dashboard. | Replaced a manual weekly spreadsheet report with a scheduled job and a dashboard, saving the operations team about [3 hours] a week. |
| Fixed bugs. | Fixed [40+] production bugs over [6] months, adding a regression test for each; the checkout flow had [no] repeat incidents the following quarter. |
No numbers? That’s common, especially early in your career. Use other evidence instead:
- Scope: how many users, screens, endpoints, or services your work touched
- Before and after: “Replaced manual deployments with a CI pipeline”
- Adoption: “Now used by all three support teams”
- Ownership: “Owned the feature from spec to release”
Never invent a metric. Interviewers ask how you measured it, and an answer you can’t back up does more damage than a bullet with no number at all.
Writing the summary and skills sections
The summary is the first thing a recruiter reads, so make it specific: your role, your main stack, one piece of evidence, and your remote logistics. Skip adjectives like “passionate” and “hardworking”; they’re on every resume. Three templates to adapt:
- Junior or self-taught: “Frontend developer building accessible React and TypeScript apps. Shipped [project], used by [who], and contributed fixes to [open source project]. Based in [city] ([UTC offset]) and used to working asynchronously.”
- Mid-level: “Android engineer with [N] years shipping Kotlin apps for [type of product]. Focused on offline-first architecture and release quality. Has worked with product teams across a [N]-hour time difference.”
- Career changer: “Backend developer coming from [previous field], where I automated [process] with Python. Now building APIs with Django and PostgreSQL; [project] handles [what it does].”
For skills, group them (languages, frameworks, data, tools and infrastructure), put your strongest first in each group, and leave out proficiency ratings. Don’t list soft skills like “team player” or “good communicator”; show them in your experience bullets instead, where they’re believable.
How to signal remote readiness
Remote hiring managers worry about a few specific things: will this person communicate clearly in writing, will they get themselves unblocked without someone nearby, and will their working hours overlap enough with the team’s. Address each one on the page.
Put your time zone in the header
Write your location with the UTC offset and, if it helps, the overlap you can offer:
Jakarta, Indonesia (UTC+7) ยท Available for [4] hours of overlap with Central European business hours
That answers the first logistics question before anyone asks it. If you’re open to working as an independent contractor or through an employer-of-record service (a company that legally employs you on the hiring company’s behalf), say so in your summary. It removes an obstacle for employers without a legal entity in your country.
Write bullets that show async work
Listing “Slack, Zoom, Jira” under skills proves very little. Show the habits behind the tools instead:
- Wrote design docs for [2] features and collected feedback asynchronously from engineers in [3] time zones before implementation
- Kept written handoff notes for an on-call rotation shared between Asia and Europe
- Wrote pull request descriptions with context, screenshots, and test steps, so reviewers in other time zones could approve without a call
- Documented the local development setup, cutting new-hire setup from [two days] to [an afternoon]
If you’ve never worked remotely, look for the same behaviors elsewhere: open source contributions reviewed by maintainers abroad, freelance clients you worked with over email, or documentation you wrote for a team.
Link to your writing
A blog post, a detailed README, or a well-written open source issue is direct evidence of written communication. One good link is enough. For what to put behind your project links, see our guide to building a software engineer portfolio that gets interviews.
One-page template outline
Copy this outline into a plain document and fill it in. If you prefer LaTeX, Jake’s Resume on Overleaf is a simple single-column template with the same sections.
FIRST LAST
Software Engineer (Backend / Mobile / Full-stack)
City, Country (UTC+X) | email@example.com | github.com/you | you.dev | linkedin.com/in/you
SUMMARY
[Role] with [N years or background] building [kind of products] in [main stack].
Comfortable working async across time zones. [One standout result or project.]
SKILLS
Languages: ... Frameworks: ... Data: ... Tools and infrastructure: ...
EXPERIENCE
Company Name, Remote (Country) | Job Title | Mon YYYY - Present
- Verb + what + how + result
- Verb + what + how + result
- Verb + what + how + result
Company Name, City | Job Title | Mon YYYY - Mon YYYY
- ...
PROJECTS
Project Name | Stack | live link, repo link
- What it does and who uses it, plus one technical decision or result
EDUCATION AND CERTIFICATIONS
Degree or program, Institution, YYYY
Relevant certification, Issuer, YYYY
Common mistakes
- Design-heavy templates. Two columns, icons, and skill bars look nice and parse badly. “Python: four out of five stars” tells a reader nothing.
- Local CV conventions on a global application. In some countries a CV traditionally includes a photo, date of birth, marital status, or religion. International remote employers generally don’t expect these details, and some would rather not receive them. Leave them out unless the posting asks.
- Listing every technology you’ve touched. It dilutes your real strengths and invites questions you can’t answer.
- Duties instead of outcomes. “Responsible for maintaining the API” says nothing about how well you did it.
- One resume for every job. Reordering bullets and adjusting the summary for each application takes minutes.
- Broken or private links. Check that every repository is public and every demo loads.
- Vague dates. Use month and year, and label freelance or part-time work clearly.
- A careless file name. Send “Firstname-Lastname-Resume.pdf”, not “CV final v3 (2).pdf”.
- Typos. Run a spell checker, then read the page aloud once.
For mistakes in the rest of the application, from cover messages to follow-ups, see remote job application mistakes to avoid.
FAQ
Should a software engineer resume be one page?
For most junior and mid-level engineers, yes. With long and relevant experience, a second page is acceptable, but the first page still has to carry your strongest, most recent work, because that may be all a recruiter reads.
Do I need a cover letter for remote jobs?
If the application has a field for one, use it, and keep it short: why this company, your most relevant piece of evidence, and your logistics (time zone, contract type, start date). Remote teams rely on writing, so a clear, specific note works in your favor; a generic one does the opposite.
Should I put salary expectations on my resume?
No. Give them in the application form if it asks, or in the recruiter call. Research the range for the role and location first, and say whether your number is gross or net and in which currency.
A 15-minute tailoring routine
Before each application:
- Highlight the five most important requirements in the job post.
- Check that each one you genuinely have appears in a bullet, not only in your skills list.
- Reorder bullets so the most relevant ones come first in each role.
- Adjust the title under your name to match the role, for example “Mobile Engineer” instead of “Software Engineer”.
- Rewrite the last line of your summary for this company.
- Run the plain-text test again and click every link.
Then do one thing today: rewrite your three weakest bullets with the formula above and add your time zone to the header. When the resume is ready, use our list of where to find remote developer jobs to start sending it out.