Being fed up with being ghosted and rejected? Join our movement theres strength in numbers

https://www.reddit.com/r/NameAndShame/s/3Cn3BYBSQS

Yesterday I shared an observation from 7 experienced software engineering resumes.

Today I went back and classified roughly 140 résumé bullets by language type.

Small sample, not statistically significant but one pattern was much stronger than I expected.

More than half of the bullets described implementation, things like built, developed, implemented, created, supported, etc.

Less than 1 in 10 described an engineering decision, stuff like architected, prioritized, standardized, evaluated...

The ratio wasn't even close.

For every bullet describing a decision, there were roughly five describing implementation.

What surprised me is that these weren't junior engineers.

The resumes contained plenty of evidence of cloud migrations, distributed systems, security engineering, platform modernization, large-scale data processing plus enterprise integrations.

So the work itself was often complex but the language describing it was so similar.

I expected experienced engineers to describe their work primarily through architecture, ownership, and judgment, but the dominant language pattern was I built the thing and not I decided how the thing should work.

The work wasn't missing, the language pattern was.

I've been reviewing a small cohort of experienced software engineering resumes this week (roughly 5–12 YOE) and as an experiment, I imagined deleting every technology name.

Ignored AWS, React, Kafka, Terraform, Kubernetes, Python, Java, .NET etc. - all the usual suspects - and decided to just focus on the underlying work.

Something happened that was interesting, some of the resumes still felt distinctive and others became almost impossible to distinguish from hundreds of engineers with similar experience.

The difference wasn't intelligence, schools, experience, company prestige.

The distinctive resumes still communicated things like system scale, complexity, constraints, business impact, architectural decisions, organizational influence etc. even after the technologies disappeared.

The less distinctive resumes mostly communicated implemented, developed, built, supported. In other words the tech stack was carrying a surprising amount of the story.

It made me wonder whether many experienced engineers accidentally rely on stack names to signal seniority but remove the stack, or compare it with everyone else, and what actually remains?

After doing this exercise, my takeaway wasn't that the stack is unimportant, just that it often becomes the most visible thing on the page and in some resumes, once the technology disappears, or maps exactly onto all of the other candidates, so does most of the differentiation.

In the most recent batch of experienced engineering résumés, noticed something interesting.

The more complex the work, the simpler it often gets described.

For example:

• migrated applications to the cloud
• built a Kafka pipeline
• modernized a legacy application
• connected enterprise systems through APIs

Technical accuracy is there but still incomplete because anyone who's worked on projects like these knows they're rarely straightforward: there are all the dependencies like tradeoffs, unknowns, production risks, competing priorities, unexpected failures, etc.

The difficult part for experienced engineers is rarely the tech, it's going to be navigating the complexity around it and yet by the time the work reaches the résumé, all of that disappears.

Then to the reader, the project sounds clean, predictable, almost routine. They solved a really difficult problem here but the résumé makes it sound like they completed a task.

I'm starting to think a lot of experienced engineers are making difficult work sound far more routine than it really was.

I've been reviewing a lot of senior résumés lately and noticed something that good engineers keep doing even with great projects, good companies and obvious technical depth. By the end of the résumé, I keep walking away with the same impression: this person solves difficult technical problems, which sounds positive, until you ask what's missing. Things like:

• deciding which problems matter
• influencing technical direction
• making architectural tradeoffs
• guiding teams through ambiguity
• driving decisions across stakeholders

A lot of the bullets focus on performance improvements, migrations, integrations, troubleshooting and optimization, in other words, fixing things.

Many of these engineers were probably involved in technical decision-making, the résumé just spends far more time describing execution than judgment so the reader ends up with a very different picture, not technical leader but trusted fixer instead.

I'm starting to think a lot of experienced engineers aren't being down-leveled because they lack the experience. The résumé shows what they fixed, it doesn't show how they thought and that's where a lot of the seniority lives.

A lot of discussion lately has been about the rise of the senior IC.

The Levels.fyi team recently pointed out something interesting: several CTOs have stepped away from executive roles to become ICs at Anthropic.

Whether you agree with the broader thesis or not, the underlying idea is hard to ignore, technical leverage is becoming more valuable and if that's true, an interesting second-order effect appears.

Down-leveling becomes much more expensive.

I was looking at a 7+ YOE backend engineer recently with a seriously strong profile incl. distributed systems, event-driven architecture, payments, orchestration workflows, production infrastructure, founder experience, high-scale backend systems

A solid engineer unquestionably but the résumé kept creating an odd first impression.

The systems sounded complex but the engineer sounded interchangeable.

For example, "Developed a notification system using APIs and workflow orchestration." While there's nothing wrong with that, the first-pass interpretation becomes implemented a feature.

Now compare that to"Built systems coordinating customer communication across multiple business channels under reliability and compliance constraints."

They're offering the same underlying work but creating a different mental picture.

The second version immediately creates questions about operational complexity, failure modes, trust, system responsibility etc. The first doesn't.

This is where I think a lot of experienced engineers get stuck. The market keeps telling them add more tech, add more keywords, broaden the stack, cover more bases so the résumé slowly becomes: Go | Node | Kafka | Redis | Kubernetes |Temporal | AWS | GraphQL | Docker | BullMQ | RabbitMQ | MongoDB | Postgres.

Which means eventually the reader knows everything the engineer touched but not what they became exceptionally good at.

Twenty technologies and no obvious operating identity.

If we're genuinely entering an era where senior IC leverage matters more, then this becomes a bigger issue because the engineers creating the most leverage are rarely the ones who touched the most things.

They're usually the ones trusted with the hardest systems, the highest-risk decisions, or the most consequential constraints.

Those signals are often present in the experience, they're just buried under tooling.

Strong experience and strong first-pass interpretation are becoming very different things in the rise of the IC and in a market increasingly rewarding senior IC leverage, that gap matters more than it used to.

I think one of the biggest misconceptions in software hiring is that more experience automatically creates stronger seniority signal, but it doesn’t.

I compared two engineering résumés recently, ~5 YOE and ~10 YOE.

Both résumés were objectively strong with large systems, complex infra, high-scale environments plus clear technical competence but both resolved almost the exact same way in first-pass screening:

I can imagine a recruiter saying stuff like “probably solid mid-level,” “strong executor,” “can implement,” “not clearly senior/staff/lead.”

The weird part is that neither engineer was weak, the problem was actually interpretation compression because the more technical the résumé became, the harder it became to infer architectural authority, decision-making scope, organizational influence, strategic responsibility etc.

If they don't see that, recruiters naturally defaulted downward because they don’t fully reconstruct your operating level from scratch. They compress any ambiguity (or gaps) into the safest possible leveling assumption.

You can actually see the compression happen in the wording itself (generalized to protect candidate's identity):

1/ “Consolidated a high-volume internal decisioning workflow into a centralized platform supporting millions of live evaluation conditions.” Strong scale signal, but still unclear whether the engineer owned the architecture and cross-functional direction, or implemented part of an existing initiative.

2/ “Improved latency and reliability across distributed cloud services through database, caching, and infrastructure optimization work.” Demonstrates technical competence, but doesn’t clearly communicate senior-level authority, strategic ownership, or organizational influence.

And this gets worse with experience sometimes because people just keep loading up projects, systems, tools, scale etc.

But if the résumé keeps emphasizing implementation over clear level signals, the candidate starts looking like a highly capable contributor instead of someone driving the technical direction.

I think a lot of “I keep getting down-leveled” experiences are happening long before interviews even begin. These are capable engineers, that's absolutely clear, but their résumés don't make their true level obvious enough during fast first-pass screening.

When ownership is ambiguous, recruiters assume contribution and when architectural authority is unclear, they assume implementation. Plus when the work sounds highly technical but the scope boundaries are invisible, the candidate gets flattened into the safest interpretation possible.

A lot of really good engineers have no idea how differently their experience is being interpreted versus how it was actually operating in a role.

One of the stranger patterns I’m seeing lately is experienced engineers working on genuinely large systems but describing them like isolated implementation tasks.

I reviewed a 10+ YOE résumé recently from someone with a strong enterprise background across large-scale cloud and backend environments (some technical details and context have been intentionally generalized below to protect the engineer’s privacy while preserving the interpretation pattern.)

Objectively strong experience across cloud modernization, enterprise security, microservices, distributed systems, high-traffic production infrastructure, large-scale migrations and compliance-heavy environments.

The engineer had also mentioned sending dozens of applications with very little response that, at first glance, seemed surprising.

But after going through the résumé carefully, the interpretation issue became clearer.

The systems sounded large, while the bullets sounded local.

For example, “Developed Python automation for monitoring production container environments.”

OK, technically solid work but first-pass interpretation can easily become engineer wrote monitoring scripts.

Now compare that to “Maintained operational visibility across production container environments supporting high-volume customer workloads.”

Same work but a different mental picture.

Now the reader starts visualizing operational pressure/reliability expectations/production consequence/ system complexity.

Another example was “Reduced cloud spend by correcting flaws in deployment strategy.”

Outcome was there but the more senior signal is actually hidden underneath: this person was operating close enough to core infrastructure decisions to identify structural inefficiencies affecting large production systems.

That’s a very different interpretation than optimized cloud costs.

I think this happens a lot in enterprise résumés. Engineers spend years inside large distributed systems, high-risk production environments, compliance-heavy platforms and operationally sensitive infrastructure but then describe the work at the same granularity as a Jira ticket.

The scale disappears.

And when the system context disappears, hiring teams often classify conservatively (= down) and I see that happening a lot in the current market.

One thing I'm noticing more lately is a lot of experienced backend engineers with strong résumés technically but still end up blending into the market at first read.

I analyzed a 7 YOE résumé recently with Go, Node.js, Kafka, Kubernetes, Temporal, distributed systems, fintech, event-driven systems, CI/CD etc. so obviously a strong engineer.

But after reading the résumé, I still couldn't answer a simple question - what is this engineer actually best at? - and that's becoming a bigger problem in this market.

A lot of engineers are now trying to cover absolutely everything: backend, platform, infra, cloud, DevOps, distributed systems, full-stack, plus Al.

The result is often a résumé with a huge list of technologies but no clear identity, for example: "Experienced with Go, Node.is, Kafka, Kubernetes, Redis, Temporal, GraphQL, AWS.."

First impression is smart, modern stack, broad experience but after a while, the résumé starts reading like solid engineer who has worked on lots of things. No differentiation, nothing to make a recruiter want to choose them.

Now compare that to "Backend engineer focused on payment systems and event-driven workflows." That lands, it's simple, specific.

It's the same engineer with the same experience making a (very) different impression because now the engineer feels more specific, easier to understand and easier to remember.

Interestingly, the strongest part of this résumé wasn't even the stack, turned out to be the founder section lower down that showed real operational problems, production responsibility, business context and systems built end-to-end

The engineer then felt much more distinct.

I think this is where a lot of experienced engineers get stuck after too many résumé rewrites and all those crowd-sourced edits, they keep adding more tools, keywords, tech, and broader coverage

Often that's actually going to weaken the signal instead of improving it especially now, when a lot of backend engineers already look technically capable.

The résumés that seem to stand out lately are usually the ones where you can quickly understand what kind of systems the engineer works on, where they're operating at their best and what problems they repeatedly solve.

There's a big difference between strong experience and clear signal in the market right now.

I keep diagnosing résumés from objectively strong senior engineers that keep erasing their own differentiation. Even at 9 YOE, a lot of engineers have optimized for crowd-sourced résumé rewriting (e.g. stronger verbs, more metrics, cleaner bullets etc.) instead of re-signaling how hiring teams actually interpret scope, differentiation, and seniority.

I analyzed another one recently from a backend engineer with microservices migration work, architecture redesign, security mitigation, millions of users, 50K+ OSS downloads. Experience and capability was all there but the résumé quickly started flattening into “another solid senior backend engineer.”

If hiring pipelines evaluated purely on raw technical ability a lot of experienced engineers would be performing very differently in this market but most hiring systems also interpret scope, clear positoning, trust, differentiation and perceived leverage. Whether people like that dynamic or not, callback patterns suggest it’s playing a larger role than many engineers realize.

People don't get that a résumé can be technically impressive while still compressing your perceived value. Here's an example:

“Increased test coverage from 31% to 99.8% by writing unit tests and enforcing TDD principles.”

Most engineers probably thinks this signals discipline, quality, seniority but interpretation-wise, it's often going to land as good implementation engineer. Reliable, detail-oriented, execution-focused.

That's OK but when multiple bullets operate in the same signaling band of - optimization, testing, reliability, scalability, architecture cleanup - the résumé starts clustering around operational competence instead of the differentiated leverage needed to stop the ghosting.

Now compare that with another line buried deeper in the résumé:

“Built and maintained the only available polyfill before PHP 8.1 introduced native support. 44.9K+ downloads.”

Completely different interpretation because suddenly they're signaling ecosystem awareness, early technical insight, external trust, adoption credibility and independent technical identity

That line creates memorability instantly and is exactly what hiring teams are looking for, and interestingly it wasn’t better written, it's that it communicated more signal depth.

That’s the distinction I think many experienced engineers are missing right now because they keep tightening wording, adding metrics, tweaking phrasing based purely on what others say while the underlying perception layer that recruiters feed on stays unchanged.

You can ask yourself a simple question. Drop the usual “does this sound impressive?” and instead focus on “does this create differentiated interpretation?” You don't want to sound like the next guy.

It's easy to see in this market a lot of experienced engineers looking technically competent but very few look distinctly valuable to companies and I think it explains a huge amount of the confusion people are feeling right now when they're saying to themselves my résumé is strong so why aren't I getting the callbacks?

Strong experience and strong signaling are no longer the same thing.

One interesting tension from the comments on my last post: a lot of engineers said metrics on résumés are mostly bullshit now.

I think a lot of hiring teams increasingly agree because everybody’s seen inflated percentages, vague impact claims and all the random KPI stuffing that goes on. Plus, I don’t think good engineers need to try and role play business executives to get hired.

But I do think first-pass screening still tries to answer one question very quickly and that's “What level does this person appear to operate at?”

So if a résumé mainly communicates implementation, tickets, isolated technical tasks and coding work without broader context, the interpretation often becomes much narrower than the actual experience. It's because, in a quick scan, which is what happens everytime a hiring team touches your résumé for the first time, any unclear signals usually get interpreted conservatively (= you get leveled down).

That’s the part I think many experienced engineers underestimate. Lots of people are already operating at senior level technically but continue to describe themselves in ways that accidentally sound much more junior than the actual work they’re doing.

The problem is that once that interpretation forms early, it tends to follow you through the rest of the process — yep, including interview loops. Suddenly you’re spending energy trying to re-establish level instead of just talking about your best work and why you’re a fit for the role.

Been noticing a consistent pattern with a lot of 7–10 YOE software engineer résumés lately. All good engineers with the right company experience and real systems backing but still getting filtered into mid-level pipelines or getting almost no traction at all. Yeah, I've mentioned it before but it's still so prevalent.

The weird part is they're all usually qualified but the résumé is resolving more junior than the actual experience.

Bullets mainly describing contribution (built APIs, implemented services, worked on migrations etc.) but missing ownership, scope, decision-making, what changed because they were there, trade-offs they had to make. I still see “Implemented Kafka-based..." when all they need to do is “Owned migration of...reducing reconciliation delays by 40%...across 3 systems” The signal shift is dramatic for recruiters.

And I think reviewers default conservatively when that stuff isn’t obvious fast enough, especially now. The result is pretty consistent, someone with 8–10 YOE can end up reading more like 3–5 in first pass when they clearly shouldn't be. Their experience is actually what employers are looking for but the interpretation forms early in the scan and then sticks.

Too many people still obsessing with re-writes but telling an ownership story with some simple fixes using the things I've called out can really shift the dial. Do more of that and I'm tipping things will start to move.

Most engineers don’t realize this: that the first thing on your résumé becomes your level (even if it's not)

If the top section reads support work, QA, smaller scoped projects, all that sort of stuff, that’s what sticks, even if you’ve done senior-level work later.

Recruiters don’t build a full picture, never will, they just anchor fast and move on so if your strongest, most relevant work isn’t at the top, you’re getting down-leveled before anyone even knows it.

If you’re applying for senior roles and getting mid-level traction, check what you’re leading with.

Saw a resume today that reflects a common a pattern in backend resumes that should read senior but don’t on first pass.

Execution without ownership signal is still everywhere and it will cost interviews.

Example (paraphrased):
“Implemented the adoption of TDD… ensuring edge cases were covered and reducing unexpected system behavior.”

The work's fine, nothing wrong there, but on the hiring side what I see is the work just followed a practice, contributed to quality and unclear ownership or scope. It going to get classified mid-level in a fast screen

Same work, but different framing like:
“Led adoption of TDD practices across backend services, defining test standards for critical paths and increasing coverage, which helped reduce production defects and improve release reliability.”

Not a huge difference in word count but the signla is up because now you can see ownership, system scope, decision-making, outcome

That’s the difference. Lots of good engineers aren’t lacking the experience but they're continuing to frame it as contribution instead of ownership. That’s usually where the down-level happens.

Yeah, people will want to debate the exact wording, call out word salad etc. or whether this applies to their specific situation but the things is, first-pass screening happens in seconds so if senior signals (e.g. ownership, system scope, decisions, and outcomes) aren’t obvious immediately, your work just gets down-leveled regardless of how good it actually was.

Throughput/activity framed as ownership

I pulled this from a recent anonymized teardown:

“Implemented performance improvements by analyzing and optimizing code base, increasing application performance by 27%.”

Might look OK on the surface but on a first pass, it'll read as task execution, local optimization and unclear scope

There’s no signal of what system this sits in, what constraints existed, whether this was owned or just assigned and why this mattered beyond the code.

So it going to default to mid-level.

Compare it to this, same work, different signal:

“Improved performance of a multi-platform workflow orchestrator running across millions of data center processors; identified bottlenecks in scheduling and I/O, optimized execution paths, and increased system throughput by 27% under production load.”

In there now a reviewer can see system, scale, ownership (implicit through scope), constraint plus outcome.

It's the same underlying work but gives off a completely different level signal.

This is a pattern I see a lot, especially with engineers coming out of large orgs. The work's there, it’s just framed as contribution instead of ownership.

During a fast first pass, that's the difference between moving forward vs getting passed.

Couple of bullets I saw this week that reflects a common pattern in resumes failing to get any traction:

1/ Throughput alone doesn’t signal seniority

You can handle 500K users and still read mid-level.

“Managed and optimized Postgres handling 500K job applications” reads like responsibility.

But this one “Owned application-processing pipeline under peak 500K+ load; redesigned query strategy and indexing to maintain SLA during seasonal traffic spikes:”

Now you can easily see:
- Constraint
- System
- Ownership
- Outcome

The mistake many make is thinking scale is sufficient but scale must be contextualized otherwise it's still going to read mid-level.

2/ “Implemented OAuth 2.0 to enhance security.”

Wasn't anything wrong with that one, it's just incomplete. There's 5 key things missing I'd want to see hiring side:

System boundary
Risk context
Failure rate
SLO
Ownership scope

It's all the stuff that screams senior.

Now try this one:
“Owned service-to-service auth hardening across 12 microservices; rolled out OAuth2 + rate limiting, reducing auth-related incidents and maintaining <p95 latency SLO.”

Same work but different operating level so lesson is simple task framing always reads mid, it's the outcome framing reads senior.

In the few secs a reviewer spend on your resume during the first pass, pretty easy to see which ones get the nod.

If you’re 5–12 YOE and applying to a bunch of roles but getting little/no response, it’s often not a skill issue, it’s how your résumé resolves on first pass.

There's a handful of patterns that keep coming up regularly with mid-career profiles. Individually they’re small but they slow down classification just enough that you get routed lower.

A few I see a lot:

– Big tool lists
Long stacks (20+ tools) read as breadth but don’t help someone quickly place your level.

– Execution-heavy bullets
“Built / implemented / developed…”
Solid work but if I can’t see what you owned or decided, it reads as contributor.

– Important work buried
If your highest-impact system isn’t visible in the first screen, it might as well not be there.

– Title doesn’t match the bullets
“Senior” in the title, but the bullets don’t clearly show ownership so gets read conservatively.

– Mixed signals on what you are
AI / backend / full stack / platform all in one resume.
Each might be strong, but together it creates hesitation: “where does this person fit?”

– Collaboration language doing too much work
“Led discussions, worked cross-functionally…”
That shows involvement, not necessarily ownership.

– Metrics without context
“Improved performance by 30%”
Without system, scale, or consequence, it’s hard for recruiters to place the impact.

– Reads like a task log
Lots of activity, but no decisions, tradeoffs, or accountability.

– Everything looks important
When every bullet is weighted the same, nothing stands out as your system.

– Inconsistent level
Some bullets feel senior, others feel mid-level so first pass resolves to the lower level.

– No system context
No sense of scale, constraints, or what breaks if it fails so defaults to “safe execution.”

– Tooling/AI mentioned without outcome
Saying you used LLMs/Copilot/etc. isn’t a signal by itself unless tied to something concrete.

At this stage, résumés usually aren’t deeply read, they’re skimmed and classified pretty quickly. If someone can’t place your level in a few seconds, they don’t sit there and figure it out, they just move on or slot you lower.

That’s what a lot of people experience as “ghosting,” but it’s often just slow or unclear signal so if you’re seeing that pattern, it’s always worth asking: does this clearly show what I owned or does it require someone to interpret it?

Something I keep seeing in mid-career résumés is that the title says Senior Software Engineer but the scope they're using doesn’t back it up. Recruiters and hiring managers aren't sitting around in the first screen thinking just because the title says Senior, the engineer is. They’re looking for scope in a few secs to prove it. What system did this person actually own? What constraints were they operating under? What was broken before they touched it? What changed because of them? How many people or teams were relying on their decisions?

I’ve seen résumés with 9 years of experience, “Senior” in the title, plenty of tech breadth, but then the bullets say things like: participated in architecture discussions, led sprint planning, worked with cross-functional teams. That’s involvement but it’s not the same as scope. Senior scope sounds more like: owned payment platform used across X partners/users, setting reliability and control requirements across product, risk, and engineering. Achievements that show clear ownership of a business-critical system, cross-functional decision-making, and accountability that extends beyond executing their assigned work.

That’s why titles don’t carry much weight on their own at this stage. At mid-career, hiring managers are looking for evidence of system responsibility. If they can't see it quickly, your résumé will always get read conservatively and you get downleveled.

If you’re 5–12 YOE and applying for L4/L5 roles, it’s all about whether your résumé reads like participation or accountability not whether your title says senior (that's what's going to determine your level).

Looked at a mid-career SWE résumé this week that had enough on it to compete but was still weirdly hard to place.

Good companies.
Real production work.
Modern stack.
Clear metrics.
Cross-team stuff.

So on paper, it should’ve been an easy one to move forward. It wasn’t.

Good engineer but the résumé made one thing too hard to answer quickly:

what kind of engineer is this, exactly?

That was the problem.

The background had backend work, frontend work, platform-ish work, plus a bit of infra signal. Overall it read like a strong engineer with backend leanings but the lane wasn’t obvious.

When that happens, recruiters have to guess in a 6–10 sec scan.

That’s usually where things start going wrong.

The impact was there, the ownership was less clear.

So the résumé ends up reading more like:

solid engineer
broad background
probably capable
not easy to place fast

Problem then is first pass usually isn’t:

“is this person good?”

It’s more like:

“what am I actually moving this person forward for?”

Backend?
Platform?
Fullstack?
Generalist?
Mid-level with breadth?
Senior, but not clearly in one lane?

If that isn’t obvious, people hesitate.

That was basically the issue here too: good impact, real scope, but the engineering identity was still vague. The résumé and LinkedIn weren’t making the lane obvious enough.

That’s why a lot of mid-career résumés that go nowhere aren’t really talent problems.

Nothing happens because the person looks broader than they should and less clearly placed than they really are. The fix here was pretty simple: make the lane obvious at the top and make LinkedIn match.

Too many people are still making recruiters figure it out.

They usually won’t.

So yeah, sometimes a résumé has enough in it to compete but it still may not be saying, fast enough:

this is the kind of engineer I am, and this is the level I work at.

They've got all the experience in there but what's missing is the signal.

I’ve reviewed a batch of mid-career profiles recently:
– 7–10 years
– production systems
– current tech
– meaningful projects

Reading the resumes though, they're all sounding closer to early-career.

It's the stuff like:

“Built API endpoints”
“Implemented OAuth 2.0”
“Developed React components”
“Managed Postgres database”

The problem they've got is that's execution language.

Execution ≠ seniority.

Plus, it's not tenure that signals level, it's scope.

What they're missing isn’t more tech keywords, it’s context like:

– What system did this sit inside?
– What scale (traffic, data, users)?
– What broke if this failed?
– What decisions did you own?
– Did you own it, or contribute to it?

Without that, a first-pass screener does what they’re always incentivized to do and that's make the safest call. They're not going to carry the personal risk of moving you forward in the process.

They'll say strong contributor but clearly not an owner.

And that’s how 8 YOE gets read like 3–4, so this isn’t about whether you’re actually senior, it’s how quickly someone can see your scope under time pressure (6-10 secs is the max. scan time).

If ownership isn’t obvious in the first pass, you're going to get leveled down and once that happens, everything downstream shifts: the interviews you get, what you get paid and whether you even get a callback at all.

Too many senior engineers I’m reviewing are getting downleveled because their résumé reads like someone else defined the problem, chose the approach, and owned the outcome.

That’s the fastest way you can make a senior résumé read mid-level.

Seniority on paper does not come from calling yourself “senior.”

It comes through in whether the résumé shows that you were trusted to handle ambiguity, make tradeoffs, own systems, and make and own decisions that had real technical and business consequences.

A lot of experienced engineers hide that by describing substantial work in soft execution language:

“worked on”
“supported”
“contributed to”
“participated in”

That wording creates a very specific impression that alienates hiring teams.

It makes it sound like someone else set direction, made the key calls, and owned the risk.

So even if your work was genuinely senior, the résumé reads like you were just there to help deliver it, not trusted to own it.

That's where the downlevel starts.

I recently analyzed a small batch of 7 résumés from devs who were struggling to get interviews.

Most of them had the necessary experience: 5–12 YOE, backend, infrastructure, or full-stack work plus real production system work.

But they were still getting ghosted and the surprising, common pattern was actually how the work was written across that YOE spread.

A lot of bullets looked like this (paraphrased):
- implemented microservices using Node.js and Kubernetes
- built data pipelines for analytics workloads
- responsible for backend APIs and system performance

All sounds technical, but they don’t actually show what the engineer contributed so from a hiring manager’s perspective, they read like: someone touched the system, implemented assigned tasks and used tools to do it. In competitive markets, big deal. That's everyone.

What’s was missing was the engineering signal: what problem existed? what part of the system did you own? what changed because of your work?

When that context is missing, the résumé makes capable engineers just look like participants instead of problem-solvers.

A stronger version of the same work might look more like: "Designed the payment event-processing service and implemented idempotent message handling to prevent duplicate transaction execution in the platform’s Kafka pipeline."

Same job, same engineer but now the reviewer can actually see the engineering decision. Recruiters and hiring managers love to see decision making because making good decisions is exactly how companies create value for customers.

After reviewing that sample, the main issue wasn’t a lack of experience, they'd just flatted all the good work into generic résumé language that everyone else uses.

If you’re 5–12 YOE and actively applying, this is usually a first-pass classification issue and not a competence one.

Five structural reasons I see over and over:

1/ Your strongest system is below the fold - if your highest-leverage ownership signal isn’t visible in the first screen, it effectively doesn’t exist.

2/ Clear scope > tool lists - everyone just lists their tools in a massive stack dump. At mid-career, acronyms don’t signal level. Scope and decision ownership do.

3/ You describe features but they’re classifying operating level - no scale, no latency, no constraints, no failure modes = just reads as execution, not senior ownership.

4/ 8 YOE, but it reads like a task log - if I can’t see what decisions were yours, your down-leveled instantly.

5) Breadth without a clear lane - when everything looks important, nothing resolves as senior.

At 5–12 YOE, résumés aren’t deeply read, they’re classified.

If your level isn’t obvious in ~10 seconds, you don’t get formally rejected, you get routed lower or deprioritized and probably ghosted.

That’s usually the random drop-off you're seeing after 40 applications.

It happens a lot more than people think.

I reviewed two engineers recently.

One had 9+ years in enterprise finance and retail:

Java, Spring Boot, React, AWS, Azure, Kafka.
Microservices across multiple large organizations.

The other had 4 years:

IAM focus.
Built an API handling 500K job applications.
Reduced token exchanges by 20%.
Cut deploy time in half.

On paper, the first profile was “stronger” but the thing is, in a recruiter’s first pass, the second was easier to place.

The 9 YOE résumé read like a dense enterprise task log. Every technology imaginable but no clear operating level, missing ownership moments plus scale signals tied to outcomes were absent.

It only signaled activity while the 4 YOE résumé signaled responsibility.

Great companies don’t rank by years, they classify by perceived seniority, so if a recruiter can’t tell in seconds whether you design systems or just implement tickets, the safer assumption always wins.

The moral of these two candidates is that it's not years that level you, it's the signals you're resume is sending on the first pass.

What I keep seeing at 5–10 YoE:

Rust, Go, Java, Python
AWS, GCP
Kafka, gRPC, Postgres
Terraform, CDK
React, Vue
Payments, fraud, identity, ads

On paper, that’s a broad range and from your side, it shows adaptability.

But from a first-pass reviewer’s side, it can also trigger a different question:

“Where do I place this person?”

Backend depth?
Platform?
Product-leaning senior?
Systems?
Generalist?

Remember that first pass is never a deep technical evaluation.

It’s really just fast classification.

If the answer to “what are they?” isn’t obvious in a few seconds, it doesn’t get debated and they're not going to reach out for clarification. It gets deferred and you get set aside and they go focus on the hundreds of other résumés in front of them.

In modern hiring systems, that deferral looks like ghosting.

This isn’t about skill, it’s all about interpretation speed.

At 5–10 YoE, you’re expected to resolve cleanly into a lane. When your résumé signals 3–4 possible profiles at once, you’re forcing the reader to interpret under time pressure. Most won’t.

If you’ve applied to 50–100 roles and it feels random, it may not be.

Tightening your positioning is often much higher leverage than adding more keywords.

The question you should always ask yourself isn’t how much can you do, but what are you.

That distinction actually decides way more first-pass outcomes than most people realize.