Software Engineer Resume Example: Annotated for ATS in 2026

A software engineer resume passes ATS screening when three things are true: a dedicated tech-stack section lists every technology in the job posting by its exact name, project and work bullets carry scale metrics (users, requests, latency, cost), and the layout is single-column — because two-column developer resumes routinely parse badly in Greenhouse and Lever. Below is a fully annotated example showing each element in place.

This walkthrough belongs to our annotated resume & CV examples library, alongside the data analyst resume example and other role-specific breakdowns. It's written for mid-to-senior engineers, with notes for freshers at the end.

The Example Resume: Senior SDE Applying via Greenhouse

Arjun has 6 years' experience and is applying to a fintech that posts on Greenhouse. The listing asks for Go, Kubernetes, PostgreSQL, Kafka, AWS, observability tooling and "experience operating production services at scale".

• ARJUN MEHTA
• Senior Software Engineer | Backend · Distributed Systems | Go · Kubernetes · AWS
• Bengaluru, India | arjun.mehta@email.com | github.com/arjunmehta | linkedin.com/in/arjunmehta

• SUMMARY
• Backend engineer with 6 years building and operating payment infrastructure handling 4M+ daily transactions. Cut p99 checkout latency 38% and infra spend ₹1.8 Cr/year through caching and right-sizing; primary responder for a 12-engineer on-call rotation.

• TECH STACK
• Languages: Go (primary), Python, Java, SQL
• Infrastructure: Kubernetes, Docker, Terraform, AWS (EKS, Lambda, RDS, S3), Helm
• Data & Messaging: PostgreSQL, Redis, Kafka, Elasticsearch
• Observability & Practices: Grafana, Prometheus, PagerDuty, CI/CD (GitHub Actions), GitOps, incident management, chaos testing

• EXPERIENCE
• Senior Software Engineer — PayZippy (Series-C payments company), Bengaluru | Mar 2022 – Present
• Own the ledger service (Go, PostgreSQL) processing 4M+ transactions/day at 99.99% availability.
• Redesigned hot-path caching with Redis, cutting p99 checkout latency from 420ms to 260ms during festive-season peaks of 12,000 requests/minute.
• Primary on-call for 12-engineer rotation; reduced Sev-1 incidents from 9 to 3 per year by adding alert thresholds and runbooks, cutting mean time to recovery (MTTR) from 45 to 18 minutes.
• Migrated 14 services from EC2 to EKS using Terraform and Helm; annualised infra savings of ₹1.8 Cr.
• Software Engineer — BlueStack Commerce, Pune | Jul 2019 – Feb 2022
• Built order-management APIs in Python/Java serving 800+ enterprise sellers; sustained 2x Black Friday traffic with no degradation after introducing Kafka-based event pipeline.
• Automated release checks in GitHub Actions, shrinking deployment time from 40 minutes to 7 and enabling daily releases.

• PROJECTS
• kwatch — open-source Kubernetes anomaly watcher: Go + Prometheus exporter flagging resource throttling before pod evictions; 900+ GitHub stars, used by teams at 20+ companies. Code: github.com/arjunmehta/kwatch
• QueueBench — Kafka vs RabbitMQ latency benchmark: reproducible harness with published results at 10k–100k msgs/sec; writeup linked from my GitHub profile README.

• EDUCATION
• B.Tech, Computer Science — College of Engineering Pune | 2015–2019
• AWS Certified Solutions Architect – Associate (2024)

Annotation: Header and Summary — the First 15 Words

The header and summary decide whether the human reader continues after the parser has done its job:

• The headline mirrors the target title ("Senior Software Engineer") and adds two specialisation keywords. If Arjun's official title were "Member of Technical Staff", this line would translate it into searchable language — honestly, without changing his employment record.
• Contact line carries location, GitHub and LinkedIn as plain text. For remote-friendly and relocation-open roles, adding "open to relocation" or time-zone coverage near here pre-answers a common filter question.
• The summary is three sentences, all evidence: scope (payments, 4M daily transactions), outcomes (latency, cost), and ownership signal (on-call rotation). No "passionate technologist" filler — every phrase could survive an interview probe.
• Numbers appear in the first sentence, because recruiter screens and keyword extractors both weight the top of the document most heavily.

Annotation: The Tech Stack Section Does the Heavy Lifting

Engineers often bury their tools inside bullets, hoping keyword scanners read carefully. They don't have to — a dedicated TECH STACK section with exact names gives both the parser and the recruiter instant coverage:

• Match exact spellings from the posting. If the job says "PostgreSQL", write "PostgreSQL"; if it says "Golang", consider "Go (Golang)" once so both variants match. The same trick covers "Kubernetes (K8s)". You're not stuffing keywords — you're covering synonyms honestly.
• Group by category, not proficiency bars. "Languages / Infrastructure / Data & Messaging" reads cleanly to humans and parses identically to any other list. Star ratings communicate nothing verifiable.
• "(primary)" next to Go does double duty: it satisfies depth screens without a separate "years per tool" table, which recruiters distrust anyway.
• Include operational keywords deliberately. Terms like "incident management", "on-call", "MTTR" and "GitOps" appear in senior postings but rarely in resumes — they're cheap matches that genuinely describe the work. For broader term lists by domain, see our ATS keywords by industry guide.

Annotation: Bullets Built on Scale Metrics

Every experience bullet above follows the same skeleton: action → system → number. Compare the rewrites:

• Weak: "Worked on payment systems and improved performance." Strong: "Cut p99 checkout latency 38% (420ms → 260ms) during 12,000 req/min peaks."
• Weak: "Responsible for deployments." Strong: "Shrunk deployment time from 40 minutes to 7, enabling daily releases."
• Weak: "Handled incidents as part of on-call." Strong: "Reduced Sev-1s from 9 to 3/year and MTTR from 45 to 18 minutes."

The numbers don't need to be enormous — they need to be real and specific. Requests per second, daily transactions, availability nines, latency percentiles, error budgets, cost saved, deploy frequency. If your metrics feel small, scope them ("first team where…", "within 3 sprints…"). Our guide on tailoring your resume to a job description explains how to reorder these bullets so the most relevant metric leads each application.

Annotation: On-Call and Incident Bullets — The Senior Signal

What separates a senior backend resume from a mid-level one isn't more technologies — it's evidence of ownership under failure:

• Rotation size and role: "primary on-call for 12-engineer rotation" proves trust, not just participation.
• Prevention, not just firefighting: alerts added, runbooks written, recurrence reduced. Interviewers read these as systems thinking.
• MTTR or availability deltas: quantifying reliability work converts invisible toil into résumé currency.

If you haven't carried a pager yet, borrow the pattern honestly from project work: uptime monitoring, load tests, postmortems written for college or open-source systems signal the same instinct.

Annotation: GitHub Links That Actually Get Clicked

• Paste full URLs as visible text (github.com/arjunmehta/kwatch) instead of hyperlinking words like "here" — parsers may strip hyperlinks, leaving nothing.
• Pin 3–4 repos and write profile-level README context. A recruiter who clicks should land on stars-and-documentation, not a tutorial clone.
• Show adoption numbers in the bullet itself: stars, forks, external users. Social proof survives even if nobody clicks.
• Keep personal projects technically current. An unmaintained repo from four years ago reads worse than none.

Do Two-Column Tech Resumes Fail in Greenhouse and Lever?

Frequently, yes — and developer forums and recruiter communities report this consistently enough to treat as settled practice. Greenhouse and Lever render uploaded resumes into a standardised candidate profile, and multi-column layouts can interleave text out of order: skills from a left rail bleeding sideways into experience entries, contact details fragmenting, dates detaching from roles. The result is a garbled profile the recruiter sees instead of your careful design.

The safe pattern costs you nothing visually meaningful:

• Single column, top to bottom, exactly like Arjun's example above.
• No tables for layout, no text boxes, no side rails for skills — put tech stack in the main flow.
• Contact info in the document body, never only in the header band.
• Text-selectable PDF exported from the source file, not a scanned or flattened image — see PDF vs Word for ATS in 2026 for the export nuances.

Most parsing failures trace back to a handful of repeat offenders; our 13 ATS resume mistakes list covers each with its fix. If your current CV is heavily designed, converting it takes minutes using our ATS conversion walkthrough.

Annotation: Project Bullets — Before and After Rewrites

Projects earn their place only when they read like engineering, not homework. The same before/after discipline applies:

• Name the artefact. A named system ("kwatch") reads as ownership; "a tool" reads as a task.
• State the load or constraint. Throughput, user counts, budgets and deadlines give interviewers a handle to grab.
• Prove it exists. Stars, users, deployed links or published write-ups convert claims into evidence — the same principle that makes GitHub links work.

Annotation: Education and Certifications for Engineers

Keep this section short but not empty: degree with full name, institution, years — CGPA included if strong and you're within ~3 years of graduation, omitted once experience dominates. One or two certifications are worth listing when they match the posting's stack (AWS, CKA, Terraform Associate); skip unrelated ones rather than padding. In India's mass-recruiter market (TCS, Infosys, Wipro), degree full name and CGPA are expected explicitly — the conventions differ from product companies, as covered in our TCS/Naukri IT resume format guide.

Adjustments for Freshers and Junior Developers

• Projects replace experience as the headline evidence — follow our projects-section framework for IT freshers, keeping the action → system → number skeleton even for college work.
• Lead with projects and internship work, keeping the action → system → number skeleton even for college systems.
• Keep it one page until ~3 years' experience; the length rules change later, per our one-page vs two-page analysis.
• Contribution over invention: meaningful pull requests to an existing open-source project outrank three abandoned repos.

Acronym Handling and Keyword Nuances for Developer Resumes

Tech job descriptions mix acronyms and expansions unpredictably — one posting says "K8s", the next spells out Kubernetes, a third says both. Cover your bases without keyword-stuffing:

• Pair expansion and acronym once each: "Amazon Web Services (AWS)", "continuous integration/continuous deployment (CI/CD)". After that, use whichever reads better.
• Match the posting's dominant form. If the description says "Postgres" three times and never "PostgreSQL", lead with "PostgreSQL (Postgres)" in your stack list and use their preferred form in bullets.
• Don't list tools you can't discuss. Exact-name matching only helps until the technical interview exposes a resume padded with frameworks you installed once.
• Version numbers rarely help. "Java 17" matters only when the posting specifies it; otherwise plain "Java" matches more searches.
• Skip soft-skill walls. "Team player, hard worker, quick learner" adds nothing to an engineering screen — demonstrate collaboration through bullets like "paired with product to re-scope…", which our skills guide for resumes contrasts in detail.

A Five-Minute Pre-Submission Check for Tech Applications

1. Paste resume + job description into a matcher and note missing exact tool names — fix honest gaps first.
2. Copy your PDF text into a plain-text editor. If the paste comes out garbled or reordered, Greenhouse's parser will garble it identically. Fix the layout source, not the symptom.
3. Confirm contact details and GitHub URL survived as body text, not header art.
4. Check that every date range sits beside its role on one line, so tenure math survives extraction.
5. Verify file naming: firstname-lastname-software-engineer.pdf beats resume_final_v6.pdf in recruiter downloads too.

Frequently Asked Questions

Do I need a separate skills section if my bullets already mention every technology?

Yes. Bullets prove depth but are scattered and phrased variably; parsers scoring exact terms match far more reliably against a consolidated list. Keep both — the stack section for coverage, bullets for evidence.

Should open-source contributions go under experience or projects?

Under projects unless they were paid work. A recurring contribution line ("maintainer of X; merged 40+ PRs from external contributors") belongs there with its metrics, not stretched into employment history.

Is it acceptable to list a tech I know at "basic" level?

In the stack section, yes — labelled honestly ("exposure to Rust"). What fails is listing it among primary languages and then failing depth questions. Labelled breadth beats hidden omission when postings ask for familiarity rather than mastery.

How long should a senior engineer's resume be?

Two pages is normal from roughly 8–10 years onward, provided page one stands alone — the pattern shown in Example 5 of our five annotated ATS resume examples. Below that threshold, compress to one.

Key Takeaways

• Dedicated tech-stack section with exact posting vocabulary beats tools buried in bullets.
• Every bullet: action → system → metric (latency, throughput, availability, cost).
• On-call/incident outcomes are the strongest senior-level signals you can add.
• GitHub links as plain URLs; pinned repos with adoption proof.
• Single-column layout — Greenhouse and Lever mangle multi-column files.

Want your own version of this resume scored against a real job posting? Build it free with JD2CV's ATS-safe resume templates — paste the job description, get your tech-stack keyword gaps flagged instantly, and export a parser-tested single-column file.