DEV Community: Raman Mohammed

How ATS Resume Parsers Actually Work (A Developer's Perspective)

Raman Mohammed — Tue, 27 Jan 2026 08:41:00 +0000

If you read my last post, you know the junior dev job market is brutal. But here's the thing that makes it worse: before a human ever sees your resume, software decides whether you're worth looking at.

That software is an Applicant Tracking System. And as developers, we should understand how it works. Because once you see the implementation, you'll realize it's far dumber than you'd expect.

What ATS Actually Is

An Applicant Tracking System is CRUD software for hiring pipelines. It posts jobs, collects applications, stores candidate data, and filters resumes.

The math makes it necessary. A single job posting at a mid-sized company gets 250+ applications. At companies like Google or Stripe, that number hits thousands. No human reads all of those.

Popular platforms include Workday, Greenhouse, Lever, iCIMS, and Taleo. Each has slightly different parsing logic, but they all follow the same basic pipeline.

Think of it as a data ingestion system with questionable parsing.

The Parsing Pipeline

When you submit your resume, the ATS doesn't "read" it. It runs a pipeline that would make most engineers cringe.

Step 1: Text Extraction

The ATS converts your document to plain text. This is where things break immediately.

What works:

.docx files (structured XML under the hood, easy to parse)
.pdf files created from text editors (text layer intact)
Plain .txt files

What breaks:

Scanned PDFs (the parser sees a raster image, not text nodes)
Complex tables and multi-column layouts
Headers and footers (many parsers skip these entirely)
Text embedded in SVGs or images
Custom fonts that don't map to Unicode correctly

If you've ever tried to extract text from a PDF programmatically, you know this pain. ATS parsers face the same issues, and they don't handle them gracefully.

Step 2: Section Classification

The parser attempts to identify document sections:

Contact information
Work experience
Education
Skills

It looks for common headers like "Experience," "Education," and "Skills." If you use "Where I've Made Impact" instead of "Work Experience," the parser doesn't understand what it's looking at.

This is basically string matching against a dictionary of known section headers. Not NLP. Not semantic understanding. Pattern matching.

Step 3: Entity Extraction

Here's where it gets interesting. The parser tries to extract structured data:

Entity	Extraction Method
Name	First line or largest text element
Email	Regex: `something@something.tld`
Phone	Regex: number patterns with area codes
Job Titles	Matched against known title databases
Companies	Matched against company name databases
Dates	Pattern matching (MM/YYYY works most reliably)
Skills	Keyword lookup against job requirements
Degrees	Pattern matching (BS, BA, MBA, PhD, etc.)

This is essentially a named entity recognition system, but most ATS implementations are closer to regex with a dictionary than actual NER models. The accuracy is surprisingly low.

Step 4: Keyword Matching

Once parsed, the system compares extracted text against the job description:

Hard skills: Python, React, AWS, Kubernetes, PostgreSQL
Certifications: AWS Certified, PMP, Kubernetes CKA
Job titles: Software Engineer, Frontend Developer, DevOps
Buzzwords: Agile, CI/CD, microservices, distributed systems

Some systems do literal string matching. Others are slightly smarter and understand that "JS" and "JavaScript" are the same thing, or that "K8s" means "Kubernetes." But don't count on it.

Step 5: Scoring

The ATS assigns a match score:

Percentage match (78% match)
Tier ranking (A, B, C candidates)
Pass/fail filter (meets minimum threshold or doesn't)

Only resumes above the threshold reach a recruiter.

Why Your Resume Gets Silently Dropped

Understanding the pipeline reveals why qualified developers get filtered out:

Formatting That Breaks Parsing

Your portfolio-quality resume with a CSS Grid layout and sidebar looks great in a browser. The ATS reads it as a jumbled mess.

The parser reads left-to-right, top-to-bottom. In a two-column layout, it might extract:

"Senior Software      5 years React
 Engineer             Built distributed..."

Instead of:

"Senior Software Engineer
5 years React experience
Built distributed systems..."

Fix: Single-column layout. Save the fancy design for your personal site.

Missing Keyword Matches

You have 5 years building REST APIs, but the job description says "API development" and you wrote "built backend services." The parser doesn't understand these mean the same thing.

// What the ATS does (simplified)
const match = jobKeywords.filter(kw => 
  resumeText.toLowerCase().includes(kw.toLowerCase())
);
const score = match.length / jobKeywords.length;

It's not semantic search. It's includes().

Fix: Mirror the exact language from the job description. If they say "CI/CD pipelines," use "CI/CD pipelines," not "automated deployments."

Non-Standard Section Headers

// ATS parser pseudocode
const KNOWN_HEADERS = [
  'experience', 'work experience', 'professional experience',
  'education', 'skills', 'summary', 'certifications'
];

function classifySection(header) {
  return KNOWN_HEADERS.find(h => 
    header.toLowerCase().includes(h)
  ) || 'unknown'; // your content gets ignored
}

"My Journey in Code" maps to unknown. Your experience section disappears.

Fix: Use boring, standard headers. "Work Experience." "Skills." "Education."

File Format Issues

Some PDF exports from design tools (Canva, Figma) create visually perfect documents where the underlying text layer is scrambled. The ATS extracts gibberish.

Quick test: Open your PDF, Ctrl+A, Ctrl+C, paste into a plain text editor. If it's garbled, the ATS sees garbled text too.

The Developer's ATS Optimization Checklist

Format

[ ] Single column layout
[ ] Standard fonts (system fonts work fine)
[ ] Clear section headers (Experience, Skills, Education)
[ ] Consistent date format (MM/YYYY)
[ ] No tables, text boxes, columns, or graphics
[ ] PDF exported from a text editor, not a design tool

Keywords

Don't keyword stuff. Integrate terms naturally:

Before:

Worked on backend systems

After:

Built RESTful APIs serving 50K requests/day using Node.js, Express, and PostgreSQL. Implemented CI/CD pipeline with GitHub Actions reducing deployment time by 60%.

The second version naturally hits: REST API, Node.js, Express, PostgreSQL, CI/CD, GitHub Actions. All potential ATS keywords.

Skills Section

Give the parser an easy win. Create a dedicated skills section:

SKILLS
Languages:    TypeScript, Python, Go, SQL
Frameworks:   React, Next.js, Express, FastAPI
Cloud:        AWS (EC2, Lambda, S3, RDS), Docker, Kubernetes
Databases:    PostgreSQL, Redis, MongoDB
Tools:        Git, GitHub Actions, Terraform, Datadog

This is structured data the ATS can reliably extract.

Job Titles

If your actual title was "Code Ninja" or "Software Wizard," translate it:

Software Engineer (internal title: Code Ninja) | Startup X | 2022-2025

The ATS recognizes "Software Engineer." It doesn't recognize "Code Ninja."

What ATS Can't Evaluate

While you're optimizing for the algorithm, remember what it completely misses:

Code quality — It can't read your GitHub
System design ability — No way to evaluate architectural thinking
Cultural fit — Your personality doesn't parse
Growth trajectory — It can't see your learning curve
Side projects — Unless you name-drop the right keywords
Open source contributions — Invisible to keyword matching

This is why networking and referrals matter so much. A referral bypasses the ATS entirely. Your resume goes straight to a human who can evaluate what the software can't.

The Uncomfortable Truth

ATS is a blunt instrument. It exists because companies are drowning in applications, not because it's good at identifying talent.

As developers, we'd probably architect this system differently. We'd use embeddings for semantic matching instead of string comparison. We'd parse documents with proper NLP instead of regex. We'd evaluate GitHub profiles and actual code.

But that's not what most companies use. They use systems built in the early 2010s with incremental improvements. And your resume needs to work with the system that exists, not the one that should exist.

The good news: once you understand the implementation, gaming it is straightforward. Clean format, standard headers, mirrored keywords, plain text that parses cleanly. It's not rocket science. It's just knowledge most candidates don't have.

If you want to see how your resume actually parses, I built ResumeFast that scores your resume against job descriptions. Knowing your match score before you apply changes everything.


---

## SEO Content for This Post

**Meta Description:**

Learn how ATS resume parsers actually work from a developer's perspective. Understand the parsing pipeline, why resumes get dropped, and how to optimize for keyword matching systems.


**Social Snippet (Twitter/X):**

Your resume doesn't get "read" by ATS software.

It runs through a pipeline that's basically:

Regex for emails
String matching for keywords
includes() for scoring

Here's the implementation and how to beat it 👇

The Junior Dev Paradox: Why "Entry-Level" Now Requires 3 Years Experience

Raman Mohammed — Mon, 26 Jan 2026 08:21:00 +0000

The job listings say "entry-level" but require 3-5 years of experience.

The junior positions that do exist receive 500+ applications within 48 hours.

Your bootcamp instructor keeps saying "just build projects and apply," but you've built 12 projects and sent 200 applications into the void.

This is the reality of breaking into tech in 2026. Let's talk about what actually changed and what to do about it.

The Jobs That Disappeared

Let's be specific. These roles used to be reliable entry points:

Junior Developer

Write basic CRUD features, fix simple bugs, learn the codebase under senior supervision. Now: AI coding assistants handle boilerplate, seniors ship faster without juniors, and the "learning runway" companies used to provide feels like a luxury they can't afford.

Junior Data Analyst

Pull reports, clean datasets, create basic visualizations. Now: ChatGPT writes SQL queries, AI tools generate dashboards, and one mid-level analyst does what a team of three did before.

QA Tester

Manual testing, writing test cases, regression testing. Now: AI generates test cases, automated testing covers more ground, and the remaining QA roles require automation skills that aren't "entry-level."

Technical Writer

Document features, write API docs, maintain knowledge bases. Now: AI drafts documentation that senior writers edit, and the volume one person can handle increased dramatically.

The common thread: tasks that required human effort but not much human judgment. Repetitive cognitive work. The digital equivalent of assembly line jobs.

Companies didn't eliminate these roles to be cruel. A Resume Builder survey found 37% of companies replaced workers with AI in 2024, with entry-level positions hit hardest.

The traditional career ladder assumed you'd learn by doing basic work, gradually taking on more responsibility. But if AI handles the basic work, there's no learning runway.

What Employers Actually Hire For Now

1. AI Wranglers, Not AI Replacements

The most in-demand skill isn't a programming language. It's knowing how to make AI tools actually useful.

Not "I can use ChatGPT." More like:

Writing prompts that generate working code (not almost-working code)
Knowing when Copilot suggestions are wrong before you accept them
Integrating AI tools into development workflows
Understanding what AI can't do and when to code manually

Most applicants your age use AI casually. Few use it systematically. That's your edge.

2. Complex Problem-Solving

AI handles well-defined tasks. It struggles with poorly-defined problems.

Employers value people who can:

Figure out what the actual problem is (not just the symptom)
Debug issues that don't have Stack Overflow answers
Make architectural decisions with incomplete information
Handle the weird edge cases that don't fit patterns

3. Human Skills That Scale

Code review isn't just about catching bugs. It's about mentoring, building consensus, and maintaining team standards. AI can suggest changes. It can't navigate team dynamics.

Same with:

Technical interviews (reading candidates, not just evaluating solutions)
Client communication
Cross-team collaboration
Handling production incidents under pressure

Building a Resume Without Traditional Experience

Here's the practical challenge: how do you prove you can do valuable work when you haven't had a job doing that work?

Redefine "Experience"

Stop thinking of experience as "employment." Think of it as "demonstrated ability."

Employment experience:

Software Engineering Intern, Company X, Summer 2024

Assisted senior developers with bug fixes

Participated in code reviews

Demonstrated ability:

Open Source Contributor, [Project Name], 2024-Present

Shipped 15 merged PRs including a feature used by 10,000+ users

Reduced API response time by 40% through query optimization

Collaborated with maintainers across 3 time zones

Which one proves you can actually ship code?

Create Your Own Proof Points

For every skill you claim, create evidence:

Backend Development

Contribute to open-source projects with real users
Build a side project that solves an actual problem (not another todo app)
Write about technical challenges you solved and publish on dev.to
Document your code decisions, not just final implementations

Frontend Development

Clone complex UIs and document what you learned
Build accessibility improvements for open-source projects
Create interactive demos that show your problem-solving process
Ship something real, even if small

DevOps/Infrastructure

Set up CI/CD for open-source projects that need it
Document your homelab or cloud experiments
Contribute to tooling that other developers use
Write runbooks and post-mortems for problems you've solved

The key: You're not pretending you had a job. You're proving you can deliver results without needing the job to prove it first.

Leverage AI as a Talking Point

Here's the irony: AI eliminated entry-level jobs, but AI proficiency can get you hired.

On your resume:

Used AI coding assistants to 2x development velocity while maintaining code quality standards
Built internal prompt library for [specific use case], adopted by team of 8
Developed AI-assisted testing workflow reducing bug escape rate by 30%

In interviews:
Don't just say you use Copilot. Explain when you ignore its suggestions and why. Show you understand the limitations. That's what separates sophisticated users from people who just accept autocomplete.

Target Companies Strategically

Stop mass-applying to FAANG job boards. Those postings get thousands of applications from people with traditional experience.

Instead:

Startups (under 50 people)

Can't afford senior salaries for every role
Value potential and hustle over credentials
Will give you real responsibility faster
More likely to evaluate your GitHub than your resume

Open Source Companies

Already know you from your contributions
Value community involvement
Shorter interview loops for known contributors

Agencies and Consultancies

High turnover means constant hiring
Project variety builds experience fast
Client work forces you to learn quickly

Contract-to-Hire

Companies hesitant to hire full-time will bring on contractors
Prove yourself, become the obvious choice when they do hire

The Skills to Develop Now

Tier 1: Non-Negotiable

AI Tool Proficiency
Not casual use. Know which tools work for which tasks. Build prompt libraries. Stay current as tools evolve weekly.

One Language, Deep
Generalists compete with AI. Go deep on one language/framework. Understand it well enough to debug without Google.

Communication
Writing clear documentation. Explaining technical decisions. Async communication for remote teams. This is your moat against AI.

Tier 2: Differentiators

System Design Basics
Even for junior roles, understanding how systems fit together matters more than ever.

Domain Knowledge
Healthcare, fintech, e-commerce. Deep knowledge in one area makes you valuable in ways AI can't replicate.

Testing and Quality
As AI writes more code, humans who can verify it becomes more valuable, not less.

What to Do This Week

Stop waiting for the perfect junior role. Start building proof.

Days 1-2:
Find one open-source project in your target area that accepts contributions. Read their contribution guide. Set up the dev environment.

Days 3-4:
Find a "good first issue" and work on it. Or find a documentation gap and fill it. Ship something, however small.

Days 5-6:
Write about what you learned. Post it here on dev.to. This is content that proves you can communicate, not just code.

Day 7:
Find 10 startups in your target area. Research them. Find the engineering lead on LinkedIn. Prepare personalized outreach for next week.

The entry-level ladder rung might be gone, but the destination still exists. You just need to build a different path to get there.

I built ResumeFast to help developers highlight projects and contributions over traditional job titles. If you're navigating this weird job market, I'd love to hear what's working for you in the comments.

Why I decided to give away my UI library for free (and just sell the boilerplate)

Raman Mohammed — Mon, 05 Jan 2026 11:30:51 +0000

Hey everyone! 👋

I've been building Launcho, a Next.js SaaS boilerplate, for the last few days. Its very early stage, but I've gotten started with building the UI components and marketing blocks.

Originally, my idea was to lock everything behind a paywall. You know, the usual "buy the kit to see the components" thing, like many other platform has it, such as Shadcnblock, etc (most of these are easily recreatable with AI anyway).

So starting this weekend, most of the UI Blocks are gonna be free. I'm adding a "Copy Code" button to the library. You can just grab the Hero, Features, Testimonials, etc., and drop them into your project. No signup needed, which you can find here: https://launcho.dev/blocks

If the UI is free, the Pro kit is the Fullstack Project.

The PRO kit is supposed to cover everything needed for a boilerplate NextJS, such as analytics, authentication, authorisation, payment, SEO, email, alternative backend architecture REST, gRPC, etc.

The goal is more for me to be able to publish many indie project, much quicker, as rewriting this for each project feels a bit tedious.

Anyway, I am trying to build in public, so if you have any tech stack preferences or ideas please share them! And if you want to support, joining the waitlist would really make my day: https://launcho.dev/waitlist

Have a great evening.

I Got My First Dev Job After 6 Months of Rejections - Here's What Actually Worked

Raman Mohammed — Sun, 16 Nov 2025 17:03:30 +0000

I Got My First Dev Job After 6 Months of Rejections - Here's What Actually Worked

Hey,

Just accepted my first junior dev position and wanted to share what actually got me there, because it wasn't what everyone on Reddit tells you.

My "Perfect" Resume That Nobody Wanted

CS degree, internships, active GitHub, LeetCode grind. Had all the boxes checked. Still got ghosted by 95% of companies for months.

The breaking point was people telling me "AI will replace you anyway" while I'm literally shipping code every day. Felt insane.

What Actually Changed

Honestly, I didn't suddenly get better at coding. Three things shifted:

Stopped spray-and-pray applications. Used to send 20+ apps/week with the same resume. Started doing 5/week but actually researched each company - matched my resume to their tech stack, referenced their products in cover letters. Quality over desperation.

This is why I built Woberry initially - needed something to help me track applications and auto-generate tailored cover letters without losing the personal touch. It's at ~$2K MRR now.

Built stuff I actually needed. Everyone says "do side projects" but here's what matters - solve your own problems. In interviews, I wasn't talking about tutorial apps. I was explaining real users, revenue, bugs I'd fixed. That hits different.

Right now I'm building a fitness app because every tracking app out there feels bloated or has a terrible UX. Just want something simple that works. In interviews, employers loved hearing about this kind of thinking - spotting gaps and just building the solution.

Gave up trying to impress people. The interview I got hired from? Went in expecting nothing, just talked normal. No rehearsed answers, just honest conversation. Apparently juniors who can communicate clearly are rarer than you'd think.

The Weird Part

Starting in November but keeping Woberry running. Part of me wonders if I should've gone full indie, but honestly the stability means I can build without financial panic. Plus I'll get Spring Boot production experience which I can't replicate solo.

If You're Still In It

Market's brutal and it's not your fault. But volume won't save you - quality and being real will.

Build something, even if small. Your side project might become your backup plan. Mine did.

If you're drowning in tracking applications and writing cover letters, that's literally why Woberry exists - built it because I needed it. Also made ResumeFast when I just needed a quick resume without all the extra features.

You're probably closer than you think.

https://www.woberry.com/ and https://www.resumefast.io/ if you want to check them out