
A tech resume that gets interviews is usually one page, single column, and built from bullets that say what you shipped or changed, how you did it, and what happened next, with numbers. It uses the exact names of the tools in the posting where they're true, links to work a reader can check, and gets tailored to each role rather than sprayed.
Definition: A tech resume is a one or two page summary of your work, written for software companies and technical teams, that a recruiter or hiring manager can parse in seconds and an applicant tracking system can store and search.
None of this is secret. The hard part is volume, so that's where we start. If you're aiming at venture firms rather than tech companies, the venture capital resume guide covers that reader instead.
What a tech resume is up against
Ashby, which makes recruiting and applicant tracking software, reported in May 2026, across more than 100 million applications to over 200,000 jobs, that applications per hire have tripled since 2021 to more than 300. It also found that candidates are roughly 50 percent less likely to get an interview than five years earlier.
Indeed's Hiring Lab found that in the second quarter of 2025, only 18 percent of US tech postings that mentioned experience were open to people with a year or less, while the share asking for five or more years rose from 37 percent to 42 percent since the second quarter of 2022.
So the reader is facing several hundred pages, many from people who clicked "easy apply" without reading the posting. Your resume has two jobs: be easy to find, then be specific enough that the reader stops skimming.
The "ATS rejects 75 percent of resumes" claim, checked
Applicant tracking systems (ATS, the software that collects and organizes applications) supposedly reject three out of four resumes before a person looks.
We couldn't find a primary study behind it. People who screen resumes for a living tend to push back on it, too. Gergely Orosz, a former Uber engineering manager who writes The Pragmatic Engineer, built his guide The Tech Resume Inside Out with input from recruiters and hiring managers at large tech companies, and its message on this point is blunt: real people read resumes, not robots. That's practitioner judgment rather than a study, but it lines up with the rest of the evidence below.
What is well documented is how common the software is. Jobscan, which sells resume-scanning software, reported in its 2026 ATS usage report that it detected an ATS at 487 of the Fortune 500 (97.4 percent), with Workday on over 40 percent of them. Across a wider set of more than 13,000 companies, Greenhouse, Workday, Lever and iCIMS each ran at roughly 14 to 19 percent. So assume a system will hold your resume. That part is near-universal.
The filtering, though, is mostly configured by people. The Harvard Business School and Accenture "Hidden Workers" study (September 2021) found that more than 90 percent of employers with recruiting systems used them to filter or rank candidates at first pass, and 88 percent agreed that qualified high-skills candidates get screened out because they don't match the exact criteria in the job description.
Here's how we read that evidence together:
- The software parses and stores. A resume that parses badly is hard to find, which can feel like a rejection.
- Knockout questions do the hard filtering. "Are you authorized to work in the US?" "Do you have three years of Python?" A "no" there can end things automatically, because someone set it up that way.
- Recruiters search and sort. Many look for exact terms like "Kubernetes" or "SQL." If your resume says "container orchestration" and never names the tool, a keyword search may skip you.
- Humans make the cut, quickly, because the stack is big.
You don't need to "beat" a robot. You need a page that parses cleanly, names real tools in the words the posting uses, and answers screening questions accurately.
A tech resume format that parses and skims
- Length: one page early in your career. MIT's career office advises sticking to one page unless you have extensive experience or an advanced degree. Senior engineers with ten-plus years sometimes run two.
- Layout: one column, standard fonts, no text boxes, icons, photos or skill bars. In our view, columns and graphics are where parsing is most likely to break.
- File: a text-based PDF unless the form asks for Word.
- Header: name, city, email, phone, LinkedIn, and one or two links to work (GitHub, portfolio, live product).
- Section order for engineers and data people: experience, projects, skills, education. Recent graduates can move education up.
- Section order for non-technical tech roles (sales, customer success, operations, product): experience, a short "tools" line, education. Projects only if they show the work.
Skip the objective statement. A one-line summary can help career changers frame the move, which our guide on how to explain a career change covers in detail.
How to write tech resume bullets that read like evidence
Weak bullets describe a job. Strong ones describe a change. A formula we find works across roles: verb + what you built or changed + how (tools, method) + result with a number. If you can add scale (users, requests, dollars, tickets), add it.
MIT's guidance points the same way: start with an action verb, name your methods and tools, and favor accomplishments over responsibilities. The Tech Interview Handbook, a guide written by a former Meta engineer, suggests at least two projects with your specific contribution spelled out.
Here are illustrative rewrites. The names and numbers are made up to show the shape.
Backend engineer\ Weak: Worked on the payments API.\ Stronger: Cut p95 checkout latency from 900 ms to 310 ms by moving fraud checks to an async queue (Go, Redis, Kafka) for a service handling 4M requests a day.
Data analyst\ Weak: Created dashboards for the sales team.\ Stronger: Built a pipeline-health dashboard in Looker on dbt models that 40 reps used weekly; flagged stalled deals that leadership used to reassign $1.2M in pipeline.
IT support, moving into a systems role\ Weak: Responsible for resolving help desk tickets.\ Stronger: Resolved about 35 tickets a week across 600 users; wrote 12 runbooks that cut repeat password and VPN tickets by roughly a third in one quarter.
Customer success at a SaaS company\ Weak: Managed a book of customers.\ Stronger: Owned 48 mid-market accounts ($3.1M ARR); ran usage reviews that lifted net revenue retention from 98 to 107 percent over the year.
Bootcamp or self-taught project\ Weak: Built a full-stack to-do app.\ Stronger: Built and deployed a scheduling app for a local tutoring center (Next.js, Postgres, Vercel); 30 families book weekly through it, replacing a shared spreadsheet.
A real user, even a small one, beats a tutorial clone. As rough rules: three to five bullets per recent role, one or two lines each, and if you can't put a number on it, name the outcome ("now the default onboarding flow").
The skills section and keywords, without stuffing
The skills section is where people tend to overdo it. A wall of 40 logos tells the reader you've touched a lot. It doesn't tell them what you can do on Monday.
What we'd do instead:
- Group it. Languages; frameworks and libraries; data and infrastructure; tools. One line each.
- List what you'd be comfortable being asked about. If an interviewer picks any item, you should be able to talk about it for five minutes.
- Mirror the posting's spelling. "PostgreSQL" and "Postgres," "JS" and "JavaScript." Use the version in the posting, once, where it's true.
- Prove the important ones in bullets. MIT notes that weaving technical skills into experience descriptions gives them context. A keyword that appears in a bullet with a result carries more weight with a human than the same word in a list.
- Leave out the obvious. Email and word processors are taken as read.
Stuffing (hidden white text, the whole posting pasted in tiny font) tends to backfire, because recruiters see the parsed text.
How to tailor a tech resume by role
Tailoring means changing what sits at the top and which bullets survive, not rewriting from scratch. Startups read for ownership and range more than polish, which our guide to writing a resume for a startup job covers with before and after bullets.
| Target role | Lead with | Links that help | Cut or shrink |
|---|---|---|---|
| Software engineer | Shipped systems, scale, performance | GitHub, live project | Unrelated coursework |
| Data analyst or scientist | Decisions your analysis changed | Notebook or dashboard | Generic tool lists |
| Product manager | Launches, metrics moved, trade-offs made | Spec or case study | Task lists from past jobs |
| Sales or customer success | Quota, retention, account size | None needed | Duties without numbers |
| IT, support or security | Volume, systems, certifications | Home lab writeup | Hobby tech without results |
Keep a master resume with every bullet you've written and cut a copy per application. NACE's Job Outlook 2025 survey (fielded August to September 2024) found nearly 90 percent of employers look for evidence of problem-solving on new graduates' resumes and nearly 80 percent for teamwork. In our view, writing those words on the page does little. A bullet that shows a solved problem does the work.
How to stand out when applying for tech jobs
A clean resume gets you into the pile. These moves get you out of it.
Apply early. With hundreds of applications per hire, the first days after a posting goes up are the window when a person is still actively reading. The 1752vc careers board shows each employer's own posting date and only keeps recent postings, so you can sort by newest and filter by level and "time posted" to find roles that went up in the past week.
Link something a person can click. A deployed project, a case study, a dashboard. One good link often beats three extra bullets. Many hiring managers already discount the page itself: Marco Rogers, an engineering leader at Lever, Yammer and Clover Health, told First Round Review in 2018 that profiles mostly show how good someone is at getting a job. In our view, that's why proof a reviewer can open tends to carry more weight.
Pair the application with a human. A short note to the hiring manager or a referral from someone on the team moves your page from the stack to someone's inbox. Our guide on how to get a referral for a tech job covers how to ask strangers without being awkward.
Answer screening questions with care. Many "automatic rejections" come from rushed knockout answers. If a posting asks for a cover letter, our guide to startup cover letters has a short template.
Tighten the signal. Our guide to building a high-signal resume goes deeper on evidence and selectivity; with little to list yet, start with how to write a resume with no experience.
"Just apply to more jobs"
It's a fair argument. Response rates are low, and tailoring every page can feel like polishing a lottery ticket.
But if interviews are roughly half as likely as five years ago, as Ashby's data suggests, a generic page sent 200 times may still produce very little, and it wastes the roles you fit best.
Our view sits in the middle: keep a steady volume, but tailor properly for the ten or so strong-fit roles a week, which the 1752vc careers board filters can surface early.
Common tech resume mistakes
- Duties instead of results. "Responsible for maintaining services" says where you sat, not what you did.
- Two-column templates with graphics. They look good in a design tool and can come out scrambled in a parser.
- A skills list that can't survive an interview. Listing Rust because you read the book is a risk.
- No links, or dead links. Click every link before you send it. Private repos and expired demo URLs are common.
- The same resume for an engineer role and a PM role. The reader wants different evidence.
- Typos and unexplained acronyms. "Javascript," "Github" and a previous employer's internal tool names all read as small signs of care, or the lack of it.
Where we land
A tech resume isn't a test of guessing what the software wants. It's a short, searchable record of things you made better.
Format it plainly, name real tools, put a number on what changed, link proof, and tailor the top. The rest is where and when you send it, which our guide on how to get a job in tech walks through.
That's our approach, not the only one. Some hiring managers prefer dense two-page resumes; some skip straight to GitHub. Adjust for who's reading.
The bottom line
The software decides whether you can be found. A person decides whether you get the call.
Write for the search box.
Then write for the human.
Key takeaways
- A strong tech resume is usually one page, one column, with bullets that state what you built or changed, how, and the measurable result.
- We couldn't find a primary source for the claim that ATS software rejects 75 percent of resumes; the hard filtering tends to come from knockout questions and recruiter keyword searches that people configure.
- Nearly every large employer uses an ATS (Jobscan detected one at 97.4 percent of the Fortune 500 in 2026), so clean parsing and the posting's exact tool names matter.
- Short, grouped skills lines work better, with key skills proven inside bullets.
- Tailoring what sits at the top for each role, applying early and linking proof tend to matter more than adding more applications.
Frequently asked questions
Some do, but mostly through rules people set, such as knockout questions about work authorization or minimum years of a skill. The popular claim that an ATS rejects 75 percent of resumes lacks a primary source. Experienced screeners such as Gergely Orosz, a former Uber engineering manager, stress that people, not software, read the resumes that make it through those rules.
One page suits most engineers with under about ten years of experience, and MIT's career office advises one page unless you have extensive experience or an advanced degree. Senior and staff engineers sometimes use two pages to show scope across several systems. If the second page is half empty or full of old roles, trimming it back usually helps.
Yes, if it holds work you'd be happy for an engineer to read: a pinned project with a clear README, real commits and ideally something deployed. A GitHub full of tutorial forks or empty repos can hurt more than help. For non-engineering roles, a portfolio, case study or writing sample usually does the same job better.
List the languages, frameworks, data tools and platforms you could discuss in an interview, grouped into a few short lines, using the posting's spelling where it's true. Prove the two or three most important ones inside your experience bullets with a result. Skip universal tools like email and word processors, and avoid long lists you can't back up.
Keep one master resume with every bullet you've written, then copy it for each role and change the top third: the order of sections, which bullets survive and the tool names in the skills line. Match the posting's language where it truthfully describes your work. Once the master exists, each version can take as little as ten to fifteen minutes, in our estimate.
Sources
- Ashby via PR Newswire: New Data from Ashby Reveals Surge in Applications, Rising Selectivity, and Shifting Recruiter Workloads
- Indeed Hiring Lab: Experience Requirements Have Tightened Amid the Tech Hiring Freeze
- Jobscan: 2026 Applicant Tracking System (ATS) Usage Report
- Harvard Business School and Accenture: Hidden Workers, Untapped Talent
- Gergely Orosz (The Pragmatic Engineer): The Tech Resume Inside Out
- First Round Review: My Lessons from Interviewing 400+ Engineers Over Three Startups (Marco Rogers)
- MIT Career Advising and Professional Development: Resumes
- Tech Interview Handbook: Practical Guide to Writing FAANG-Ready Software Engineer Resumes
- NACE: What Are Employers Looking for When Reviewing College Students' Resumes?
Disclaimer: This guide is for general education only and is not legal, tax or investment advice. Laws, market data and program terms change, so it may not reflect the latest developments or fit your situation. Treat it as a starting point, not a source of truth, and talk to a qualified lawyer, accountant or financial adviser before you make decisions.


