Software Engineer resume tips, roasted and fixed
Updated 2026-10-12
Most software engineer resumes fail the same way: they read like a dependency list. Twenty-five technologies in a skills block, then bullets that say “worked on backend services” without saying what the service did, how big it was, or what changed because you touched it. A reviewer skimming a stack of these cannot tell the person who built the payments retry system from the person who once fixed a typo in its README.
Strong engineering resumes are boring in the best way. Each bullet names the system, the problem, the thing you built or changed, and the result in terms someone outside your team would care about: latency, uptime, cost, deploy time, developer hours saved. The tech stack shows up inside the bullets where it was actually used, so the skills section confirms what the experience already proved instead of carrying the whole page.
What they screen for
- Languages and frameworks that match the posting, shown inside real project bullets rather than only in a skills list
- Scope and ownership: whether you built, led, or maintained a system, and how big it was (users, requests, data volume, team size)
- Measurable outcomes such as latency, error rates, uptime, cloud cost, build or deploy time
- Production experience: on-call, incident response, monitoring, testing and CI/CD habits
- System design signals: APIs you designed, migrations you ran, tradeoffs you made
- Collaboration: code review, mentoring, working with product and design
- A GitHub, portfolio or shipped product link for early-career candidates, with something worth clicking
The mistakes we see most
A skills section with every technology you have ever installed
You list Rust, COBOL, Svelte and Kubernetes. Your bullets mention one Flask app. The jury has questions.
Keep the skills list to what you could be interviewed on tomorrow, grouped by type (languages, frameworks, cloud, data, tooling). If a technology never appears in a bullet or project, ask whether it earns its spot.
Bullets that describe the team’s work, not yours
“We migrated to microservices.” Great. Was “we” you, or were you in the Slack channel watching it happen?
Start bullets with what you did: built, designed, migrated, debugged, owned. If it was a team effort, say your piece of it, such as “wrote the data backfill for the billing service migration.”
No results, only activities
“Wrote unit tests.” So does everyone who has ever been yelled at by a linter.
Tie the work to what changed: fewer production bugs, faster releases, a coverage target hit, an outage that stopped recurring. Use your own real numbers; if you don’t have exact figures, describe the change plainly instead of inventing one.
Side projects that are just tutorial clones
A to-do app, a weather app and a calculator. Bold of you to compete with the first week of every bootcamp.
Pick one or two projects with a real user or a real problem, and describe them like work: what it does, the stack, one interesting technical decision, and a link that works.
Burying the stack the posting asks for
The job says Go and AWS. You used both for two years. They appear on line 31, in a font size usually reserved for legal disclaimers.
Read the posting, then make sure the overlapping technologies show up in your most recent, most relevant bullets. This is where tailoring to a specific job matters, and Resume Roast can do that pass against a posting you paste in.
Bullet points, before and after
Worked on the checkout API, found slow database queries and fixed them so pages loaded faster.
Sped up checkout page loads by finding and fixing slow database queries behind the checkout API.
Leads with the result and says how. If you measured the speedup, add your own before and after numbers.
Responsible for CI/CD pipeline, reduced build time from 25 minutes to 8 minutes.
Cut CI build time from 25 to 8 minutes by owning and restructuring the team’s CI/CD pipeline.
Leads with the result and turns “responsible for” into ownership.
Helped with migration from monolith to microservices using Docker and Kubernetes.
Containerized services with Docker and deployed them on Kubernetes as part of the monolith-to-microservices migration.
Replaces “helped” with the actual work and keeps the stack where it was used.
Was on call and fixed production issues.
Served in the on-call rotation, triaging and resolving production incidents.
Clearer, but add your own specifics, such as how many incidents or what kind, if you can.
A summary that says something
Passionate software engineer with a love for clean code and solving problems. Team player who is always eager to learn new technologies.
Software engineer focused on clean, maintainable code and practical problem solving. Works well on teams and picks up new technologies quickly.
Drops the filler adjectives. Add your years of experience, main stack and the kind of systems you build, using your own facts.
Keywords postings ask for
Use the ones that are true for you, in the words the posting uses.
Python · Java · JavaScript · TypeScript · Go · React · Node.js · REST APIs · SQL · PostgreSQL · AWS · Docker · Kubernetes · CI/CD · Git · unit testing · microservices · system design · Agile · code review
Questions people ask
- Should a software engineer resume be one page?
- For new grads and people with a few years of experience, one page is the norm and forces you to cut weak bullets. Senior engineers with a long record of relevant systems can use two pages, as long as the second page is still worth reading.
- Do I need a GitHub link on my resume?
- It helps most when you are early in your career or changing into software, because it is evidence you can actually build things. If your GitHub is empty or full of forks, leave it off. A link to one solid project beats a profile with nothing to look at.
- How do I describe work I can’t talk about because of an NDA?
- Describe the type of system and the technical work without naming confidential details: “built an internal fraud scoring service in Java handling card transactions” says plenty without leaking anything. Use percentages or relative changes if exact figures are sensitive, and only if they are true.