Skip to content
Laddro
Guide

How to Write a Software Engineer Resume That Passes the First Screen

A practical guide to writing a software engineer resume, with before and after bullets, where to put your stack, and how to quantify impact when you cannot share metrics.

6 min read

What engineering hiring managers actually read

An engineering manager skims a resume for two things: does this person build the kind of thing we build, and did their work matter. The second one is where most developer resumes fall apart.

A lot of engineers list technologies like a shopping receipt and describe their job as "worked on the backend." That tells a reader you were present. It does not tell them you shipped anything that changed a number. Hiring managers see hundreds of resumes that say "developed features using React and Node." The ones that get interviews say what the feature did and what it moved.

Before a human even reads it, though, your resume usually passes through keyword filtering. If the posting asks for Kubernetes and your resume says "container orchestration," you may not match. So a strong engineer resume has to do two jobs at once: satisfy the keyword filter and prove impact to the human who reads it next.

The structure that works for engineers

Keep it to one column and, in most cases, one page for early to mid career, two pages only once you have a decade of substantive work.

Contact line. Name, email, city, and links that matter: GitHub, and a portfolio or personal site if it shows real code. Skip the street address.

Summary, if you use one. Two lines. Your specialty, years, and the kind of systems you build. "Backend engineer, 5 years, distributed payment systems at scale." Optional but useful for career switchers or specialists.

Technical skills. A scannable, grouped list. Languages, frameworks, infrastructure, databases. This is where the keyword filter finds its matches, so be specific and honest.

Experience. Reverse chronological. Each role: company, title, dates, and three to five bullets that lead with impact.

Projects. For juniors, new grads, or career changers, a projects section can carry as much weight as a job. Include the problem, the stack, and the outcome or scale.

Education. Degree, institution, and relevant coursework only if you are early career.

Writing bullets that show impact

The formula is simple: what you built, the technical decision behind it, and the result. If you can attach a number, do. If you genuinely cannot share a metric, show scale or scope instead.

Before: "Worked on improving the checkout page."

After: "Rebuilt the checkout flow in React, cutting page load from 4.2s to 1.1s and reducing cart abandonment by 18%."

Before: "Responsible for backend APIs."

After: "Designed and shipped a REST API in Go serving 2M requests per day at p99 latency under 80ms."

Before: "Helped migrate the database."

After: "Led the migration from a single Postgres instance to a sharded setup, supporting a 6x growth in write volume with zero downtime."

If you truly have no numbers because the work was internal or early stage, anchor on scope: "sole engineer on," "across three services," "used by the entire sales team," "reduced deploy time from a manual hour long process to a one command pipeline." Scale is still evidence.

The keywords engineering filters look for

Keyword filtering in tech is real, especially at larger companies and through recruiting agencies. The fix is not to stuff a list. It is to make sure the exact terms from the posting appear where you genuinely used them.

Read the job posting and mirror its wording. Put the specific technology in the bullet where you used it, not just in a skills blob. If a filter and a human both read your resume, the human sees the proof and the filter still gets its match.

Terms worth checking against the posting:

  • Exact language and framework versions when they ask: "TypeScript," "React 18," "Python 3," not just "JavaScript"
  • Infrastructure by name: AWS, GCP, Kubernetes, Docker, Terraform
  • Databases and messaging: PostgreSQL, Redis, Kafka, DynamoDB
  • Practices they mention: CI/CD, TDD, microservices, event driven architecture
  • The role shape: backend, frontend, full stack, platform, SRE

A word of honesty. Only list what you can talk about in an interview. A filter matching "Kubernetes" gets you in the room; a manager asking about it and hearing nothing gets you out of it.

Junior, career changer, and senior: where to put the weight

The structure is the same for everyone, but the balance changes with experience.

If you are a junior or a new grad, projects carry the resume. A hiring manager knows you have limited work history, and they are not holding it against you. What they want is evidence you can build something real and reason about it. Give each project the problem it solved, the stack, and the scale or outcome, even if the outcome is "deployed and used by 200 people in a student community." A deployed side project you can talk about in depth beats a long list of tutorials you followed. Put your strongest project or internship first, above coursework.

If you are a career changer coming from a bootcamp or self study, do the same, and be honest about the timeline rather than hiding it. Your capstone projects, any freelance or open source contributions, and any technical work from your previous career are all fair evidence. A former analyst who automated a reporting pipeline in Python has real engineering experience, so frame it as engineering.

If you are senior, the resume flips toward scope and ownership. Lead each recent role with the systems you owned, the decisions you made, and the scale you operated at. Show leadership: mentoring, setting technical direction, driving a migration, reducing on call load. Trim your early roles to a line or two. A staff or senior candidate does not need three bullets about a junior job from eight years ago. The reader wants the recent, high leverage work up top.

Common mistakes that get developers rejected

Skills without context. A wall of 40 technologies with no bullets showing where you used them reads as padding. Group them, then prove the important ones in your experience.

Describing the team's work, not yours. "We built a real time analytics platform" hides your part. Say what you personally owned.

No metrics anywhere. Latency, throughput, error rate, load time, cost, user count. Engineering is measurable. A resume with no numbers looks like you never shipped anything that mattered.

Overdesigned templates. Two column layouts with sidebars and icons often break parsing. A clean single column resume is safer and reads faster for a busy hiring manager.

Listing every course and tutorial. A finished, deployed project beats ten half done ones. Show the work you can defend.

Put it together

  1. Open the resume builder and choose a clean, single column template
  2. Group your technical skills so the filter and the reader both find them fast
  3. Rewrite each bullet to lead with impact and a number
  4. Match the exact terms from the job posting and watch the ATS score respond
  5. Export a text based PDF and apply

For a full worked example, the software engineer resume example shows how to lay out a tech stack, phrase impact bullets, and structure experience so both the filter and the hiring manager are satisfied.

Write your engineer resume now

You know the structure, the bullet formula, and the keyword rule. Now build it.

Open the resume builder, pick an ATS safe template, and write bullets that lead with impact. The score updates live as you match the posting. Free to build and download, no sign up to start.

If you want to see the layout options first, browse the resume template gallery. Already have a resume and a specific role in mind? Run it through the AI tailoring tool to match it to that job description.

Ready to build your resume?

Put this into practice. Open the builder and create your resume step by step.

Build your resume

Free to use. No account needed to start.