How do you spot and fix an impossible job description?

How do you spot and fix an impossible job description?

You spot one by counting. Count how many jobs the description contains, count how many of its requirements are load-bearing, and count how many candidates could plausibly exist. A job description is the document that states a role's responsibilities and its requirements, and an impossible one is a description whose requirement list describes a person who is vanishingly rare or does not exist.

Impossible descriptions are common, and they are rarely written on purpose. They accumulate. One line comes from the last req, one from an engineer's wishlist, one from a template, and nobody is charged for the additions until sourcing starts. The fix is the same set of moves every time: split the stapled roles apart, translate proxy lines back into the work they stand for, and cut the phrases that push strong candidates away. The sections below walk through each move on the classic offenders.

How many jobs is this description?

The fastest test is the Tuesday test: describe the person's ordinary Tuesday. A description covering frontend work, backend services, cloud infrastructure, and machine learning describes three or four different Tuesdays, and each Tuesday is a role.

Software work divides into layers, and the people on a team specialize by layer. A frontend engineer's day is interfaces and browsers. An infrastructure engineer's day is deployment systems and reliability. A machine learning engineer's day is data and models. Individuals who work across two adjacent layers are common. Individuals with real depth in all three are rare enough that a req depending on one has quietly chosen a sourcing project measured in months.

The fix is a decision, and it belongs to the hiring manager: which Tuesday is the actual job? The other layers become collaboration lines, meaning the person works with an infrastructure team rather than being one. A description that says so reads as honest, and honest descriptions get replies from people who match them.

What is a purple squirrel?

A purple squirrel is a candidate profile that combines requirements almost nobody holds at the same time. The term is recruiting slang, and the engineering version has a specific origin: reqs produce purple squirrels by accumulation. No hiring manager sits down and decides to require a rare combination. Each line was reasonable on its own. Stacked together, they describe an animal that does not exist in the forest.

The tell is requirements drawn from separate careers. Deep frontend craft plus production machine learning plus infrastructure ownership is three careers. Ten years of experience plus expertise in a two-year-old technology is a contradiction in dates. When a req has been open for a quarter with strong sourcing behind it, the pool size is the evidence, and bringing that number back to the room is what gets the spec revised.

The fix runs through the transfer table. Requirements in adjacent technologies collapse into one requirement plus a short ramp, and the squirrel usually turns back into a large, reachable pool of ordinary strong engineers.

What does five years of a technology mean?

Very little on its own. Years in a technology is a proxy for depth, and depth actually comes from the difficulty of what someone built. An engineer who spent five years making routine edits to one aging application has five years of React. An engineer who spent eighteen months building a complex product under load has deeper React than that. The number measures calendar time, and calendar time is the input, never the output.

Years of experience does one legitimate job: it sets a floor. Someone with dated professional history is past the beginner stage. Beyond the floor, its predictive power drops fast, which is why seniority is better defined by scope than by tenure.

The fix is to replace the number with the work. "Five years of React" becomes "has built and maintained a large React application in production." The second version is checkable against a real record, it admits the strong engineer with three intense years, and it filters out the weak one with seven quiet ones.

Is a CS degree a real requirement?

Run it through the must-have test: does the work fail in the first weeks without it? For nearly all product engineering roles the answer is no, which makes the degree a proxy. It stands in for problem-solving ability and baseline rigor, and both of those show up directly in an experienced engineer's work record.

The cost of the proxy is measurable. Bootcamp graduates and self-taught engineers make up a large share of working developers, including a long list of celebrated ones, and a hard degree line removes all of them before anyone looks at what they built. After a few years of professional work, the record of shipped systems predicts performance far better than the credential does.

The degree stays load-bearing in a narrow band: research-flavored roles, some machine learning work on the building side, and roles where a regulation or a customer contract requires it. Outside that band, the fix is to move it to nice-to-have or delete it, and to say "or equivalent practical experience" when the hiring manager wants a rigor signal kept.

Which phrases repel engineers?

Developers read job descriptions the way recruiters read resumes: fast, pattern-matching, with learned translations for common phrases. "Rockstar" and "ninja" translate to a team that talks about heroics instead of process. "Wear many hats" translates to undefined scope. "Fast-paced environment" translates to long hours and interruptions, and "work hard, play hard" translates to the same thing with a foosball table. These readings are unfair to some of the teams using the phrases, and the phrases repel candidates anyway, because developers filter high-volume text on specifics and these phrases are the opposite of specific.

The absence that costs the most is the tech stack. The stack is the first thing an engineer looks for in a posting, because it tells them whether their skills apply and what their daily tools would be. A description that hides it gets skipped by exactly the careful readers the req wants.

The fix is substitution: every vibe phrase becomes a fact. The stack gets listed. "Wear many hats" becomes the actual list of responsibilities. If the role carries on-call duty, the description says so and says how often, because the engineers who accept it knowingly stay.

What does "AI experience preferred" translate to?

In almost all cases it means the using side: building product features on top of existing models through their APIs, which is ordinary backend work with a new dependency. That pool is large and growing, and most strong product engineers can ramp into it quickly. Written as "preferred," the line is close to harmless and close to meaningless at the same time, since it neither filters nor describes.

The danger is the other reading. If the team actually needs someone to train or fine-tune models, "AI experience preferred" is the wrong sentence, because the building side is a different discipline with a far smaller pool and a research-shaped background. A description that means the building side has to name it: the data, the training work, the deployment of models. A description that means the using side does better naming the product work instead, since "experience integrating model APIs into production features" is checkable and specific where "AI experience" is neither.

What does the rewritten description look like?

Shorter, checkable, and honest about which job it is. The rewrite keeps one Tuesday. It carries three to five must-have requirements, each tied to work the person touches in the first weeks, and moves everything else to a clearly labeled nice-to-have list. Every years-in-technology line has become a sentence about systems built. The stack is listed. The proxy lines have been translated back into the qualities they stood for, and the vibe phrases have become facts about scope, process, and hours.

The rewritten description also does something the original could never do: it sources for you. Strong engineers self-select into postings that describe real work in their own vocabulary, and the module overview covers how each section of the document carries that weight. A req that once described three stapled jobs and a mythical animal now describes one job and a few thousand real people, and a pool of real people is a thing a recruiter knows exactly what to do with.