How to write a software engineer resume
Updated 2026-09-02
A software engineer’s resume is judged on scope and ownership. A long list of technologies adds nothing. A reviewer looks for three things: where your system ended, what load it carried, and whether you were there when it broke. A resume that lists fifteen languages with no subject in any sentence answers none of the three.
Describe systems by load and constraint. “Built with React and Node.js” names the materials. “Serving [N] requests per day with a p95 under [N] ms” describes the engineering. Every number on this page is an [N] placeholder on purpose. The real figures have to be yours, because you are the one who will defend them.
Below: the section order that parses cleanly, three summary levels, bullets grouped by competency, before-and-after rewrites, what to cut from the skills section, ATS keywords, common mistakes, and the follow-up question each claim invites.
What a finished one looks like
Below is a complete sample for a fictional person, rendered as a real page by the product's own sheet and scored by the same rules engine the editor uses — the number is computed, not typed in. Every figure a bullet owes is left as [N], which is why the score stops under the cap. That is not a flaw in the example; it is the product's rule, demonstrated.
Wei-Ting Lin
Education
- Built a distributed key-value store for the systems capstone that sustained [N] thousand ops/sec under a simulated network partition
- Mentored [N] first-year students as the systems programming lab teaching assistant, rewriting the debugging handout the course still assigns
Experience
- Cut p95 order-routing latency from [N] ms to [N] ms by replacing synchronous fan-out with a worker pool
- Halved on-call pages by adding SLO-based alerting and deleting [N] alerts that had never preceded an incident
- Designed the payment-webhook idempotency layer, ending [N] duplicate charges a month refunded by hand
- Shipped a Go log shipper handling [N] million events a day, replacing a pipeline that dropped [N]% at peak
- Built the integration test harness adopted by [N] teams, cutting release regressions from [N] to [N] per quarter
- Led the CI migration from Jenkins to GitHub Actions, shortening median build time from [N] min to [N] min
- Automated the nightly catalog reconciliation in Python, retiring a manual checklist two operations staff worked through every morning
- Instrumented checkout with request tracing, surfacing the slow inventory call behind [N]% of abandoned carts
- Consolidated [N] thousand product images onto one CDN path with generated thumbnails, cutting median product-page load from [N] s to [N] s
Projects
- Launched an open-source token-bucket limiter now used in production by [N] companies, with [N] GitHub stars
- Rebuilt the capstone key-value store on a from-scratch Raft implementation, which doubled sustained write throughput under simulated partitions
Additional Information
Structure and section order
One column, standard headings, no icons or skill bars. This is what lets an applicant tracking system read the page at all. Two-column layouts merge unrelated lines, and star ratings simply vanish.
There is one ordering rule: strongest evidence first. For engineers that evidence sits in Experience, so every other section gets out of its way.
- 1Summary
Three sentences: level, domain, and your single most defensible quantified fact. The reviewer decides here whether to keep reading.
- 2Experience
Reverse chronological. Three to five bullets per role, verb-first, scope plus an [N] outcome. This section should own most of the page.
- 3Projects (optional)
Only if there are real users or an engineering decision worth probing. Written exactly like work experience.
- 4Skills
Only what you have shipped with recently, grouped by category. This section is a keyword table, so keep it short.
- 5Education
One or two lines at the bottom after three years of work. Entry-level candidates can move it up with relevant coursework.
Summary examples by level
A summary previews your strongest evidence. One example per level, with numbers left as [N] for you to fill.
Backend engineer with internship experience building and operating services in Go and PostgreSQL. Shipped a rate-limiting middleware adopted by [N] internal services and handled production incidents under supervision. Looking for a team where code review and operational ownership start on day one.
At entry level, lead with one thing that had real users. Middleware adopted by [N] services is a fact an interviewer can probe.
Software engineer with [N] years across payments and logistics systems, owning services from design review to on-call. Cut p95 latency and infrastructure cost on systems handling [N] requests per day. Comfortable being the engineer who writes the design doc and then answers for it in production.
Mid-career means showing the full span of ownership: design through on-call. The last sentence states a way of working, which beats any adjective.
Senior engineer setting architecture direction for a [N]-service platform and mentoring [N] engineers across two teams. Retired two legacy systems without downtime and turned recurring incident patterns into roadmap items. Works best where technical decisions are written down, argued, and revisited on evidence.
Senior evidence is change left in other places: systems safely retired, incident patterns turned into roadmap items. Not one word is self-appraisal.
Bullets grouped by competency
Engineer bullets read best grouped by competency. The skeleton never changes: verb, scope, method, [N] outcome.
Delivery and iteration speed
· Shipped a checkout service rewrite in [N] weeks by cutting scope to two payment flows, then closing the remaining edge cases over [N] follow-up releases.
· Cut deployment lead time from [N] days to [N] minutes by moving the team to trunk-based development with automated canary rollouts.
· Delivered a partner-facing API from design doc to production in [N] weeks, including a versioning policy and a migration path for [N] existing integrations.
Reliability and debugging
· Diagnosed a memory leak that restarted production pods every [N] hours, tracing it to an unbounded cache and shipping the fix within one on-call shift.
· Cut P1 incidents from [N] to [N] per quarter by alerting on user-visible symptoms instead of host metrics.
· Raised availability of the order service to [N]% by adding retry budgets and circuit breakers at the three most failure-prone downstream calls.
Performance and cost
· Reduced p95 checkout latency from [N] ms to [N] ms by batching downstream calls and moving session lookups into an in-memory cache.
· Cut monthly infrastructure spend by [$N] by right-sizing over-provisioned instances and archiving [N] TB of cold data to object storage.
· Profiled a report-generation job, removed an O(n²) join, and brought runtime from [N] hours to [N] minutes at peak volume.
Architecture and tradeoffs
· Split a monolith into three services along team ownership lines, keeping shared billing logic in one place to avoid distributed transactions.
· Chose PostgreSQL over an event-sourced design for the order system, trading replay ability for operational simplicity, and documented when to revisit the decision.
· Introduced idempotency keys for payment writes, eliminating duplicate charges under retry storms without adding a distributed lock.
Cross-functional collaboration
· Turned a vague “make search better” request into [N] measurable relevance fixes by pairing with support to label the worst-failing queries.
· Wrote the rollout plan for a pricing change with product and legal, sequencing feature flags so each market could launch independently.
Technical leadership
· Onboarded [N] engineers with a paved-path starter service and a written runbook, cutting time to first merged change from [N] weeks to [N] days.
· Ran design reviews for a [N]-engineer group, cutting rework by requiring a one-page decision doc before implementation starts.
Before and after
The same experience, written weakly and then well. The defect named in each “why” matters more than the rewrite itself.
Responsible for backend development of the e-commerce platform.
Owned the order and inventory services for an e-commerce platform serving [N] daily users, including schema design, on-call, and two major version migrations.
Why it works · “Responsible for” only says where you sat. The rewrite has scope (two services), scale ([N] daily users), and facts an interviewer can probe (the migrations).
Used React, Node.js, Docker, Kubernetes, AWS, Redis, and MongoDB to build applications.
Built the seller dashboard in React against a Node.js API, containerizing the stack so preview environments spin up per pull request in [N] minutes.
Why it works · A tool list is not an achievement. The verb becomes “built”, only the tools the story needs stay, and the tooling shows a result: per-PR previews.
Improved system performance significantly.
Cut p95 API latency from [N] ms to [N] ms by adding a read-through cache and removing [N] redundant database round trips per request.
Why it works · “Significantly” cannot be checked. The rewrite names the metric (p95), leaves the values as [N], and states the method. Every part invites a follow-up you can answer.
Participated in the migration to microservices.
Migrated the notification pipeline out of the monolith, designing the queue-based interface and running both systems in parallel for [N] weeks before cutover.
Why it works · “Participated” hides which part was yours. The rewrite names your service, your interface design, and how you de-risked the cutover.
Wrote unit tests to ensure code quality.
Raised branch coverage on the billing module from [N]% to [N]% and wired the suite into CI so regressions block merge instead of reaching production.
Why it works · Writing tests is routine work. The highlight is the coverage change and where the suite now stands guard: before merge.
What belongs in the skills section
One rule: defensible. If you would not take a whiteboard question on it, it does not belong on the sheet.
Worth the space
Go · TypeScript · Python · React · Node.js
PostgreSQL · Redis · Kafka · Docker · Kubernetes · AWS
CI/CD · OpenTelemetry · load testing · incident response
Cut these
- Microsoft Office · No engineer has been hired for it; it only dilutes the page.
- Every language ever touched (C++, PHP, Ruby…) · Interviewers probe the weakest item on the list. Keep what you would take a whiteboard question on; delete the rest.
- Adjectives like “hard-working” or “fast learner” · A claim without evidence is noise. If you learn fast, show a stack switch as a bullet instead.
- Agile / Scrum · Every company calls itself agile, so the word sets you apart from nobody. Keep it only if you ran the process.
ATS keywords
The tracking system matches keywords before a human reads content. These are the terms commonly matched for this role, by category.
Only use terms your experience can defend. A keyword you cannot discuss hurts more than leaving it out. Stuffing does not move parsers, and a human reader sees noise.
The evidence that is not on the resume
For an engineer the resume is an index; the evidence lives somewhere a reviewer can open, and they do open it. Write every link as one that will be clicked within the minute. What follows is what they see, in the order they see it, the line on the sheet that points there, and when leaving the link off is the right call.
- The GitHub profile: pinned row, last-updated dates, contribution graph
The tab is usually open before your second role has been read. What lands first is not code: it is the pinned repos, the “updated” date beside each one, and whether the contribution graph is blank. The pin row holds six, which is a ceiling and not a quota — three repos you can walk through line by line beat six that fill the space. Private work can be counted toward the graph in your settings, so the account stops looking abandoned without exposing anything.
- The first screen of the README, before any scrolling
Assume the reader stops at the fold. That screen owes three things: the problem the project solves, the tradeoff you made, and the one command that runs it. Setup goes above the architecture diagram, because setup is the part they will actually follow. A repo with no LICENSE file reads to a company lawyer as code nobody is allowed to use.
- A URL that answers right now
Something that runs earns trust faster than something that compiles, but only while it is genuinely running. A free-tier instance that has gone to sleep returns a spinner, and a demo account with an expired password is a 404 with extra steps. Open it in a private window the morning you send the application. If it does not come up, cut the URL and keep the repo rather than letting the reviewer find out for you.
- The line on the sheet that points at it
The sample above has no GitHub field in the header. The pointing is done by each Projects entry carrying its own line: ratelimit-go · Go, Redis · github.com/[your-handle]/ratelimit-go. Put github.com/[your-handle] in the header only when the profile itself is the thing worth opening. Do both, and the reader spends a click finding which one you meant.
- When leaving the link off is the stronger move
Coursework, a row of forks, and a last commit from two years ago: delete the field. That is not a concession. Write one finished small thing into Projects instead — narrow scope, explainable end to end, a file you can open and scroll during the interview. An empty profile is an invitation to go and look at the weakest evidence you have.
- What can be checked against what is only claimed
Stars, downloads, merged pull requests: one click and the reviewer knows. A figure in a bullet has to match what that page shows today, and when the figure is small, write what the code does instead. Certifications behave the same way — AWS and the CKA both issue a credential ID and an expiry that verify on the issuer’s own page, so put the year on the line and mark or remove anything lapsed. When the sheet says one thing and the register says another, nobody reads it as a typo.
- Work behind an NDA or a private repo
The company repo is not yours to hand over, but its shape is: the load it carried, the constraint you designed against, the interface you owned — with no customer name and none of their rows. The checkable substitute is whatever spilled outward: a patch you sent upstream to a dependency, a merged issue thread, a talk with public slides. Those carry your handle and do not belong to your employer.
Common mistakes on engineer resumes
- 1Listing every language ever touched
The longer the list, the less each item is believed. Interviewers probe the weakest one; a bad answer reprices the whole list.
- 2Framework names instead of system description
“Built with React and Node.js” names materials. The constraints are the real evidence of engineering: load, data volume, and latency budgets.
- 3Bullets with no subject
“The team migrated…” credits no one. The word before the verb has to be you: designed, migrated, debugged.
- 4Side projects disguised as employment
Getting caught costs the credibility of the entire resume. Keep a separate Projects section, and only for work with users or decisions worth probing.
- 5Two-column layouts and icon skill bars
Tracking systems read line by line: two columns merge unrelated experience, and star icons vanish. One column with standard headings is the floor.
- 6A GitHub link that leads to an empty profile
A link is an invitation to click. If the profile holds coursework and forks, leaving it off is the stronger move.
The follow-up each claim invites
Every claim on your resume is an interview question you wrote yourself. Before keeping a line, ask: does it survive three levels of probing?
Cut p95 latency from [N] ms to [N] ms.
Where was p95 measured? Client, load balancer, or the service itself? What happened to p99 over the same window?
Know the measurement point, the time window, and the traffic conditions. If p99 stayed flat or got worse, say so first. Better than having it dug out.
Scaled the service to [N] requests per second.
What was the bottleneck? CPU, the connection pool, or lock contention? Where does the next one appear?
Bring the load-testing method and the source of the numbers. “We added machines” is not an answer; explain why horizontal scaling worked in that architecture.
Migrated the monolith to microservices.
What did you decide not to split? Looking back, which service boundary was drawn wrong?
A credible boundary story includes the parts left unsplit and one admitted mistake. “We got them all right” reads as: you were not in the room.
Reduced production incidents by [N]%.
Over what period? Did the definition of an incident, or the severity levels, change during it?
State the window and the definition plainly. If the severity scheme changed mid-period, say so. Otherwise the number reads as a story rather than a measurement.
Led a team of [N] engineers.
Led as in managed, set technical direction, or coordinated the project? Did you have a part in their performance reviews?
Multinationals read “led” precisely. Settle on the definition you can hold, and bring one technical decision you actually made as the proof.
FAQ
Will my resume be filtered out without a well-known company on it?
The first filter is the tracking system’s parsing and keyword match. The company name comes later. What you control is stating system scale, ownership boundaries, and outcomes anyone can check. The bullet structure on this page exists for that.
Screening by brand mostly happens on roles filled through outbound recruiting. That is a targeting problem, and a resume cannot fix it.
Can side projects count as work experience?
Not inside Experience. They earn a separate Projects section if there are real users or an engineering decision worth probing. Write them exactly like work bullets: scope, method, [N] outcome.
The job posting lists a stack I have only partly used. Should I add its keywords?
Only what you can hold. Adjacent technology can be layered honestly: if Go is your main language and you have used Kafka without ever tuning it, Kafka goes in a secondary skills position, not in an achievement bullet.
The generator here will not add technology you did not provide. That is deliberate.
Should an English resume include a photo, age, or GitHub link?
No photo, no age. Compliance processes at most multinationals reject those fields. Add GitHub only when there is something worth seeing. A profile of coursework and forks is weaker than no link.
One page or two?
Under ten years of experience: one page. Cut by demoting old roles instead of shrinking the font. A position from three years ago becomes two lines, and the space goes to your strongest current evidence.
Turn your systems into bullets interviewers want to probe
Describe what you built in plain language. The Tech lens rewrites it into English at the level on this page. The 0–100 score comes from a rules engine, so the same draft gets the same score every time. Every missing number stays a yellow [N] placeholder for you to fill, because you are the one who has to defend it.
Try 2 free draftsKeep reading
The same person’s cover letter
The letter cites only what this resume states, explained paragraph by paragraph, with the engine’s letter check beside it.
How to write a software engineer cover letter