Structuring Your Resume to Beat ATS Systems in Tech

Most rejected resumes are never read by anyone. They are parsed by an applicant tracking system, converted into structured fields, scored against the job description, and sorted. If the parse goes badly, a strong candidate can be filtered out before a human ever sees the file — not because they weren't qualified, but because their two-column layout confused a text extractor.

This is a solvable problem, and solving it costs nothing. Here is what actually happens to your resume, and how to make sure it survives.

What an ATS actually does

An ATS does three things in sequence. First it extracts raw text from your file. Then it tries to identify sections — where does experience start, which lines are job titles, what are dates. Finally it matches the extracted content against the requirements of the role, usually by looking for specific terms.

Every one of these steps can fail, and the first is the one that quietly destroys the most resumes. Modern systems are considerably better than their reputation suggests, but they still parse a single-column document far more reliably than a designed one.

Formatting choices that break the parse

• Multi-column layouts. Text extractors read left to right across the full page width. A two-column resume can interleave your skills section into the middle of your job history, producing gibberish.
• Text inside images or graphics. It is invisible. A skills section rendered as a chart contributes exactly nothing.
• Headers and footers. Many parsers skip them entirely. If your phone number and email live in the header, you may have submitted an anonymous resume.
• Tables. Support is inconsistent and the failure is silent.
• Creative section names. "Where I've Made An Impact" will not be recognised as your experience section. Call it Experience.
• Uncommon fonts and icon glyphs. A phone icon may extract as a garbage character glued to your number.

The structure that works

Single column. Standard section headings, in a conventional order. A common font. PDF, unless the application explicitly asks for .docx.

1. Name and contact details — in the body of the document, not the header.
2. A two-line summary, only if it says something specific. Skip it rather than write a generic one.
3. Skills — a plain, scannable list of real technologies.
4. Experience — reverse chronological, with dates in a consistent format.
5. Projects — for career switchers this may deserve to sit above Experience.
6. Education and certifications.

Keywords: mirror the posting, don't stuff it

The matching step looks for terms from the job description. If the posting says "PyTorch" and your resume says "deep learning frameworks," you may not match — the system is often doing something closer to string matching than semantic understanding.

So mirror the posting's vocabulary, exactly, wherever it is honestly true of you. If they ask for RAG, write RAG — not "retrieval systems." If they list Kubernetes, and you have used Kubernetes, the word Kubernetes should appear on your resume.

Two guardrails. First: spell out acronyms once, in the form "Retrieval-Augmented Generation (RAG)," so you match both variants. Second: never list a technology you cannot discuss for five minutes in an interview. Keyword stuffing gets you into a room where you are then exposed, which is worse than not getting into the room.

Bullets that survive the human, too

Passing the filter only earns you six seconds of a recruiter's attention. What loses that attention is a resume that lists responsibilities instead of results.

The pattern that works: what you did, how you did it, what changed as a result. The last part is the one almost everyone omits, and it is the only part that distinguishes you.

• Weak: "Responsible for building machine learning models."
• Better: "Built a customer churn model in Python and scikit-learn."
• Strong: "Built a churn prediction model (Python, scikit-learn, XGBoost) that identified at-risk accounts two weeks earlier than the previous rules-based system, cutting monthly churn by 12%."

If you genuinely don't have a metric, use scale or scope instead — the size of the dataset, the number of users, the volume of traffic, the reduction in manual hours. Something concrete beats an adjective every time.

If you're switching careers

The temptation is to hide the old career. Don't — it's an asset, and pretending otherwise makes your timeline look suspicious. The move is to reframe it as domain expertise and put your evidence of the new skill above it.

A finance analyst moving into AI is not competing with fresh graduates; they are a candidate who understands financial data, which is worth a great deal to a fintech hiring an ML engineer. Lead with a projects section that proves you can build, keep the old experience but rewrite the bullets to emphasise data, analysis, and systems, and let the combination speak.

The one-page question

Under roughly ten years of experience, keep it to one page. This is not a formatting rule, it is an editing discipline: the constraint forces you to cut the bullets that were never impressing anyone. Two pages are acceptable for genuinely senior candidates with a long record of relevant work. Three pages are not.