A tech resume is judged on scope, not on the length of your stack list.
Almost every technology resume contains the same skills section, and almost none of them explain what the person actually owned. Engineers list frameworks; hiring managers are trying to work out whether you shipped something to real users, how much of it was yours, and what broke. The keyword filter is real and worth clearing — but it is the easy half. The half that decides the interview is whether a senior person reading for six seconds can tell what you are responsible for.
- Roles covered
- 10 guides
- Screened on
- Scope + evidence
- Typical length
- 1–2 pages
- Links
- As plain text URLs
Reflects general practice in the US and EU tech market as reviewed in 2026. Norms vary sharply by company size — startups read for ownership, large firms read for level calibration.
Ownership is the signal; the stack is just the filter
Two candidates write 'React, TypeScript, Node, Postgres'. One adds: 'owned the checkout rewrite end to end — 40k daily sessions, cut p95 latency from 1.9s to 620ms, ran the rollout behind a flag'. Only one of them has said anything. Scope is the variable that separates otherwise identical tech resumes: how many users, whose decision it was, what you were on the hook for when it failed. Write the stack so the filter matches you, then spend the rest of the line proving what you owned.
What every technology resume has to prove
The size of the thing you worked on
Users, requests, records, revenue, team size — any one of them calibrates you instantly. 'Built an internal dashboard' could be a weekend or a year. 'Built the internal dashboard 200 support agents use daily' cannot be misread.
What was yours versus the team's
Inflation is assumed, so precision reads as credibility. 'One of four engineers; I owned the payments integration and the reconciliation job' is stronger than 'led development of the payments platform' — and it survives the interview, which the inflated version does not.
A result the business would recognise
Latency, uptime, error rate, conversion, cost, time saved. Engineering results that are only legible to engineers still work, but the ones tied to money or user behaviour travel further, because the recruiter forwarding your resume is not an engineer.
Evidence someone can open
GitHub, a live URL, a case study, a published package. One working link outperforms an entire projects section. Write links as plain visible text — a URL hidden behind anchor text can be lost when the file is parsed, which is a self-inflicted wound.
Technology resume examples by role
Each guide has a full annotated example, summaries by seniority and the keywords that role is filtered on.
Software Engineer
Software engineer resume examples that pass the robots.
See the exampleWeb Developer
Web developer resume examples with links recruiters can actually click.
See the exampleDevOps Engineer
DevOps resume examples that show what the pipeline did, not what was installed on it.
See the exampleQA Engineer
QA engineer resume examples that show judgement, not a tool inventory.
See the exampleCybersecurity Analyst
Security resume examples that show judgement, not a certification stack.
See the exampleData Scientist
Data scientist resume examples that prove impact, not tool lists.
See the exampleData Analyst
Data analyst resume examples that prove impact, not tool lists.
See the exampleBusiness Analyst
Business analyst resume examples that show the decision, not the document.
See the exampleUX Designer
UX designer resume examples whose only job is to get the portfolio opened.
See the exampleProduct Manager
Product manager resume examples that show outcomes, not features.
See the example
Bullets that get read, and the ones that do not
Same experience, rewritten. The difference is always the same thing: something a reader can check.
Worked on the company's main web application using React and TypeScript.
Rebuilt the account settings area of a React/TypeScript app used by 90k monthly users; cut the support tickets tagged 'can't change plan' by roughly two thirds over the following quarter.
Why: Same stack, but now there is a surface, a scale and a consequence. The hedge on the number is deliberate — it keeps the claim defensible in the interview.
Improved application performance.
Traced a p95 regression to N+1 queries in the orders endpoint; added batching and an index, taking p95 from 1.9s to 620ms.
Why: Names the method, not just the outcome. Interviewers ask 'how' — a bullet that already answers it gets you a better conversation.
Responsible for data analysis and reporting.
Owned the weekly retention model in SQL and dbt; found that the 30-day drop was concentrated in one onboarding step, which the product team then rebuilt.
Why: Analysts are hired for the decisions their work caused. A finding that changed something beats a description of the tooling.
Led the migration to microservices.
Split the billing module out of the monolith with two other engineers — I designed the event contract and ran the dual-write cutover; no customer-visible downtime across the switch.
Why: 'Led' with no team size is the most-discounted word in tech resumes. Naming your specific piece makes the claim believable.
Keywords that recur across technology postings
Function-wide terms, not role-specific ones. Mirror them verbatim when the posting uses them — filters match strings, not meaning.
| Keyword | Priority |
|---|---|
| CI/CD | High |
| REST APIs | High |
| Git / version control | High |
| SQL | High |
| Cloud (AWS / GCP / Azure) | High |
| Agile / Scrum | High |
| Code review | High |
| Testing (unit, integration) | High |
| Docker | Medium |
| Kubernetes | Medium |
| Observability / monitoring | Medium |
| Cross-functional collaboration | Medium |
| A/B testing | Medium |
| Technical documentation | Medium |
How the resume changes as you move up
Junior / first role
Projects carry the page when jobs cannot. Two or three real ones with live links, written as work rather than coursework: the problem, your part, the stack, what it does now. Skip the tutorial clones — every screener has seen them.
Mid-level
The stack section shrinks and the scope grows. Show that you own features end to end, that you handle production, and that you have opinions you can defend about testing and rollout.
Senior
Design decisions, trade-offs and blast radius. Mentoring and code review count here. The strongest senior resumes read as a list of judgement calls, not a list of technologies.
Staff, lead and engineering management
Influence beyond your own commits: architecture across teams, hiring, incident command, platform work others build on. Managers should show headcount, retention and delivery — and keep one recent technical thread visible.
How these resumes actually get filtered
Most tech applications meet a keyword filter first, then a recruiter who is not technical, then the hiring manager. The filter matches literal tokens, which is why the exact spelling in the posting matters — 'Node.js' and 'NodeJS' are not the same string. The non-technical recruiter is scanning for company names, titles, dates and the technologies from the requisition. Only the third reader cares about your architecture decisions. A resume has to survive all three, and the usual failure is a document written entirely for the third one.
See what four real ATS parsers did with 36 resume layoutsMistakes specific to technology resumes
A skills section listing 40 technologies, half of them tried once.
Group by depth — 'daily', 'working knowledge', 'familiar'. Anything you cannot survive fifteen minutes of questions about does not belong.
Rating yourself with star bars or percentages.
Nobody agrees on what 4/5 in Python means, and the graphic carries no text for a parser to read. Delete it and let the experience section imply the level.
Describing team achievements in the first person plural.
'We shipped' tells the reader nothing about you. Name your piece — it is both more honest and more persuasive.
Linking GitHub as a clickable icon with no visible URL.
Write the address as text. When your resume is parsed, an icon's underlying link is one of the first things to disappear.
Assuming a designed, two-column layout will be read correctly.
Some are, some are not — it depends on the parser, and we published the per-template data. Pick a layout that has been tested rather than one that merely looks tidy.
Templates that suit technology resumes
Technology resume FAQ
How long should a software engineer resume be?
One page up to about five years, two after that. Beyond two pages you are asking a hiring manager to do work on your behalf, and they will not — they will read the top third and decide.
Do I need a portfolio or GitHub link?
For frontend, design and early-career roles it is close to mandatory. For backend and infrastructure it helps but is not expected. One link that opens and shows something real beats five that are empty or broken — a dormant GitHub is worse than none.
Should I tailor my resume to every job posting?
Tailor the top third and the skills section — that is where the match is decided. Rewriting the whole document per application is a poor use of time. Mirror the posting's own vocabulary for the tools you genuinely use.
Are two-column resumes safe for engineering roles?
It depends on the parser, not on the number of columns. We put the same resume through four production systems in 36 layouts: the thing that breaks parsing is the order text lands in the PDF's text stream. Several two-column templates came through perfectly.
Should I include personal projects if I already have a job?
Only if they are recent, live and relevant, and only after the professional experience. A senior engineer's side project rarely adds anything the day job hasn't already proved — and stale ones raise questions instead of answering them.
Other job functions
Build it on a template that has been through a real parser.
Unwatermarked PDF export, no subscription, and a score against any posting when you want one.
Build my resume