Why Your Engineering Job Descriptions Are Scaring Off the Right People

A senior engineer scanning job listings sees dozens of postings per week. They've developed a fast pattern-matching system for identifying companies worth their time, and most engineering JDs fail it immediately. The signals they look for aren't flattering: a list of fifteen technologies signals that nobody thought carefully about what the role actually requires. “5–10 years of experience” for a problem that could be solved by someone two years out of school signals that the company copied a large-company template without reading it. Vague language about “owning the full stack” in a company with no real description of what the stack is signals that nobody who wrote this has thought clearly about the role.

The JDs that attract strong candidates are rare, which means the field is actually open. Most of your competition is posting the same boilerplate. A job description that clearly describes a real problem, says something honest about the state of the codebase, and treats the reader as a professional — rather than a skill set to be collected — will stand out immediately to the kind of engineer who has options.

The deeper problem is that most engineering JDs are written by people who don't have a clear picture of the role. They're assembled from templates, last year's posting, and a wishlist that reflects anxiety more than planning. The result is a document that describes a role that doesn't actually exist, at a company that doesn't understand what it needs, asking for an impossibly broad skill set that signals low standards and poor hiring judgment. Strong engineers recognize this and move on.

You need to understand what a senior engineer is actually evaluating when they read your JD. They're not checking whether they have the required skills — they're deciding whether the role is interesting, whether the company seems competent, and whether they'd trust you to make good decisions once they're inside. A JD that describes a real problem clearly, shows that someone thought carefully about what the first six months of work looks like, and is honest about the hard parts of the environment will signal all three.

Know the difference between requirements and preferences. A requirement is something the person genuinely cannot do the job without. A preference is something that would be nice to have. Most JDs list preferences as requirements — and this is the single most effective way to filter out strong candidates. A senior engineer who has ten of your twelve listed technologies, and would learn the other two in a month, won't apply if you list all twelve as required. Cut your requirements list to two or three things that are truly non-negotiable and move everything else to a clearly labeled “nice to have” section.

Know what the actual first 90-day problem is before you write a word. Not the general area of responsibility, not the team's long-term vision, but the specific thing you need a person to own in their first quarter. If you can't answer this clearly, you don't yet know what you're hiring for. Writing a JD before you can answer this question produces a generic document that attracts generic candidates. Write the answer to that question first, then write the JD around it.

Start with the first 90-day problem, written in plain language. “In your first three months, you'll take ownership of our payments infrastructure — currently a direct Stripe integration that's starting to strain as we add multi-currency support — and build the abstraction layer we need before we launch in Europe.” This tells a strong candidate what they'd actually be doing, demonstrates that you know what you need, and immediately filters for people who find that problem interesting. It's far more useful than a generic list of responsibilities.

Be honest about the state of the codebase and the environment. “We have a two-year-old Rails monolith that works but has some rough edges we haven't had time to clean up” is a better signal than silence — strong engineers expect imperfection, and honesty about it signals maturity. Describe the decision-making environment: does this person have autonomy over technical choices, or are they executing a defined roadmap? What does the engineering team look like right now? How do you ship? These details separate your JD from the corporate template boilerplate that says nothing.

Cut every technology requirement that isn't truly non-negotiable, then read the list again and cut half of what's left. Consider whether your most important requirement is actually a technology — or whether it's a quality like “can operate independently in a codebase without a dedicated onboarding process” or “comfortable making architectural decisions and defending them.” Strong engineers are defined by those qualities, not by whether they already know your specific ORM. List the technologies you actually use, be honest about which ones are essential, and leave room for people who could learn the rest.

Language that signals a healthy engineering culture: “You'll own the technical direction for this area — we expect you to propose the approach, raise concerns early, and make the call.” “Our codebase is two years old and has areas that need improvement — we'd rather tell you upfront than surprise you.” “We're a team of five engineers; you'll work directly with the founders on product decisions.” These phrases tell a senior engineer that the company is self-aware, trusts its engineers, and operates with honesty. They signal that the person they'd be working for has thought about what it means to make a good engineer's life work.

Language that signals chaos or over-process: “Must thrive in a fast-paced environment” — this phrase has appeared in so many JDs that it now means nothing, and experienced engineers read it as “we don't manage scope well.” “Passionate about technology” — this is noise; every engineer you want is interested in their work, and this phrase doesn't tell them anything about the role. “Strong ownership mentality” listed as a bullet under requirements — this is a value, not a requirement, and listing it alongside technical skills makes the document feel assembled rather than written. “Experience with [10+ technologies] required” — this signals that nobody prioritized; it reads as an anxiety list, not a thoughtful role definition.

The simplest test for your JD: would a strong engineer reading this feel like they were being described as a professional or processed as a skill set? A JD that describes the real problem, the real environment, the real team, and a realistic set of expectations treats the reader as a professional. A JD that lists technologies, years of experience, and culture-fit platitudes processes them. Strong engineers with options choose environments where they're treated as professionals — and they make that judgment, in part, from your job description.