Which job requirements are must-haves and which are copy-paste?

Which job requirements are must-haves and which are copy-paste?

A must-have requirement is one the work fails without in the first weeks on the job. Every other line on a technical job description is a preference, a proxy for something else, or text copied from an earlier req. On a typical engineering description, the must-haves are two or three lines out of ten.

The test that sorts them is short. For each requirement, name the thing this person does in week one that fails without it. A payments company hiring someone to work on money movement can name it: the ledger code is in Java, the person edits it on day three, and Java at working depth is load-bearing. For the line that says "experience with Kafka" on the same req, nobody can name the week-one failure, because the one engineer who touches Kafka sits on a different team. That line came along from a previous description.

Sorting a req this way is the highest-leverage half hour in the whole intake. Every line that survives narrows the pool of people who can be approached, so each copied line that stays in costs real candidates. The sections below give the categories: what makes a line load-bearing, what a nice-to-have does, what a proxy is standing in for, and which technology lines collapse once the transfer table is applied.

What makes a requirement load-bearing?

Load-bearing is a term from construction. A load-bearing wall holds the building up, and removing it brings the structure down. A decorative wall can go without consequence. The metaphor maps directly: a load-bearing requirement is one the job collapses without, and the rest of the list is decoration that reads as structure.

Three kinds of requirement pass the week-one test almost every time.

The first is the specific systems the person touches immediately. If the team's product runs on a monolith being split apart, the brownfield experience described in the hiring manager's own phrases is real. The person changes a live system in week one, and someone who has only done greenfield work will struggle immediately.

The second is the domain. A req at a medical-imaging company that requires familiarity with medical data formats is describing week-one work, because the data arrives in those formats on day one. Domain knowledge takes months to build and the product cannot pause while it does.

The third is legal and regulatory constraint. A role that requires a security clearance, or work authorization in a specific country, or experience with a regulated compliance regime has a requirement no amount of talent routes around.

Notice what the three have in common. Each one is anchored to the actual work or the actual rules, so each one survives being questioned. A line that survives only because it has always been on the list is the other kind.

What is a nice-to-have?

A nice-to-have requirement shortens ramp-up rather than deciding whether someone can do the job. The candidate who has it starts contributing a few weeks sooner. The candidate without it arrives at the same place a few weeks later, and a strong engineer closes the gap on the job.

Most technology lines on a req are nice-to-haves wearing must-have clothing. "Experience with PostgreSQL" on a backend req usually means the team uses PostgreSQL as its database. An engineer who has run a different database at the same layer of the stack has the durable knowledge already, and the PostgreSQL specifics are the small remainder. The line is honest as a preference. As a filter it removes people who would have been productive within the month.

The useful move at intake is renaming rather than deleting. A hiring manager who hears "should we cut this?" defends the line. A hiring manager who hears "does the work fail in week one without this, or does it add a few weeks of ramp?" usually sorts the line correctly themselves, because the week-one framing is one they can answer from the actual work. The sorted list then has two sections, and the rewritten description can say which is which.

What is a proxy requirement?

A proxy requirement stands in for something else the writer actually wants. The degree requirement is the classic case. "Bachelor's degree in computer science" almost always stands in for "can reason about problems in a structured way", and the industry's own record undermines the proxy: many strong working engineers hold no degree, and open-source careers have made the underlying ability directly visible in public work.

Years-of-experience lines are the other big family. "Five years of Python" stands in for depth, and depth comes from the difficulty of the systems someone worked on rather than from elapsed time. Two engineers with five years each can sit at very different depths, and one with three years on hard systems can outrank both.

The test for a proxy is to name the quality behind the line and then check whether that quality can be observed directly. Problem-solving shows up in the systems someone has built and in their public code. Depth shows up in what they shipped and owned. Communication shows up in their writing, which is public in every pull request discussion they have taken part in. When the direct observation exists, the proxy line is removable, and removing it widens the pool without lowering the bar.

Which requirements collapse under the transfer table?

Most of the technology lines. The transfer table established that skill travels along layers far more than along names: a backend engineer in Java writes useful Go within weeks, an AWS engineer becomes productive on Google Cloud within weeks, and a React developer works in an adjacent frontend framework with a short ramp. Every requirement naming one technology at a layer where transferable skills carry is really a requirement for the layer, plus a few weeks.

So the collapse works shelf by shelf, using the sorting from earlier in the path. "Python required" collapses to "backend engineer, Python-adjacent accepted, weeks of ramp". "AWS required" collapses to "cloud experience on any major provider". "React required" collapses to "frontend engineer with modern framework experience", unless the team is deep in React-specific territory the hiring manager can name.

The lines that resist collapsing are the cross-layer ones. A frontend engineer moving to infrastructure work is months of ramp rather than weeks, because the knowledge underneath is different. A requirement that sits across a layer boundary from the candidate's experience is the one place where the technology line and the load-bearing line are the same line.

Applied honestly, the collapse usually turns a ten-line requirements list into one load-bearing layer, one or two genuine must-haves, and a set of equivalents-accepted preferences. That shorter spec describes a pool several times the size of the original.

What happens when the codebase is in a language the candidate does not know?

The candidate learns it, and at companies with strong engineering cultures this is routine rather than exceptional. Several well-known engineering organizations hire explicitly for ability and let new engineers pick up the house language during onboarding, because they have watched the ramp happen enough times to trust the number: weeks, for an experienced engineer moving within a layer.

The reasoning follows from what transfers. The durable skills are understanding systems, debugging, and design judgment, and those arrive with the person on day one. The codebase itself does much of the teaching, since it is full of working examples in the house style, and code review from teammates corrects the accent quickly.

Why do requirement lists grow?

Because adding a line is free at writing time and expensive at sourcing time, and the two costs land on different people. The hiring manager who adds "experience with Kubernetes a plus" pays nothing in that moment. The cost arrives later, distributed across weeks of sourcing, as candidates who would have been strong quietly fail a filter nobody remembers installing.

The mechanics of growth are ordinary. A new req starts from a copy of the last one, so every line from the previous search is inherited by default, including the lines that were specific to a project that has since shipped. Then each stakeholder who reviews the draft adds a preference, since reviewing is when adding feels responsible. Nothing in the process removes lines, so lists ratchet upward, and a req three generations deep carries requirements no one present can explain.

This is why the sorting in this lesson has to be an active step rather than a hope. The list does not shorten itself, and every inherited line has a defender in the person who does not remember adding it but recognizes it as familiar. The week-one test gives the conversation neutral ground: each line either has a nameable failure attached or it does not, and the lines that do not can be moved to nice-to-have without anyone losing an argument. What that shorter, sorted list looks like on the page is the subject of the rewrite.