Two People Wrote That Job Description and It Shows

An engineering manager opens a shared doc, lists four tools his team actually uses, and describes a database migration that has been rotting for two quarters. Forty-eight hours later the posting goes live asking for fourteen technologies, seven years in a framework that has not existed for seven years, and a passion for thriving in a high-velocity culture.

The engineering request was not replaced. It was buried. Tech job descriptions are written by two authors with opposing incentives, and once you can see the seam between them, you can read what the job actually is in about two minutes.

Two Authors, Two Incentives

I wrote backend code and owned production deployments for eight years before I moved into talent acquisition, and the thing that surprised me most on this side of the table was how the sausage actually gets made. When a team loses a senior contributor or takes on an architectural overhaul, the engineering manager writes down concrete things: we need someone who can optimize PostgreSQL queries, debug distributed tracing in Go, and not break the deployment pipeline on their second week.

That draft almost never reaches the careers page intact. The requisition goes to HR, HR applies the template, and then the additions start — compliance language, keywords for the applicant tracking system, and requirement padding meant to reduce the volume of applicants a recruiter has to screen. By the time it publishes, the manager’s three precise needs are buried inside a wishlist assembled by someone who has never opened the repository.

This is not a conspiracy and the recruiter is not the villain. The two authors are solving different problems. The manager is solving a technical bottleneck. The recruiter is solving for screening volume and hiring risk. But if you read the document as one coherent statement of truth, you will either eliminate yourself from a job you could do or walk into an interview prepared for the wrong role.

Where the Engineer’s Fingerprints Are

The manager’s voice leaves specific marks. Version numbers. Named infrastructure. A described problem rather than a described person. When a posting says “PostgreSQL 15+, Go 1.22, Kubernetes, Kafka,” an engineer read that draft. They told you exactly what you will pull to your laptop on day one.

Vagueness in the technical section means the opposite. “Experience with a mix of modern technologies” or “familiarity with cloud platforms” means the recruiter never got a stack list, or got one and did not think it mattered enough to keep. A team that will not name its primary database in a posting for a backend role is telling you something about how much engineering input survives its internal processes.

• The fourteen-technology laundry list. React, Python, Java, Rust, AWS, Kubernetes, GraphQL, Snowflake, and Terraform for one backend seat was not written by a lead engineer. It was stitched together from the skill tags of three separate teams.
• Years that exceed the technology. If a posting asks for more years of experience than the framework has existed, nobody technical reviewed it. This is the easiest tell in the entire document and it costs you ten seconds to check the release history.
• “Wear many hats” at two hundred people. At a five-person seed startup that is an accurate description. At a two-hundred-person company it means missing platform teams and undefined ownership boundaries, and you will find out which on your third week.
• “High-velocity environment.” Occasionally this means good shipping cadence. More often it means product priorities move faster than the roadmap and engineering absorbs the difference.

Requirement Inflation, and a Statistic Worth Examining

Recruiters over-specify because over-specifying feels safer than under-specifying. Harvard Business School’s Dismissed by Degrees report, led by Joseph Fuller with Burning Glass Technologies, documented this for educational requirements specifically — postings demanding bachelor’s degrees for roles where the existing workforce, performing the same job well, largely did not hold one. The report is from 2017 and its subject is degree inflation, so I will not stretch it further than that. But the underlying behavior it describes is the same one that produces a seven-year requirement on a four-year-old framework.

There is a related claim you have certainly encountered: that women apply only when they meet 100% of listed qualifications while men apply at 60%. It gets cited constantly, including by people in my profession. It traces to an internal Hewlett-Packard report referenced in a 2014 Harvard Business Review piece by Tara Mohr, and to my knowledge the underlying survey and its methodology have never been published.

I bring it up because of where we are in this article. A number with no published methodology has been repeated for over a decade by an industry that writes requirements it cannot justify, and almost nobody checks the source. That is the same failure mode as the fourteen-technology list. Whether the specific split is 60 and 100 or something else, the behavior it points at is real and I have watched it: strong candidates disqualify themselves against a list that the hiring manager never wrote and would not defend.

So treat the padding as padding. If a senior posting asks for seven years in one framework, assume several of those years are screening buffer. If you can manage the data layer, write clean interfaces, and ship without breaking the pipeline, you meet the criteria that actually exist. The recruiter’s list is negotiable. The manager’s problem is not — and reading the posted compensation band the same way is a separate exercise Arthur Sterling covers in his breakdown of what a posted range actually commits an employer to.

The Euphemisms for Technical Debt

In Stack Overflow’s 2024 Developer Survey, technical debt came in as the leading frustration at 62% — roughly double the next items on the list, which were the complexity of build and deployment tooling at about a third each. That is what developers say the job is. It is almost never what the posting says the job is, because no company writes “our monorepo is unmaintained and test coverage is under ten percent.”

So the two authors collaborate on translation. The manager admits the service needs rewriting; the recruiter turns it into an opportunity. Here is the conversion table I use:

• “Legacy modernization opportunity” → A decade-old monolith with no test coverage and partial documentation, refactored while it stays up in production.
• “Opportunity to shape engineering culture” → No coding standards, inconsistent review, and deployment that depends on someone’s scripts.
• “Pragmatic approach to technology” → Infrastructure work does not get budgeted until an outage forces it onto an executive’s calendar.
• “Greenfield development in an enterprise environment” → You will build something new, and spend half the schedule on security review, compliance sign-off, and integrating with an identity system older than the project.

None of these are automatically disqualifying. I have placed excellent engineers into legacy modernization roles who knew exactly what they were taking on and priced it accordingly. The problem is arriving without knowing.

The Question That Cuts Through It

Once you reach the technical round, your job is to get past the marketing layer and verify the manager’s actual environment. Ask about mechanics, not culture. Culture questions get culture answers.

“The posting mentions React and Kubernetes alongside some legacy Django templates. Walk me through the path a commit takes from a local branch to production. How often does CI break, who owns triage when a release fails at two in the morning, and roughly what share of a sprint currently goes to refactoring versus new features?”

That does three things at once. It signals you have operated real systems. It reveals whether the modern stack in the posting runs in production or lives in a sandbox somebody built last year. And it forces a number out of the manager about operational toil.

The answer is the signal, and so is the hesitation. Vague deflection about agile flexibility means the posting inflated the team’s maturity. A manager who tells you plainly that thirty percent of the sprint goes to fixing pipelines has just given you an honest read on the job and told you something about how they will treat you once you are inside. I would take the second team over a cleaner-sounding first one almost every time.

What the Recruiter Screen Tells You

How a recruiter handles a technical question in the first fifteen minutes tells you how tight the loop is between talent acquisition and engineering. In healthy organizations the recruiter knows why the role opened, roughly what the architecture looks like, and who you would report to. They will not debug with you, and they should not have to.

Where the loop is broken, recruiting runs as an isolated keyword filter. Ask whether the backend uses async processing for heavy jobs and you get “let me check whether that’s on your resume.” That is not the recruiter’s failure — nobody gave them the context. It is a fact about the organization.

When you hit that, stop pressing. Use the screen for what it can answer: reporting line, whether the budget is approved, hiring timeline, how many rounds. Save the technical verification for the manager, where accurate answers exist.

A Two-Pass Triage

Instead of treating every bullet as a requirement, run the posting through two passes before deciding whether to apply.

First pass — delete. Cross out soft skills, culture language, and the standard education template. “Self-starter,” “strong communicator,” “bachelor’s degree or equivalent experience.” These are template filler and they carry no information about the work.

Second pass — keep. Highlight only named tools, described architectures, and stated problems. That residue is the engineering manager’s draft, recovered. Compare it against what you have actually built.

If you match most of that residue, apply — even at zero percent on the culture wishlist. And if the residue is empty, if nothing survives the first pass, that is information too. It means no engineer reviewed the document, which tells you roughly what engineering input looks like everywhere else in that company. I have seen where value is migrating in this market, and I wrote about it in The Generalist Collapse — but none of that helps if you cannot read what a company is actually asking for.

A job description is not a contract. It is a first draft written by a committee of two who did not talk to each other enough. Read it that way and it stops being a barrier.