A job posting titled "programmer" is telling you something before you read a single requirement. Companies that hire "software engineers" tend to be product and tech firms with a stack-first screening process. Companies that hire "programmers" are more often banks, insurers, government agencies, manufacturers, and mid-size businesses where the software team sits inside a larger operation. That difference changes what your resume needs to prove.

Specialized postings, a Java developer role or a front end role, screen almost entirely on hard skills: the stack, the frameworks, the years. General programmer postings ask for the hard skills too, but they lean noticeably harder on the other half: communicating with non-technical stakeholders, translating business requirements into working code, documenting your work, and maintaining systems other people built. When Roleframe's job-analysis engine reads generalist programmer postings against specialized developer postings, that split is one of the most consistent patterns: the generalist role expects you to be legible to people who do not code.

This guide walks through a complete programmer resume example, then breaks down every section: structure that parses cleanly in an applicant tracking system (ATS), a summary that survives a skim, experience bullets with real numbers, the languages employers actually filter for, and how to handle projects, education, and certifications.

Strip away the templates and every strong programmer resume makes the same four arguments, in roughly this order:

• You can build and maintain software in the languages they use. Named languages, named frameworks, named databases. Not "proficient in various programming languages."
• Your code had consequences. Faster processes, fewer errors, money saved, hours reclaimed. A bullet that ends at "developed an internal application" is half a bullet.
• You work inside a business, not beside one. Requirements gathering, stakeholder communication, documentation, supporting legacy systems. This is where generalist programmer roles differ most from pure engineering roles, and where most programmer resumes are thinnest.
• You keep learning. A recent certification, a personal project in a newer stack, a migration you drove. Programming roles at non-tech companies often involve older systems, and employers worry about hiring someone whose skills stopped in 2015.

The example below hits all four. Read it before the section-by-section breakdown, because everything after refers back to it.

Before a recruiter sees your resume, an ATS usually parses it into structured fields. If the parse fails, your carefully chosen keywords never make it into the database the recruiter searches. The fixes are boring and they work:

• Single-column layout for the core content. Multi-column designs can scramble the reading order in older parsers. If you want visual structure, keep contact details and skills in a narrow sidebar and your experience full-width.
• Standard section headings. "Experience," "Skills," "Education," "Projects," "Certifications." A heading like "Where I've Shipped Code" reads as personality to you and as an unparseable section to the software.
• Reverse-chronological experience with job title, company, and dates on predictable lines. Parsers key on that pattern.
• Real text, not graphics. Skill bars, icons, and text embedded in images are invisible to a parser. If a skill matters, it needs to exist as selectable text.
• Save and submit as PDF. A text-based PDF preserves your formatting on every machine and parses reliably in modern systems. Only send another format if a specific employer explicitly asks for it.

For the full checklist, including how to test whether your resume actually parses, see the guide to making your resume ATS-friendly without ugly design.

On length: one page up to roughly five or six years of experience, two pages after that. A senior programmer with fifteen years does not need to compress three major systems into one page, and a junior does not need to inflate two internships across two. The one page vs. two breakdown covers the edge cases.

The summary exists for the recruiter's first pass, the skim that decides whether your resume gets a real read. It has one job: state who you are, what stack you work in, and one outcome that proves you are good at it. Three sentences, maximum four lines.

A weak programmer summary lists adjectives: "Detail-oriented, passionate programmer with strong problem-solving skills." None of that is checkable, so none of it registers. A strong one lists facts:

• Weak: "Experienced programmer seeking a challenging role where I can apply my skills in software development."
• Strong: "Programmer with 5 years building and maintaining .NET and SQL Server applications for insurance operations. Automated claims-intake workflows that cut manual processing time by more than half and reduced data-entry errors across three departments."

The strong version front-loads the exact terms a recruiter searches for (the stack, the domain) and anchors them to an outcome. Notice it also signals the generalist strength: "across three departments" says you work with people outside the dev team without ever writing "strong communication skills."

If you have under two years of experience, a short objective naming your stack and target role can replace the summary. Everyone else should summarize what they have done, not what they want. More patterns and worked examples in the guide to writing a professional summary.

The experience section is where programmer resumes go generic. "Developed and maintained applications using C# and SQL" describes tens of thousands of people. The fix is a simple formula: what you built, in what, and what changed because of it.

• Before: "Wrote scripts to automate reporting tasks."
• After: "Built Python scripts that automated monthly financial reporting, cutting a 3-day manual process to under 2 hours and eliminating reconciliation errors."
• Before: "Maintained legacy inventory system."
• After: "Maintained and extended a legacy VB.NET inventory system used by 40+ warehouse staff, resolving an average of 15 support tickets per week while migrating core modules to .NET 8."

You do not need revenue numbers to quantify. Programmers have metrics everywhere: processing time before and after, error rates, ticket volume, number of users, records handled, uptime, build times, release frequency. If you genuinely cannot measure an outcome, quantify the scope instead: how many systems, how many integrations, how many people relied on it.

Two structural rules. First, lead each role with your biggest outcome, not your daily duties; the first bullet is the only one guaranteed to be read. Second, keep it to three to six bullets per role, weighted toward recent jobs. The bullet count guide has the breakdown by experience level.

One more thing generalist programmer postings reward: at least one bullet per recent role that shows the soft-skill half of the job. "Gathered requirements from the underwriting team and translated them into technical specifications" or "Wrote onboarding documentation that cut new-developer ramp-up time." On a specialized developer resume that bullet is optional. On a programmer resume it is load-bearing, because the posting almost certainly asked for it.

Generalist programmer postings cluster around the enterprise stack: Java and C# dominate, SQL appears in nearly every posting because business programming is database programming, and Python shows up constantly for automation and data work. JavaScript appears wherever the role touches internal web tools. Older postings, especially in finance, insurance, and government, still ask for COBOL, VB.NET, or Delphi, and candidates who can maintain those systems while modernizing them are scarce enough to command attention.

Organize your skills section into labeled groups rather than one long comma soup. It reads faster for humans and parses cleaner for machines:

Match the posting's exact vocabulary. If it says "MS SQL Server" and your resume says "relational databases," a keyword filter scores that as a miss even though you are qualified. This is the single most common gap on otherwise strong programmer resumes, and it is checkable: duplicate your resume for a specific job in Roleframe and the fit report lists the exact keywords the posting asks for, which ones your resume already covers, and which are missing, so you edit against a named list instead of guessing.

Do not pad the list. Ten skills you can defend beat twenty-five you dabbled in, because every listed skill is a fair interview question. And skip self-ratings like "Python (expert)." Your experience bullets are the rating. For the wider principle of balancing this section, see hard skills vs. soft skills on your resume.

List them separately, and only list the ones you can actually work in. C and C++ are different languages with different idioms, and interviewers know it; writing "C/C++" when you have only written C signals either carelessness or padding. If a posting asks for one and you know both, list both as separate entries. If you have not touched either in years, leave them off rather than inviting a pointer-arithmetic question you will fumble.

Projects earn their space in two situations: you have under three years of experience and need proof of ability, or your day job is in an older stack and a project demonstrates the modern skills a posting asks for. A senior programmer with a decade of shipped systems does not need a to-do app on page two.

Treat each project like a mini job entry: a name, the stack in parentheses, and one or two outcome-focused bullets. "Built a REST API in Python/FastAPI that aggregates local event data; deployed on a VPS with automated CI, serving 200+ weekly users" tells a hiring manager you can design, ship, and operate software. "Made a website with HTML and CSS" tells them nothing a bootcamp certificate did not already say.

Three rules that separate credible projects from filler. Only include projects with real, browsable code; a pinned, readable repository beats a paragraph of description. Prefer finished and deployed over ambitious and abandoned. And skip unmodified tutorial builds, because recruiters have seen that exact weather app hundreds of times. The full playbook is in how to list coding projects on a resume, and if you are linking a profile, put it in your header the way the GitHub link guide describes: a clean text URL, not an icon a parser will drop.

Programming is one of the fields where employers genuinely accept multiple paths in: a computer science degree, an unrelated degree plus a bootcamp, or fully self-taught with a strong project record. Your job is to present whichever path you took cleanly, then let your work carry the weight.

• Degree holders: institution, degree, graduation year. Include your GPA only if it is strong and you graduated recently; the GPA guide covers the cutoffs. After a few years of experience, education drops below experience and shrinks to two lines.
• Bootcamp graduates: list the bootcamp in education with the stack you trained in, and let your projects section do the proving. There is a specific format that avoids the common credibility traps in how to put a coding bootcamp on your resume.
• Self-taught: skip apologetic framing entirely. A projects section with deployed work and a skills section you can defend is your education section.

Certifications matter more in generalist programmer hiring than in startup engineering, because non-tech employers use them as a proxy when nobody on the hiring panel can evaluate code. The ones that reliably move the needle map to the enterprise stack: Microsoft's Azure certifications for .NET shops, AWS certifications where the posting mentions cloud, Oracle's Java certification for Java-heavy environments. A Scrum or Agile credential occasionally appears as a requirement in postings where the programmer sits inside a formal delivery process. If a posting names a certification you hold, move it near the top of the resume; placement rules are in where to put certifications on a resume.

"Programmer" postings vary more than specialized ones. One wants a .NET maintainer, the next wants a Python automator, the third wants someone to babysit a COBOL core while building its replacement. Sending the same resume to all three means being a partial match for each.

The workable system is a master resume plus tailored versions: keep one complete document with everything you have done, then produce a trimmed, reordered version per application that leads with what that posting asks for. The mechanics are covered in why you need a base resume and tailored versions. In Roleframe this is the core workflow: your base programmer resume lives in a role workspace, each job spins off its own version with a fit report naming the gaps, and Remi, the career copilot, helps you rewrite individual bullets to close them, with you approving every change. Nobody writes your resume for you, which matters, because you will be asked about every line of it in the interview.

If you already have a programmer resume, do not retype it to apply any of this. Roleframe imports an existing resume as a PDF and converts it into editable blocks, with your roles, dates, and bullets landing in the right places. The import runs a full resume analysis on its own, so the first thing you see is a scored document with its weak sections named, not a blank canvas.

From there the edits in this guide take minutes instead of an evening: drag your skills section above experience if you are pivoting stacks, rewrite the vague bullets with quantified ones, and export a clean PDF that matches the editor exactly. The editor itself is free to use with no account, and the free PDF download has no watermark.