When Everyone Has the Perfect Resume

This one will be a bit more observational than the deep dives I usually prefer.

Based partly on my recent interview with Ameya, I wanted to share a few quick observations about what seems to be changing in the software engineering job market in 2026.

I guess this time you’ll get the shorter version of the Tuesday newsletter :)

I first saw this data on a16z and then found the original chart from Revelio Labs. Since early 2025, the number of skills mentioned in tech job postings has been declining, while the preferred years of experience have been rising.

The shift isn’t huge, but the direction is interesting, especially when you compare it with some of the patterns below:

Applying to more jobs used to be a fairly rational strategy. If your chance of getting a response from one application was low, sending more applications increased your chances.

AI has pushed this logic pretty far. You can now find hundreds of vaguely relevant jobs and apply to most of them with almost no effort. But when everyone can do that, employers receive more applications without necessarily receiving more good candidates.

So I don’t think the advantage is in applying faster anymore. The interesting part is deciding which jobs are actually worth applying to. Ten applications where the company, level, and work genuinely make sense may tell you more than another hundred generated by an auto-apply tool.

The same thing may be happening with resume tailoring.

The standard advice is to adjust your resume for every job description. There is some logic to this, but LLMs have made it possible to take it to a strange extreme. You can now have a slightly different version of yourself for every company you apply to.

I’m not sure this helps much.

If you know the type of companies and roles you want, one resume should probably fit 80–90% of them. You may swap a few bullets for genuinely different roles, but if the whole resume needs to change each time, something is probably off about either the targeting or the resume.

I recently spoke with a tech recruiter at a Dutch scale-up, and she told me they still screen every tech resume manually. No keyword matching decides who moves forward. What they actually want is to understand the human behind the resume.

She also mentioned how many extremely polished, almost clinical resumes they receive now. You can often feel that ChatGPT has been used to optimize every sentence, add the right keywords, and make everything sound perfect. But for them, that doesn’t really give the candidate any advantage.

I noticed something similar during our latest resume review session for paid subscribers last week. A few resumes were almost entirely technical, keyword- and process-oriented. Lots of technologies, metrics, and polished bullet points, but after reading the whole thing, it was still difficult to understand what kind of engineer the person actually was.

I think this is one of the downsides of trying to AI-optimize every resume. Knowing a long list of technologies matters less than it used to. What becomes more important is whether the resume gives me a clear sense of what you’ve built, how complex the problems were, what you owned, and how you actually work.

“Senior Software Engineer” doesn’t tell you much on its own. Neither does ten years of experience. Two engineers can have the same title, similar years of experience, and almost the same stack while having worked on completely different problems.

The useful details are usually somewhere underneath. Millions of users. A system that couldn’t go down. An architecture that had accumulated ten years of constraints. A difficult migration. Performance problems. Ownership of something where a bad decision was expensive. A product problem with no clean technical answer.

Maybe this is partly what employers are buying when they ask for more experience. Not another year of writing the same kind of code, but a higher probability that you’ve already seen difficult things.

There’s a related change in what companies seem to expect from senior engineers.

Being very good at implementation is obviously still useful. But the boundary of the job seems to be expanding: architecture, product thinking, mentoring, working with other teams, understanding the business, making trade-offs, owning something beyond your own code.

AI makes this more noticeable because implementation is one of the parts of engineering where it can already help a lot. If writing the first version becomes cheaper, more value shifts to deciding what to build, how it should work with everything around it, and whether what you produced is actually good.

This doesn’t make coding less important. It just makes “I can write good code and cover everything with unit tests” an incomplete description of a senior engineer.

When good interviews are harder to get, each one becomes more valuable.

This changes the timing of preparation. The old sequence of “search first, prepare once interviews arrive” becomes risky if it takes weeks to generate another good opportunity.

I’ve heard enough stories of engineers finally getting an interview with a company they really wanted, only to realize they hadn’t done a technical interview in two years. By the time they’re back in shape, that particular opportunity is gone.

So searching and preparing increasingly seem like parallel activities rather than two stages of the same process.

I still think LLMs are extremely useful for the job search. Just perhaps not in the most obvious way.

Instead of giving an LLM one vacancy and asking it to rewrite your resume, give it 5 or 10 jobs you genuinely want. Ask what patterns it sees. Which requirements keep appearing? Which parts of your experience seem weak? Which bullets on your resume don’t help with any of these jobs? What would be unclear to someone reading it for thirty seconds?

That preserves something important: the resume is still yours.

The LLM is looking for problems/patterns rather than producing a new version of you for every application.

Perhaps the biggest change is that a job search now produces enough feedback that you can debug it.

If you send relevant applications and nobody responds, that’s one problem. If recruiters respond but you don’t get through the first interview, that’s another. If you regularly reach final rounds, that’s another again.

The loop is fairly simple:

Pick a target → Apply → Measure → Find the bottleneck → Change one thing → Repeat

No responses → look at targeting or the resume.
Interviews but no progress → look at interview performance.
Final rounds but no offers → look at what stronger candidates have that you don’t.

The useful question isn’t simply how to get more applications into the top of the funnel. It’s where the funnel is breaking.

This way of thinking comes naturally to engineers. You wouldn’t keep sending more traffic through a broken system and hope it fixes itself. Yet that’s often how people search for jobs: more applications, more resume rewrites, more referrals.

And if you missed last week’s hand-curated job list, you can find it here. We’re getting close to 10,000 jobs shared, and my team carefully preselects every one before we send it to you.

Stay in touch ✌️

Andrew