Software Engineer Resume Example (Structure and Bullets)

Engineering resumes work when a hiring manager can see your stack and one or two shipped outcomes in 20 seconds. Use MineResume’s Professional Sidebar or Modern template, then keep bullets specific.

Suggested order

• Header: name, email, city, GitHub, LinkedIn (full URLs or clean handles).
• Summary: years of experience, primary languages, type of systems (APIs, mobile, data).
• Skills: languages, frameworks, databases, cloud — grouped, not a paragraph.
• Experience: company, title, dates, 3–5 bullets each.
• Projects: only if they are public or as substantial as a job.
• Education.

Bullet pattern

Verb + what you built + how (tech) + result. Weak: “Responsible for backend.” Stronger: “Built REST endpoints in Node.js for order status, cutting timeout errors by 30% after adding retries.”

What to cut

• Every programming language you touched in college if you cannot answer questions on it.
• Soft-skill lists with no evidence (team player, hard worker).
• Screenshots inside the PDF; link a portfolio instead.

Sample experience bullets

• Shipped a Node.js API for order status with retries after timeout errors showed up in logs.
• Wrote Playwright tests for checkout and caught a tax-rounding bug before release.
• Documented local setup in the README so two new joiners could run the app on day one.

Intern vs full-time

Interns should emphasize one or two merged PRs or a demo, not every tutorial. Full-time engineers should show ownership of a service or a metric. Keep GitHub in the header.

A stack section that a hiring manager can scan

Group skills: languages, frameworks, datastores, cloud, and testing. Put the ones from the posting first. If you used Django for two years and Flask for a weekend, Django goes first. A single comma-separated dump of twenty tools looks like a keyword bag.

Experience bullets should mention the production surface. “Wrote Python” is weak. “Wrote a FastAPI service that returned order status for the shop app; added retries after 504s showed up in Cloud Logging” is something an interviewer can unpack. If you cannot remember a metric, say what broke and what you changed.

Projects that help versus projects that hurt

• Help: a repo with a README, tests, and a live URL or screenshots of a real user.
• Help: a contribution with a merged pull request you can open in the interview.
• Hurt: a tutorial clone with no README and a commit titled “final final 2.”
• Hurt: listing ten college labs as if they were products.

Interns should lead with the team's stack and one merged change. Senior engineers should show ownership: on-call, a migration, a performance fix, or a design doc. Keep GitHub in the header as a full URL so it stays clickable in the PDF.

The fifteen-second stack audit a hiring manager runs

Here's the honest version of how tech resumes get read: the screener has a team profile in their head — 'we're a React and Node shop moving some jobs to Python, need someone comfortable with SQL' — and your page gets audited against it in about fifteen seconds. What they're checking, in order: your current role's stack and whether the overlap is daily or decorative; the scale hints (users, data volume, request load — any number that lets them guess if your experience is at their level); whether you've built or only maintained (a feature with a name beats 'worked on sprints'); and whether anything is clickable that proves it. Three practical consequences follow. First, name the stack in the summary, not just in a skills dump: 'backend engineer, four years Node and Postgres, moved two services to Go' is the audit's answer sentence pre-written. Second, one scale number per job is worth five adjectives — 'served ~40K monthly users', 'a 2GB/s ingest pipeline', 'the payments table at 60M rows' — because the screener's real question is 'will my worst production incident surprise this person or bore them?' Third, if the posting's stack is 70% yours, apply; if it's 30%, the honest reframe is which of your load-bearing skills transfer ('I haven't touched your exact framework but I've owned a TypeScript monorepo with the same module-boundary problem') — and that sentence, not a keyword addition, is what gets the read.

AI on a 2026 engineering resume: what counts and what doesn't

Every tech resume now has a Claude or Copilot line, and screeners have already split the population into three groups, so know which one you're claiming. Group one: AI as an everyday tool — 'I ship with Copilot and run review on generated code; my team's merge time is unchanged because I own the diff.' This is table stakes in 2026, worth one skills line, and the honest framing is workflow, not magic. Group two: building with AI — you shipped a feature that calls a model: retrieval over a document set, a classifier, an eval you actually ran. That's real and belongs in a bullet with the same verb-object-result grammar as everything else: 'built internal search over 4 years of support tickets (pgvector + reranking); deflected 12% of repeat queries' — data, method, outcome, done. Group three: claiming model-level work you didn't do — 'experience with LLM fine-tuning' learned from a workshop. Engineers who've fine-tuned anything can smell it in one follow-up question about dataset size. The line no good resume crosses: naming AI as the author. 'I built' has to mean you built it, reviewed it, and can defend it at a whiteboard — the autocomplete era changed what 'built' costs in effort, not what it promises in understanding.

Which links to include, and the click-test before sending

Every link on an engineering resume is a promise someone will click, so the standard is brutal: include it only if the worst thing it shows is fine. GitHub: pin two or three repos with a README, and if the README is empty, the repo is a liability no matter how good the code inside is — a stranger's first impression is your commit titles, and 'final final 2' is what they'll remember. Portfolio for front-end roles: a live URL beats screenshots beats nothing; a deploy that 404s on review day is worse than admitting you haven't deployed. LinkedIn: custom URL, photo that matches reality, and the header facts synced with the resume — recruiters cross-check, and date mismatches between the two files are one of the quietest no-hire signals in the industry. LeetCode or Kaggle profiles only if the number actually flatters you; a link to a ratings chart at the 40th percentile invites exactly the judgment it's trying to avoid. Then the click-test, thirty seconds, non-optional: open the exported PDF on your phone, touch every link, watch the right app open to the right page. A LinkedIn vanity URL with an old typo, a live demo behind a crashed container, a repo you forgot was private — each one converts your initiative into evidence of carelessness, in a field where the hiring manager's next thought is 'would this person leave a broken link in production?' The links are the interview you can pre-attend; audit them harder than the bullets.

The one-page test that predicts the callback

Before you send an engineering resume, run the reading test a screener will run on yours without meaning to, because it predicts the callback better than any formatting tweak. Print it or open it at phone size, give yourself fifteen seconds, then close it and write down four things you can still remember: the person's current role, their main stack, one thing they built or shipped, and one number from anywhere on the page. If you can't fill all four from memory, that's exactly what a tired hiring manager fails to extract, and the fix is never 'add more' — it's put those four facts higher and louder. The current role and stack should be in the top third, unmissable; the shipped thing should be the first bullet of the current job, not buried third; and the number — users, requests, records, cost saved, latency cut — should be the one figure your eye can find again once the page closes. Then the sharper follow-up question, the one a real interviewer asks and a resume has to pre-answer: 'of the things on this page, which one did you personally build, and can you draw its architecture on a whiteboard?' If a bullet can't survive you sketching it from memory and explaining a tradeoff, it's a bullet you'll lose the interview on, and you should rewrite or remove it now rather than in front of them. An engineering resume is a promise about the technical conversation you're about to have; the one-page test just checks whether you can keep the promises you made on it.