A tech resume is read twice: first by a recruiter who skims it in well under a minute looking for a reason to pass it on, then by a hiring manager who reads the parts that match the job more carefully. Write for both readers. Put the evidence that you can do this specific job where a skimmer will see it, and make every bullet specific enough that an engineer believes it.

This guide covers how that reading happens, what applicant tracking systems do and do not do, how to structure the page, how to write bullets, and what to cut.

How a resume is actually read

The first reader is usually a recruiter or a sourcer handling many open roles. They are not evaluating your code. They are matching: does the title, recent experience, tech stack and level line up with the job description and the notes the hiring manager gave them? They look at your most recent role, your job titles, the dates, the skills line and maybe the first bullet or two under each job.

That means the top third of the page does most of the work. If your most recent role is relevant, it carries you. If it is not (say you are moving from support into development), the top of the page needs to show the bridge: a short summary line, a relevant project, or a skills section that matches the posting.

The second reader is the hiring manager or an engineer on the team. They read more slowly and more skeptically. They are asking what you personally built, how hard it was, and whether the claims hold up. Vague bullets fail here even if they passed the recruiter. Bullets that name the system, the scale and your part in it pass.

What applicant tracking systems really do

An applicant tracking system (ATS) is mostly a database and workflow tool. It stores applications, tracks which stage each candidate is in, schedules interviews and lets recruiters search and filter. Most of the rejection people blame on "the ATS" is really a human using it: a recruiter filtering by a knockout question (work authorization, location, years of experience), searching for a keyword, or simply reviewing the newest applications first.

A few practical points follow from that:

  • Parsing matters a little. Most systems try to pull your name, contact details, job titles and dates into fields. Unusual layouts (text in images, multi-column designs, headers and footers holding key information, tables for the whole layout) can come out garbled. A single-column layout with standard section headings parses cleanly everywhere.
  • Keywords matter because humans search. If the job asks for Kubernetes and you have used it, write "Kubernetes," not just "container orchestration." Use the same names the posting uses where they are accurate.
  • Keyword stuffing does not help. Hidden white text and pasted job descriptions get noticed by the person reading the result, and that person decides.
  • Format. Submit a PDF unless the application asks for something else. Name it sensibly, such as firstname-lastname-resume.pdf.

You will see alarming percentages quoted about resumes "auto-rejected by robots." We have not found a sound public source for them, so we do not repeat them. Write a clear document with accurate terms and you have handled the ATS.

A structure that works

For most people in software, IT and data roles, this order works:

  1. Header. Name, city and state (or "Remote, US"), email, phone, and one or two links. No photo, no full street address.
  2. Summary (optional, two lines). Useful when you are changing direction or your title undersells you. Skip it if it would just say "passionate engineer."
  3. Skills. One compact block grouped by type: languages, frameworks, infrastructure, data, tools. List what you could discuss in an interview, not everything you have touched once.
  4. Experience. Reverse chronological. Company, title, dates (month and year), then three to six bullets for recent roles, fewer for older ones.
  5. Projects. Essential for new graduates and career changers, optional for experienced engineers unless a project is more relevant than your job.
  6. Education and certifications. Degree, school, year. Certifications that matter for the role (see our certifications hub). Experienced candidates put this at the bottom; new graduates can put it near the top.

The bullet formula

A good bullet answers three questions: what did you do, how, and what changed because of it. A useful pattern is:

Action verb + what you built or changed + the tech or method + the result (with a number if you have an honest one).

The examples below are illustrative, written for this guide, not taken from real resumes.

Backend developer

  • Before: "Responsible for working on the payments API."
  • After: "Rebuilt the payment retry logic in our Go payments API, adding idempotency keys and a dead-letter queue; duplicate charges reported to support dropped from several a week to none over the following quarter."

IT support specialist

  • Before: "Helped users with computer problems."
  • After: "Resolved about 25 tickets a day across Windows, macOS and Microsoft 365; wrote 30 knowledge base articles that let the team close password and VPN tickets at first contact."

Data analyst moving into data science

  • Before: "Used Python for data analysis."
  • After: "Built a churn model in Python (pandas, scikit-learn) from three years of subscription data; the retention team used its weekly risk list to prioritize outreach calls."

Systems administrator

  • Before: "Managed servers."
  • After: "Automated patching for 140 Linux servers with Ansible, replacing a manual monthly process that took two engineers most of a weekend."

Notice what the "after" versions do. They name the system. They say what you did, not what the team did. They give a scale (25 tickets a day, 140 servers) that a reader can calibrate against. And the result is something a business cares about: fewer duplicate charges, faster ticket resolution, less weekend work.

On numbers: use them when you know them or can reasonably estimate them, and be ready to explain how you got them. "Improved performance by 300%" with no context invites a hard follow-up question in the interview. "Cut p95 page load from about 4 seconds to under 1.5 seconds by moving image resizing to a CDN" survives one.

If you genuinely have no metric, describe scope and consequence instead: who used it, how often, what it replaced.

What to cut

Most resumes get better by removing things.

  • Objective statements. "Seeking a challenging role where I can grow" tells the reader nothing.
  • Soft-skill lists. "Team player, excellent communicator" are claims without evidence. Show them in bullets ("ran the weekly incident review").
  • Skill ratings. Bars or stars for Python proficiency mean nothing to a reader and invite questions.
  • Every technology you have heard of. If you list it, expect to be asked about it.
  • Old, irrelevant jobs in detail. A retail job from ten years ago can be one line or gone. A recent non-tech job can stay as a line if it explains a gap or shows responsibility.
  • Duties copied from the job description. "Maintained servers" is a duty. Bullets should be accomplishments.
  • References available upon request. Assumed.
  • Personal details such as age, marital status or a photo. In the US they are not expected and some employers prefer not to receive them.

One page or two

Use one page if you have under roughly eight to ten years of relevant experience, or if you are a student or changing careers. Two pages is fine for senior engineers, architects and managers whose recent work genuinely needs the space. Three pages is almost always too long for a US industry job (academic CVs for research roles such as computer research scientist follow different norms).

The test is not page count but density. If the second page is mostly older roles described in the same detail as your current one, compress it.

Links help only if they lead somewhere that supports your case.

  • GitHub. Worth including if a reviewer can find one or two repositories that show real work within a minute: a clear README, sensible structure, some tests. Pin those repositories. A profile full of forked tutorials and empty repos does not help, and it is fine to leave GitHub off if your best work is private company code.
  • Portfolio. Close to mandatory for web developers and anyone doing front-end or design-adjacent work. Show live projects that load quickly and work on mobile.
  • LinkedIn. Recruiters will look you up anyway. Make sure the titles and dates match your resume, because mismatches look careless at best.
  • Writing. A technical blog post or conference talk is a strong signal for senior roles and for technical writers. Link one good piece rather than the whole archive.

Use full, readable URLs (github.com/yourname), because some readers print resumes or view them in tools where hyperlinks do not work.

Tailoring without rewriting from scratch

Keep a master resume with every bullet you might use, then cut a version for each type of role you apply to. For most people that means two or three variants, not one per application. A software developer applying to both backend and platform roles might keep one version that leads with API work and one that leads with infrastructure.

For each application, spend ten minutes on these steps:

  1. Read the posting and note the three or four requirements that appear first or most often.
  2. Make sure those terms appear in your skills block and in at least one bullet each, if they are true for you.
  3. Reorder bullets so the most relevant ones sit first under each role.
  4. Adjust the summary line, if you use one, to name the role you are applying for.

Do not claim experience you lack. Interviewers check the resume line by line, and a single invented item undermines everything else on the page.

Before you send it

Read it once as a recruiter: cover everything except the top third and ask whether it matches the job title you are applying for. Then read it as an engineer: for each bullet, ask "what exactly did this person do?" If the answer is unclear, rewrite the bullet. Finally, export to PDF, open the PDF, and copy and paste the text into a plain text editor. If it comes out in the right order with your name, titles and dates intact, any ATS will read it too.