Role resumes
Software engineer resume: stack in Skills, proof in Experience
Put the stack under a Skills heading Greenhouse can map. Write experience bullets as shipped work: system, users, and a change you can defend. Repeat a language only where you used it. Then check the parse before you upload to Greenhouse or a company Workday board.
Written by EnhanceCV Editorial Team·Editorial review: CPRW
Published August 27, 2026·Last updated August 27, 2026
Key takeaways
- · Languages, frameworks, and stores belong under Skills in real text — not as colored pills in a sidebar Greenhouse cannot map.
- · Bullets are shipped work: who used it, what changed, which system. A comma-separated stack in every line is noise.
- · Match the posting’s nouns you can defend: Go, Postgres, Kafka, React — not a footer of every library in node_modules.
- · Staff and senior files lead with scope (on-call, design docs, migrations). Junior files lead with a project that actually ran.
- · Export selectable text, then check the parse before Apply in Greenhouse or Workday.
Put the stack under Skills, not in every bullet
Key takeaway: Hiring managers skim for shipped systems. Greenhouse search uses language and store names. If the stack lives only in a skill cloud graphic, you are invisible.
A software engineer resume is not a dump of every library you have imported. The hiring manager is asking three questions before the first bullet: Have you shipped in this language? Have you operated a system like ours? Can we find you in Greenhouse when we search “Go Postgres Kafka”? Workday at a bank or retailer runs the same search with slightly worse parsing. If the stack sits in colored pills in a sidebar, the extract comes back without Go, and you never appear in the language filter.
Write a Skills heading in plain text. Group it: languages, frameworks, data stores, infra, practices. Example: “Go, TypeScript; Postgres, Redis; Kafka; Terraform, Kubernetes; CI in GitHub Actions.” That block is for search. Experience bullets are for proof. Repeating the entire stack in every line wastes the only space a staff engineer has to show a migration, an incident, or a design doc. One posting noun in a bullet is enough if Skills already holds the rest.
Match the title only when it is true. If the posting says “Backend Engineer” and your badge said “Software Engineer III,” you can write “Software Engineer III (Backend).” You cannot invent staff scope you did not have. GitHub and portfolio URLs belong in the contact line as text, not as icons. Workday often drops a header URL; a full https link in the body survives more often. For the writing sequence around one posting, use how to write a resume and tailor a resume to a job. This page stays on stack versus proof.
What to copy from an engineering posting — and what not to
- Copy nouns: Go, Java, TypeScript, Postgres, DynamoDB, Kafka, gRPC, Kubernetes, Terraform, Datadog, LaunchDarkly.
- Copy the shape of seniority: “own the on-call,” “write the RFC,” “migrate,” not fluffy adjectives.
- Do not paste the entire requirements paragraph. Parsers do not reward that, and a hiring manager will notice.
- Do not list a language you cannot write in a screen. Greenhouse will not save you in the pairing interview.
Give Greenhouse and Workday a layout they can map
Key takeaway: Tech Greenhouse boards and corporate Workday extracts hang name, email, employers, dates, and a skills blob. Two-column “dev portfolio” templates shuffle the stack.
Greenhouse is the default at many product companies. Workday shows up at banks, retail, and healthcare tech. Neither sees your resume the way you see it in Preview. They extract text and hang it on fields: name, email, phone, employer, title, start/end dates, education, skills. If your email lives in a header, or Go lives only in a pill graphic, the extract can come back empty. Recruiters then search “TypeScript Postgres” and you are not in the set.
Use one column. Left-aligned. Headings a parser already maps: Work Experience or Professional Experience, Education, Skills, optionally Selected projects. “Tech stack,” “What I build,” and icon rows are pretty and unmapped. Dates belong next to the company: “Mar 2022 – Present.” Contract plus client in the same block so the employment graph does not look like a gap — “Contract SWE, ThoughtWorks / Client: payments API, Go.”
Keep contact in the body. Phone, email, city/region, GitHub or LinkedIn as a full URL. Skip a photo for US Greenhouse and Workday pipelines. For visual rules, see resume format and ATS resume. For Workday field-by-field behavior, Workday resume format is the companion. Skills placement that is not engineering-specific lives in resume skills.
File type, fonts, and the GitHub line
- Upload .docx or a tagged, selectable-text PDF. A screenshot of VS Code is a brick.
- Calibri, Arial, Georgia, or the Enhance CV system font. Body 10.5–12 pt. Monospace for the whole page is harder to skim on a phone.
- One GitHub or portfolio URL in the contact line. Five badge icons in a header often vanish in Workday.
- No skill bars, no GitHub contribution graphs as images. Greenhouse does not score the green squares.
Test the file the way the ATS will. Select all. If you cannot highlight “Postgres” or the email, neither can Greenhouse. Then run the ATS checker against the posting. An ATS resume for engineering is still a systems argument — it is just an argument that still contains Go after the parse.
Rewrite weak engineering lines: three before-and-after transforms
Key takeaway: A tech dump describes the toolbox. Shipped work describes you. If a bullet could sit on any backend resume in that title, it is not finished.
Hiring managers skim for a verb, a system, and a user or scale they recognize. “Responsible for developing features” hides all three. Below are three rewrites we use in edits — backend, full-stack, and intern. Steal the pattern, not the facts. If you do not have a clean latency number, use scope: services owned, weekly deploy count, team size, regions, on-call rotation. Do not invent p99s you cannot explain at the whiteboard.
Before
Responsible for developing new features and working with stakeholders across the stack.
After
Shipped the billing CSV export in Go and Postgres used by 40 finance users; cut the month-end close query from 12 minutes to 90 seconds after adding a covering index.
Before
Worked on the frontend and the backend to improve the checkout experience.
After
Built the React checkout path for EU VAT in TypeScript; gated it with LaunchDarkly so legal could disable the flow without a deploy.
Before
Improved code quality and collaborated on various services in a fast-paced environment.
After
Split session auth out of the Rails monolith into a Go library; p95 login dropped from 800 ms to 220 ms after removing an extra Redis round trip.
Stop at three to five bullets on the current role. Older roles can take two. A two-page dump of every ticket is how a hiring manager never reaches the line that would have gotten you the screen. For line-level patterns, keep resume bullet points and resume action verbs nearby. Keyword stuffing without context is covered in resume keywords. Do not borrow clinical or classroom examples into this file.
Side projects belong under Selected projects only if they ran for someone besides you: a bot used by a club, an open-source patch that merged, a course project with a real dataset. “Todo app in React” is weaker than one intern bullet with a production deploy. Bootcamp career switchers: keep chronology and put the engineering proof first — see career change resume.
A 12-step playbook for one engineering posting
Key takeaway: Do the steps in order. Skipping to a two-column “dev” template is how people ship a pretty file that Greenhouse stores without an email.
Block two hours. Have the posting, your last resume, and a notes file of systems you actually shipped. If you want a layout parsers already understand, start in the Enhance CV builder and paste facts as you go. Write the summary last.
- Save the posting. Circle the title, five required languages or stores, infra nouns, and any seniority shape (on-call, RFC, mentorship).
- New file (do not overwrite the master). Name, city/region, phone, email, GitHub URL in the body — not in a header text box.
- Leave the 3–4 line summary blank until the bullets exist. You cannot summarize evidence you have not lined up.
- Roles in reverse chronology. Company, title, city, dates with month and year. Agency plus client in one block if you contracted.
- Under the most relevant role, draft eight messy bullets of work you shipped: migrations, incidents, features, design docs.
- Delete anything that does not help this posting. Move leftover libraries to the master file, not a keyword footer.
- Rewrite remaining bullets as verb + system + user or number. Read them out loud. If you would not say it in standup, the verb is fake.
- Skills heading from posting nouns you can defend. Group: languages, stores, infra. No star ratings, no bars.
- Education: degree, school, year. Drop GPA unless you are early career and it helps. Optional: relevant course only if you lack a second job.
- Selected projects only if they change the decision. One GitHub link in contact is enough; do not paste a README.
- Export selectable text. Open on your phone. Confirm the email is tappable and dates are readable without pinch-zoom.
- Paste resume and posting into the ATS checker. Fix contact and stack misses, then upload to Greenhouse or Workday.
People invert step 3. They write “results-oriented engineer passionate about scale” and the rest of the page is a library list. Write proof first. The summary should sound like a hiring manager repeating you to another hiring manager: title, years, domain, stack, one proof point — “Backend engineer, 6 years, Go and Postgres, billing exports for a 40-person finance team.”
If you stall on the summary, skip it and return after bullets. You can steal structure, not sentences, from professional summary examples. Do not paste someone else’s p95. Invented latency is the fastest way to lose a loop with the last tech lead.
Do this, skip that
Key takeaway: Most “tech resume” templates optimize for looking like a developer. Parsers and hiring managers optimize for stack fields and shipped proof.
Use this as a desk-side filter. If a choice is not in the table, ask: will Greenhouse store it, and will a hiring manager understand it on a phone at 07:15 before standup?
Parser-friendly vs. parser-hostile choices for engineering files
| Topic | Do | Don’t |
|---|---|---|
| Skills | Plain-text heading with languages and stores you can defend. | Colored pills, skill bars, or a footer of every npm package. |
| Bullets | Shipped work: system, users, change. | The same stack repeated in every line with no outcome. |
| Headings | Experience, Education, Skills — words an ATS already maps. | “What I build,” “Tech journey,” icons instead of words. |
| Links | One GitHub or portfolio URL in the body. | Five header icons Workday drops, or a QR code. |
| Dates | Month + year beside each role. Contract + client together. | Years only to hide a gap a one-line contract would fill. |
| File | Selectable PDF or .docx named FirstLast_Backend.pdf. | A PNG of the resume, or ResumeFinalFINAL3.pdf. |
Functional resumes that hide dates under “Languages” still show up in bootcamp advice. Greenhouse can parse a skills cloud; humans distrust it. Keep chronology. If you are switching from another field, see career change resume and still date the last employer. Gaps get a plain line — details in employment gap resume. Length for mid-career stacks is covered in resume length.
Junior, staff, bootcamp: same method, different proof first
Key takeaway: You only change which shipped proof sits in the first five lines, and how you label internships and contracts.
Junior and new grad. Lead with the internship or the project that actually ran: users, deploy, language. “Coursework: data structures” dumps are weak. “Load-tested a Go service used by a 12-person campus club” is a bullet. Pair this page with resume with no experience and student resume if you have no paid engineering role yet. Do not invent production if the app never left localhost.
Staff and senior. Lead with scope: services owned, on-call, RFCs, migrations, people you unblocked. Cut early-career bullets that scream “I still list intern projects.” Two pages are fine when the second page still has proof for this posting — not when you are afraid white space looks empty. See mid-career resume and resume length.
Bootcamp or career switch. Keep reverse chronology. Put the engineering internship or apprenticeship first, then compress the prior career to dates, employer, and one transferable line — not a full retail resume. Two files if you are still applying to the old field. LinkedIn can be broader; the Greenhouse upload cannot.
Contractors and agencies. Each engagement is a role: firm, client, stack, dates. Merging three Go contracts into “Freelance 2022–2025” hides the clients a background check will ask for and looks like a gap in Workday’s employment graph. Keep one-line older contracts if you are over two pages; do not delete the client names if you are allowed to name them.
What to do next today: pick one posting, run the 12 steps, then score the file. If the checker flags a missing email or a heading Greenhouse will not map, fix that before you add another framework. The Skills heading is the first thing to test. Then build in Enhance CV if the layout is still a two-column “dev portfolio” template.
FAQ
Where should programming languages go on a software engineer resume?
Under a Skills heading in plain text, grouped with stores and infra, so Greenhouse and Workday can map them. Repeat a language inside a bullet only where you shipped with it. A colored pill row in a sidebar is the usual reason Go never lands in the database.
Should every bullet list the full tech stack?
No. Skills holds the stack. Bullets hold shipped work. Repeating “React, Node, Postgres, Docker, AWS” on every line crowds out the only fact a hiring manager will ask about in the screen. One noun per bullet is enough if Skills is complete.
Is a GitHub link enough instead of project bullets?
A URL in the contact line helps a human. It does not replace Experience. Greenhouse search does not crawl your repos. Put the shipped work in text. One selected project is useful when you lack a second job; five README pastes are not.
Can you use a two-column developer template in Greenhouse?
You can upload one. You should not rely on it. Greenhouse and Workday often read columns top-to-bottom in unexpected order, which is how emails and Skills vanish. A single column with a Skills heading is the reliable choice; save decorative layouts for a portfolio site.
How long should a software engineer resume be?
One page is enough for most people with under about eight years of relevant work. Two pages are fine when the second page still has proof for this job — migrations, on-call, systems — not a library dump. Hiring managers rarely finish a padded two-pager on a phone. See resume length.
How do contractors list multiple clients?
One block per engagement: firm, client if you can name it, title, stack in Skills, dates with months. You can shorten older contracts to one line. A single “Freelance Engineer” blob with no clients looks like a gap and slows a background check.
Do you need an objective on an engineering resume in 2026?
Almost never if you already have shipped work. A three-line summary that states title, domain, stack, and one proof point does the same job with less fluff. Use an objective only when you are changing fields and must explain the pivot in one sentence.
How do you check an engineering resume before applying in Greenhouse?
Select-all in the PDF. If languages and email do not highlight, fix the file. Then run the Enhance CV ATS checker against the posting for contact, dates, Skills heading, and stack gaps. Fix those, then upload. Do not wait for a silent board to tell you Postgres never parsed.
Write the next draft in a layout parsers already understand
Open the Enhance CV builder, keep your stack and shipped facts, and tighten lines that still read like a job description. Then score the file against the posting.