Software Engineer Resume Example and Section-by-Section Guide

The full sample resume

This is a one-page resume for a backend-leaning engineer applying to product companies. The person and companies are fictional; the structure and level of detail are what to copy.

Header and summary

The line under the name is a headline: a role title plus a specialisation. “Software Engineer — Backend and Distributed Systems” tells a recruiter in two seconds which pile you belong in. Avoid stacking titles like “Full Stack Developer | DevOps | ML Enthusiast”; it reads as unfocused.

The summary does three jobs in three sentences: years and core stack, two or three proof points with scale, and what you want next. That last part is optional but useful — it lets a recruiter route you quickly. Notice what isn’t there: “passionate”, “team player”, “quick learner”. Those words take space and prove nothing.

Skills: group them, and keep them honest

A flat list of twenty-five technologies is hard to scan and invites suspicion. Grouping by category — languages, backend and data, cloud and infrastructure, practices — lets a reader find what they’re looking for and shows you understand how the pieces fit together.

• Put the technologies the job description asks for first within each group.
• Only list what you could discuss in an interview. A good test: could you answer “tell me about a problem you solved with this”? If not, leave it off or mark it as “working knowledge”.
• Skip skill bars, star ratings and percentages. “Java 80%” means nothing and invites the question “what’s the missing 20%?”
• Leave out things every engineer is assumed to know, like Git, VS Code, Windows or MS Office, unless the posting specifically mentions them.
• Make sure the important skills also appear in your experience bullets. A skill that only appears in the list is a claim; a skill used in a bullet is evidence.

Experience bullets: impact, scale and how

This is where most engineering resumes fall short. The common failure is describing duties (“worked on microservices”) rather than outcomes. A strong bullet answers: what did you build or change, how, and what was different afterwards? Scale — requests, users, data volume, number of services, latency — gives a technical reader a sense of the problems you’ve handled.

If you don’t have exact numbers, use honest approximations (“around”, “roughly”, “400+”) or describe the change qualitatively — “replaced a manual weekly process”, “removed the need for a nightly batch job”. Never invent a percentage. Engineers who interview you will ask how you measured it.

Projects, GitHub and portfolio links

For experienced engineers, a projects section is optional and should only include work that adds something your job history doesn’t — open-source contributions, a tool other people use, or work in a technology you’re moving into. For freshers it’s often the most important section on the page.

• Describe a project like a job: what it does, what you built it with, and any evidence it’s real — users, stars, a deployment, a write-up.
• Link directly to the repository or live demo, not just your profile, so a reviewer lands on the right thing.
• Before you link your GitHub, check what someone sees in the first ten seconds: pinned repositories with clear READMEs, not a wall of forked tutorials and empty repos.
• A README with a short description, a screenshot or architecture sketch, and setup instructions does more for you than a long resume bullet.
• Only link a portfolio site if it loads quickly and is current. A broken link is worse than none.

Education

Once you have a couple of years’ experience, education shrinks to one line: degree, institution, year, and grade if it’s strong. In India, CGPA is commonly listed and some employers filter on it, so include it if it’s at or above the cut-offs that typically appear in postings you’re targeting; otherwise, leaving it off is acceptable for experienced roles. Class 10 and 12 marks are relevant mainly for freshers and campus placements, and can go once you have a full-time role behind you.

Certifications such as cloud provider associate or professional certifications can sit under education or in their own short section. They help most when they match the stack in the posting and you’re early in your career or switching specialisation.

Adjusting the example for your level

The same structure works across levels, but the weight shifts.

• Freshers and new graduates: put Education right after the summary, with CGPA, relevant coursework and any campus placement or internship. Projects come next and should be the strongest part of the page — two or three solid ones beat six small ones. Include internships with the same bullet style as full-time jobs. Competitive programming ratings or hackathon results are worth a line if they’re notable.
• Senior and staff engineers: lead with scope and influence, not just output. Bullets should show technical direction (“defined the event schema standard adopted across 5 teams”), cross-team work, reliability and cost outcomes, and people you developed. Drop or shorten roles older than about ten years. Two pages is reasonable at this level if the content earns it.
• Career switchers: open with a summary that names the target role and bridges from your previous field — for example, a QA engineer moving into development, or an analyst moving into data engineering. Put projects above experience if they’re more relevant, and rewrite past-role bullets to emphasise the technical parts: automation you wrote, scripts, SQL, tooling. Don’t hide the previous career; domain knowledge from finance, healthcare or logistics is a genuine advantage in those industries.

Formatting choices that matter for engineering roles

• One page for up to roughly five to seven years’ experience; two pages after that if needed.
• Single-column layouts parse most reliably in applicant tracking systems. Avoid putting key information in images, icons or text boxes.
• Write technology names the standard way: PostgreSQL, JavaScript, Node.js, Kubernetes. Misspelt tool names look careless to an engineering reader.
• Use consistent date formats and right-align them or keep them on the title line.
• Send a PDF unless the employer asks otherwise, and name it sensibly, such as Arjun-Mehta-Software-Engineer.pdf.

In Indian hiring, add your notice period somewhere visible — the summary or a line in the header — if it’s 30 days or less, because recruiters often screen on it before reading anything else. Current and expected CTC usually belong in the portal fields or the recruiter conversation rather than on the resume.

Frequently asked questions