Why Developers Get Rejected (And Never Find Out Why)

Lenny Garnier — Tue, 28 Apr 2026 12:03:34 +0000

The application process is a blackbox, let's first crack it open then come up with a plan

"The first step toward change is awareness." — Nathaniel Branden

Hey! I'm Lenny, a junior Software Engineer. Like most developers I know, I've felt the pain of the job search, there's usually two scenarios when applying:

The sniper: Apply to a restricted number of job offers, focus on quality over quantity, actually read the whole job description, look what matches, if it interests you to actually work there, reach out directly to the company people with a (human) message.

The spammer: Apply to almost any job that lands under your mouse cursor.

I wish either of these guaranteed landing a job but the hard truth is that after trying both, getting rejected 200+ times I can say that it is not that easy to land a tech job.

To do so we need to dig deeper than just how you apply, we need to figure out what happens after you click the "Submit application" button, because if we know exactly why we're getting rejected then we know exactly how to stop getting rejected.

Part 1: Cracking the blackbox

1.1 — The invisible pipeline

Most developers think applying for a job goes like this: send a CV, someone reviews the CV then gives the response. The reality is that between "Submit" and "Unfortunately…" there's an entire pipeline that sometimes rejects you even before your application reaches human eyes.

That process used to be true. Ten, fifteen years ago applying for a job meant that a human will read it and manually review your application, that was the process when the volume was manageable.

But in 2026, a single job posting at a mid-sized tech company is likely to receive anywhere from 200 to 1k+ applications, sometimes more. It is not a viable option anymore for companies to manually review every single one, not out of laziness but out of arithmetic.

To fix that issue, a first layer of filtering was added to application processes: the Applicant Tracking System.

1.2 — The ATS layer

The ATS is software, not a human. Its job is to filter the hundreds of applications received and filter out the ones that do not "match" the job description.

The ATS parses your CV into plain text and looks for keywords. So if your CV does not mention the skills listed on the job description, there's a high chance that it will be rejected automatically.

Another effect of the ATS is that as said previously, the ATS will parse your CV into plain text, but this parsing process is not perfect and can never be, meaning that if your CV lists a skill in a fancy box the ATS may not even catch it.

That is why when making your CV it's always important to keep in mind whether it is easily readable or not. Not fancy, not unique, first and foremost it needs to be readable.

The ATS is "dumb", it will not make any conclusion. It won't look at your experience, your projects, its only job is to look for keywords and filter out CVs whose matching percentage with the job description's hard and soft skills are too low. Once you understand that, passing the ATS becomes straightforward. The real challenge starts at the next layer.

1.3 — The Human layer

If your CV passes the ATS, it finally reaches a human, usually an HR recruiter. Not a developer. Someone who may not know the difference between Python and JavaScript, or the difference between a Senior and Mid-level Engineer.

But then why does your application reach their eyes first in the pipeline? Well developers are busy, it is unfair to be reviewed by someone who is likely to not fully grasp your profile as an applicant, but it's unimaginable to make developers look at applications that early in the pipeline, the ATS does filter some applications out but it's likely that there's still 20–100 applicants left to review, again it's not laziness it's arithmetic.

The role of the HR that will review your application is closer to the ATS than you'd imagine, the purpose is to filter out even more applications, thus they will spend a few seconds looking at your application and choose whether you're suited to continue in the process or not.

6 seconds. That's the average time HRs spend making that decision, that's too short to read, instead they scan. They look at your current title, the companies you've worked at, how long you stayed at each one, and whether anything visually stands out.

This is where a lot of developers get it wrong, they optimize their CV for technical depth listing every technology they've ever touched, detailing every project they've shipped. But the recruiter cannot evaluate any of that, it's noise. What they can evaluate is clarity, structure, red flags and whether your profile looks like what they've been told to look for.

So what would stop them immediately when reviewing an application? Let's see some examples with their deduction that would stop their reading immediately:

1. Short stay at each company
The applicant has trouble being consistent at one job, it is likely that he loses motivation few months into the job.

2. Big time gaps between jobs
What happens during those gaps? Nothing? Working on side projects? What makes the applicant look for a job again after the gaps? Simply money?

3. CV has 2+ pages with less than 10 years of experience
The CV is unnecessarily long, thus probably containing inflated information.

4. CV is too colorful, too many graphics
Such CV screams "I'm compensating"

5. Font too fancy or too small
Hard to read, is not worth the time and energy deciphering the text

6. Unprofessional
Selfie profile picture / using dragonslayer2003@hotmail.com as mail / typos — it just doesn't look serious, makes the CV lose all credibility

7. Inconsistencies
Overlapping job dates / 5 years of experience but graduated 3 years ago / title on CV different than LinkedIn's. Any of these makes your CV lose 100% of its credibility, once they find one inconsistency they deem you too risky to trust.

8. Too many skills
Listing 40 technologies doesn't make you seem competent, it makes your CV look inflated and unreliable.

9. "Familiar with…"
Means the applicant lists in their CV skills they master no aspect of.

Bad news is that this list is far from complete, because it's impossible to enumerate all existing red flags.

Good news is that I'm sure this list sounds obvious, meaning you can perfectly figure out yourself what is and what is not a red flag in your CV. Just try to take the point of view of the HR that is not fully qualified in tech.

1.4 — The hiring manager layer

If you make it past the HR recruiter, your application finally reaches someone technical: the hiring manager. This is the person that will actually work with you, manage you, or be your future colleague. They know what the job requires because they do it themselves.

They look at your application completely differently.

Where the HR recruiter was scanning for red flags and structure, the hiring manager is looking for signals. Specific, technical signals that tell them whether you can actually do the job and at what level.

The first thing a technical hiring manager will often do is open your GitHub. Not to read every line of code, but to get a feel. Do you code outside of work? Are your projects just tutorials cloned from YouTube or do they solve real problems? Do your repos have clear READMEs? Is there recent activity or was the last commit two years ago?

They'll also cross-reference your CV with LinkedIn and GitHub, not to catch the applicant lying necessarily, but because consistency between the two reduces uncertainty.

Ultimately the most important question that the hiring manager asks themselves is: "Is this applicant experienced enough for the job?" To answer that question they will look for seniority signals such as Ownership, Impact, Leadership, Production systems:

"I built a feature" versus "I owned and shipped a product used by 10,000 users"
"I participated in code reviews" versus "I established the team's code review process"

The difference is not just wording, it genuinely reflects different levels of experience and responsibility.

The hard truth is that a hiring manager has seen hundreds of CVs. They immediately know when someone is a level below what the role requires. And in a pool of 10–20 shortlisted candidates, "almost senior" always loses to "clearly senior".

If you pass the hiring manager's review, you get an interview. If you don't, you get silence or a polite template rejection email that tells you nothing.

Congratulations! We just cracked open the blackbox of the hiring process — three layers, three different perspectives of whether you're suited for the job.

You could be failing at any of those layers and have no clue of how far you've made it into the pipeline. That's what we're going to fix.

Part 2: The blind spots

2.1 — What you live versus what you show

I'll make a bold guess: You're probably suited for the job. What stands in your way is literally between you and the job: ATS, HR, Manager and Interviews.

What keeps you from landing the job is the gap between reality and what you show. Your application is a story, to you it seems obvious but to the HR and the Manager it's incredibly hard to understand your story just by reading your CV.

Here is a classic example. You spent 6 months building a payment system that handled thousands of transactions a day, dealt with edge cases, worked with external APIs, and went to production without a single incident.

Your CV says: "Worked on backend payment features." That's the gap.

That's why I want you to do this exercise: Open your CV, close your eyes for a few seconds and try putting yourself in another point of view, the next time you'll read your CV you'll know only what you read about the applicant, nothing more, nothing less. Once you're done reading ask yourself these questions:

Is the applicant's journey clear?
Is it clear what the applicant can and cannot do?
Would I hire this applicant (yourself) solely based on what I read on this CV?
If no, what in this CV makes me reluctant to hire this applicant?

This is a hard exercise, mainly because you wrote this CV yourself, but think of this: You need to be the first to read your CV, not the hiring HR.

Push this exercise further, make someone read your CV and answer all those questions, I'm sure at least a few (if not many) improvements will result from this exercise.

2.2 — Each job is a story

Have you ever wondered what's a job? Personally I once treated a job as a way to get money, don't get me wrong it is that but the truth is that it's way more than that.

Have you ever asked yourself: "What issue is the company trying to solve by hiring someone?" "What profile are they looking for when writing the job description?" "Why this profile in particular?" "What do they expect from the hired applicant 6 months from now?" "1 year from now?"

Two companies can post the exact same job title with the exact same required skills. One is a startup that just raised a Series A and needs someone to build fast and break things. The other is a scale-up that needs someone to stabilize a codebase that's been growing too fast. Same title. Same technologies. Completely different stories. Completely different ideal profiles.

As said in 2.1 you have a story, but so does the job. It's about whether your story resonates with the job's story, so it's not about lying on your application, it's about telling your story in the same language as the job's.

So the next time you're going to apply for a job, spend 10 minutes asking yourself those questions. Not to find the right answers, but to understand what story the job is telling. Then look at your CV and ask: does my story speak the same language?

2.3 — The seniority trap

The seniority trap is not just about "you're applying for something too high", it's more subtle than that: it's that a lot of devs do not know what their actual level is. And their CVs are sending clear signals without them realizing.

Developers who deem themselves mid are juniors, and seniors are mid. It's human.

Junior signals:

"I worked on"
"I helped build"
"I used React"
Only side projects on GitHub
No metrics
Describe tasks

Senior signals:

"I owned and shipped"
"I designed and led"
"I architected the frontend"
Projects that are live, with a real user base
Describe impacts

Have you noticed the difference? It's the active/passive tone. Whether you were an actor or director of operations, whether you led or were led, whether you had responsibilities or not. Just from the tone of your CV, LinkedIn and GitHub the Hiring Manager knows whether you're senior enough for the job or not.

So how can an applicant know what their true level is? Same exercise — try reading your CV from another perspective, from what's written evaluate your seniority level. Also read the job description thoroughly, figure out what the responsibilities are. Does your CV fill those? Does your CV show experience in at least 90% of the job description's requirements?

In those exercises you are bound to improve faster with outside help, even from a non-technical profile, just ask them to be honest and tell you what level they think you're at. The answer might surprise you.

2.4 — Your online presence is probably working against you

Your CV is half the story, anything that is public is part of your application, whether you like it or not.

Now that you're good at reading stories solely based on CVs, here's your final exercise which is way harder. Get good at reading people's stories — not just their CVs, everything. Give yourself 30 minutes per person, look up their CV, their GitHub, their LinkedIn, search them up on Google, do cross-referencing, try to mentally map out their timeline and ask yourself these questions:

"Is everything adding up?"
"What are their strong points? Weak points?"
"What is their level of seniority?"
"Would I hire them?"
If no, "Why is that?"
If yes, "What is it that they do that I should do?"

Who should you analyze? Find developers on LinkedIn who have the job you want. Look at people who were recently hired for the exact role you're targeting. Their profile is proof that the hiring manager said yes — figure out why.

Again outside help is useful but this time it is crucial that you do it yourself and thoroughly. Your application will improve at each iteration, even if it's little by little.

Part 3: The plan

You cracked the blackbox. You identified your blind spots. Now it's time to set a plan, repeatable at each application.

Start by identifying the real issue — it's not that devs lack skills, it's that they apply without a system. Each application should be an iteration, not a blind shot.

The moment you start treating rejections as data points instead of failures, the whole game changes.

You're not someone who got rejected 200 times. You're someone who ran 200 experiments. Some of them taught you that your CV was unclear. Some taught you that you were applying for the wrong level. Some taught you that your GitHub was sending the wrong signals. Each rejection, as painful as it is, is information.

The developers that land jobs are not necessarily the most talented ones. They're the ones that iterate the fastest.

Here's the framework in three steps:

1. Before applying

Audit your CV, GitHub, LinkedIn
Do the Part 2 exercises
"Is my story clear?"

2. For the job

Adapt your story to theirs
Add the job description's keywords
"Is my seniority level correct?"

3. After each rejection

It's not a failure, it's data
"What probably made me fail?"
"What do I need to change for the next application?"

I know how exhausting this process is. I lived it through 200+ rejections, doing all of this manually for every single application: reading the job description, cross-referencing my CV, checking keyword match, auditing my GitHub and LinkedIn. It's a lot.

That's why I built RejectCheck. I wanted a tool that does this audit for you, before you apply, so you can focus on what actually matters: understanding the job and telling your story better.

I built it for myself first. It worked. Now it's free to try.

Thanks for reading this far. I know it's a lot to take in.

If any of this resonated with you, or if you're currently in the middle of a job search and struggling, feel free to reach out. I've been there, I know how isolating it can feel, and I'm always happy to talk.

Good luck out there. You've got this!

DEV Community: Lenny Garnier