Resumes for Technology Roles: What the Sector Screens For

The two readers

A technology application is normally screened by someone who does not do the job, and then read by someone who does. The recruiter is checking a short list of concrete things — the stack, roughly how many years, whether you are near the location or a time zone that works, whether the visa situation is workable. The engineering manager reading it afterwards has a completely different question: how big were the things this person was actually responsible for?

These two readers reward opposite instincts. The first rewards completeness and literal wording. The second rewards restraint and evidence. Most weak technology resumes are written entirely for one of them — either a wall of technology names with no story, or an elegantly written page that never says which database it was.

• Write the skills section for the first reader. Exact, conventional strings: "PostgreSQL", "Kubernetes", "Terraform", "React", "Power BI". Not "modern JS tooling", not "cloud infrastructure".
• Write the experience bullets for the second. Traffic, data volume, uptime, team size, incident counts, cost, latency, release cadence. Numbers a peer can use to place you.
• Let the two agree. If Kafka is in your skills list and appears nowhere in your history, an interviewer will assume you read the tutorial. Anything worth listing should be traceable to a job, a project or a course.

Levelling: the thing nobody tells you is happening

Most technology employers of any size run a levelling ladder — junior, mid, senior, staff and upward, or their internal equivalent. The level you are interviewed at is usually decided from your resume, before anyone speaks to you, and it is very hard to move upward once the loop has been scheduled at a particular band. Salary follows the level far more than it follows negotiation.

Levels are defined by scope rather than tenure. Roughly, and with a great deal of variation between employers:

Executing

You were given well-defined work and delivered it. Evidence: features shipped, tickets closed, tests written, dashboards built.

Owning

You held a component or service end to end, including its failures. Evidence: on-call ownership, design decisions you made, something you were the person for.

Influencing

Your work changed how other people worked. Evidence: a migration you led, a standard you set, engineers you mentored, a decision document that others followed.

Write bullets that make the highest band you genuinely occupied unmistakable. "Built the payments integration" is executing. "Owned the payments service, including on-call, and led the migration off the legacy provider across four teams" is influencing — and the second one is not a longer way of saying the first, it is a different job.

Why "5 years of Python" screening is not really about Python

Years-of-experience filters are a proxy, and everyone involved knows they are a crude one. They exist because scope is hard to read quickly and tenure is easy. This is why an applicant with four years of genuinely senior scope frequently clears a five-year filter and one with eight years of narrowly-defined ticket work frequently does not — the human reader at the other end is correcting for the proxy. Give them the material to correct with.

Sub-sectors that behave differently

Technology is not one hiring market. The document that works for a product engineering role at a software company is not the one that works for an IT operations role at a hospital, and the differences are structural rather than stylistic.

Each of those has role-level detail worth reading on its own page — the software engineer, data analyst, DevOps engineer, cybersecurity analyst, IT support specialist and product manager examples each show what a finished document looks like in that lane.

Rewrites that move a technology bullet up a level

The things technology resumes get wrong as a class

• A link with nothing behind it. A GitHub URL that leads to three forked repositories and no commits in two years is worse than no link. Link it when there is something to see; otherwise use the space.
• Version numbers as padding. "Java 8, Java 11, Java 17" is one skill written three times, and the reader notices.
• Certifications with no dates. Cloud and security certifications expire and recertify on cycles; an undated one invites the assumption that it lapsed. Name the issuer and the year in full — for example the vendor-neutral CompTIA certifications, or the cloud providers' own programmes.
• Tutorial projects presented as work. A to-do app and a weather dashboard are recognised on sight. One project with real users, real data or a real constraint outweighs five.
• Hiding the scale of unglamorous work. Keeping a 3,000-seat estate patched is a serious job. Support and operations candidates undersell it more than any other group in the sector.

A short sector checklist

• The exact technology names from the posting appear on the page, spelled as the posting spells them.
• Every job has at least one number: users, requests, records, incidents, cost or time.
• Your highest genuine level of ownership is visible in the first third of the page.
• Nothing in the skills list is absent from the work history without an explanation.
• Links go somewhere worth going, or are removed.
• Certifications carry an issuer and a date.
• The document is one page under about ten years of experience, two beyond it.

When the page is drafted, run it against the exact posting with the ATS checker to catch the literal terms you paraphrased, and see quantifying achievements for how to find numbers in work that felt unmeasurable. Purdue's Online Writing Lab is a good non-commercial reference for the underlying conventions if you want a second view.