Most engineering job descriptions are assembled from three things: a previous JD for a similar role, a list of required tools and frameworks, and a generic company culture paragraph that could appear on any startup's careers page. The result screens out a large portion of qualified candidates before they ever apply, and attracts a pool optimized more for keywords than for fit.
This is not a minor problem. The job description is the first filter in your hiring funnel, and it is the only one candidates control. They decide whether to apply based on what you wrote. If the writing is unclear about what the role actually requires, or if it signals things about the company that turn off exactly the engineers you want, you will not see them in your applicant pool.
The scope problem
The most common JD failure mode is scope ambiguity. The description uses seniority labels without defining what senior means in this specific context. "Senior backend engineer" at one company means owning a microservice end-to-end and occasionally mentoring a junior. At another it means leading technical strategy across a team of twelve. These are very different roles with very different candidate profiles, and a single title communicates almost nothing.
Strong engineers read job descriptions quickly and make fast judgments about whether the role is calibrated for someone at their level. If the scope is unclear, or if the requirements list signals a level above or below what they are looking for, they move on. A JD that is scope-ambiguous will attract a wide range of candidates, which looks good for inbound volume but bad for funnel efficiency.
Fix this by being specific about what the role's core decisions are. Not responsibilities in the abstract, but the actual problems the person will be working on in the first six months and who they will be working with. A candidate reading "you will own the data pipeline infrastructure serving 3 million daily events and work directly with the ML team to evolve its architecture" knows exactly what the role involves. That specificity attracts people who want that problem and self-selects out people who do not.
The requirements list problem
Engineering JDs typically include a requirements list: five years of Python, experience with Kubernetes, familiarity with distributed systems. This list often grows over time as each hiring manager appends their own preferences until the total is something no real person has.
There is also a well-documented asymmetry in how different candidates respond to requirements lists. Candidates who feel they need to meet all or nearly all requirements to apply will self-screen at different rates depending on various individual and background factors. The longer and more exhaustive the requirements list, the more this asymmetry compounds. If your list has 12 items and a strong candidate meets 9 of them, they may still conclude they are not qualified enough to apply.
The better approach is to separate what is genuinely required from what you can teach. There is usually a short list of real prerequisites: the candidate needs to understand distributed systems tradeoffs, or they need production experience with a specific database, because the learning curve otherwise is too steep for the pace of the role. The rest of the list is often preferences, not requirements. State them as preferences. "Bonus if you have experience with Kafka" is different from "experience with Kafka required" and it attracts a more accurate candidate pool.
What to include that most JDs omit
Strong candidates are evaluating the company and team as much as the role. The things they want to understand from a job description are often not in it: how the team makes technical decisions, what the relationship with product looks like, how code review and deployment work, whether engineers own their work in production or throw it over a wall.
A JD that answers these questions directly is unusual enough to be a differentiator. Consider including a brief description of how the team actually works: what a typical sprint looks like, whether the team tends toward synchronous collaboration or async documentation, how technical decisions get made, what the engineering culture expects from a senior contributor. This does not need to be long; two or three sentences on each dimension is enough to give a candidate a real sense of whether they will like working there.
Compensation transparency is also worth including if your company policy allows it. Engineers are sophisticated enough to look up market rates and estimate whether a role is in range. Omitting compensation adds friction and time to conversations that should happen earlier. Bands do not need to be exact, but "senior engineer comp range is $160-200k base, with equity" removes a common early conversation that often ends in no-hire for reasons unrelated to fit.
The culture section problem
The company culture paragraph is almost universally useless. "We are a fast-paced, collaborative team that values innovation and work-life balance" appears on thousands of career pages. Engineers know this, and they skip it. If your company culture is meaningfully different from competitors, describe it in concrete terms rather than abstract values.
"We run entirely async, write long-form RFCs before starting significant work, and rarely have synchronous meetings" is different and specific. "We are a small team that ships fast, has minimal process, and expects engineers to own their scope from design to production" is also specific. These descriptions will turn off candidates who want the other thing, which is the correct behavior. You want the JD to filter on culture, not to present a culture-neutral surface that attracts everyone and tells you nothing.
The interview process signal
One of the highest-return additions to a job description is a brief description of the hiring process. How many stages? What does each stage evaluate? How long does it typically take from first conversation to decision? This information is rarely included, which means candidates are going in blind. That asymmetry creates anxiety and often leads strong candidates to prioritize processes where they know what to expect.
Including the process structure also communicates respect. You are acknowledging that the candidate's time is valuable and that you have thought about how to evaluate efficiently. A short paragraph on process is one of the lowest-effort, highest-signal additions to any JD. It is one of the first things we advise teams to add when we see a role getting low-quality inbound.
Revision as a practice
A job description is not a legal document; you can revise it. If a role has been open for three weeks and the inbound does not look like the candidates you want, the JD is a good first place to look. Read it as a strong candidate would. Would you understand what the role actually involves? Would the requirements list make you hesitate to apply? Does the company description tell you anything real about the team?
We have seen teams revise a stalled JD by clarifying scope and pruning the requirements list, and see a meaningfully different inbound quality within two weeks. The funnel does not change; the signal it receives changes. That is the leverage point a well-written job description provides.
