By Vadym Lobariev, founder of MindHunt — recruiting technical specialists across Europe and Ukraine since 2011
A job description is usually the first thing a candidate sees about your company. It determines who applies, who self-selects out, and how long the search takes.
In my experience, a significant number of searches that drag on or produce the wrong candidates start with a job description problem — not a talent shortage. Here are the four patterns I see most often.
Pattern 1: The Author Doesn't Understand the Domain
This is more common than it should be, and it produces job descriptions that range from confusing to actively misleading.
A recent example: a job description for an AI-related role where the author used "agent" and "LLM" interchangeably — as if they were different words for the same thing. They are not. An LLM is a language model. An agent is a system that uses an LLM to take actions, make decisions, and complete tasks. Conflating them signals to any technically literate candidate that the company does not understand what it is building.
Another example: a job description that listed "experience reviewing and testing AI-generated code" as a requirement, with a note that "we are looking for real developers, not people who rely on AI." The implication being that developers who use AI tools are somehow less real than those who don't.
Setting aside the debate about AI tools — the note about testing AI-generated code reveals a misunderstanding of why QA exists. If experienced developers wrote perfect code on the first attempt, QA engineers would not be a profession. Testing is not a response to AI. It is a response to the fact that all code has errors, regardless of who or what wrote it.
A job description written by someone who does not understand the domain will repel the candidates you want — the ones who know enough to spot the confusion — and attract the ones who don't know the difference. The search outcome reflects this.
The fix: Have the job description reviewed by someone with domain expertise before it goes out. Not to rewrite it — just to flag the parts that are technically inaccurate or misleading.
Pattern 2: Too Many Requirements Repel the Right Candidates
There is a common belief that writing an exhaustive list of requirements is a form of precision. In practice, it is the opposite.
Here is why: candidates self-qualify. When someone reads your job description, they are deciding whether to apply. If the list is long and specific, many candidates who would be excellent fits will disqualify themselves because they do not meet two or three requirements — even when those requirements are negotiable, and even when the hiring manager would happily discuss them.
The default assumption is that requirements are requirements. If the company intended them to be preferences, the job description should say so.
A list of fifteen requirements for a senior developer role tends to produce two outcomes: a small number of applications from people who technically match everything (who may be over-qualified or moving for the wrong reasons), and a large number of non-applications from people who are the right fit but assumed they would not be considered.
The fix: Separate genuinely required skills from preferred ones. Be explicit: "Required: X, Y, Z. Preferred but not essential: A, B." This gives suitable candidates permission to apply. It also respects their time — they know immediately what the non-negotiables are.
Pattern 3: Multiple Authors, Conflicting Vision
This is the organisational problem that produces the most confused job descriptions.
A role opens. Multiple stakeholders have opinions: the CTO wants strong coding skills, the team lead thinks deep code understanding is sufficient, HR wants someone who fits the culture. Nobody agrees on what the actual requirements are. The resulting job description is a committee document that tries to satisfy everyone and ends up confusing everyone.
The candidate reads it and cannot tell what the role actually is. The recruiter cannot screen effectively because there is no clear standard to screen against. The interview panel asks different questions and comes to different conclusions.
One particularly common version of this: "Must have strong coding skills" vs "Code understanding is fine, they will be managing others." These are genuinely different roles. A management-track technical lead who will mostly review and direct is not the same as a hands-on engineer who will write significant amounts of code. The search for one will produce the wrong shortlist for the other.
The fix: One person owns the brief. Other stakeholders have input, but a single person makes the final call on what is required, what is preferred, and what the role actually involves. If there is genuine disagreement about what the role should be — that is a conversation to have before the search starts, not during it.
Pattern 4: Stubbornness in the Face of Expertise
The fourth pattern is the most difficult to address because it is about attitude, not process.
A company receives feedback from a recruiter, a technical advisor, or experienced candidates that the job description is unrealistic, confusing, or misaligned with the market. The response is to defend the description rather than reconsider it.
"We know what we need." "Our requirements are our requirements." "We'll just keep looking."
This is sometimes reasonable — a recruiter suggesting you lower your standards is not always right. But when multiple experienced people independently raise the same concern, it is worth taking seriously.
The candidates you want are evaluating you too. A job description that signals internal confusion about the role, unrealistic expectations, or a lack of technical understanding of the domain will influence how strong candidates perceive the opportunity — and whether they stay in the process.
The fix: Treat feedback on a job description the same way you would treat feedback on a product. Validate it, discuss it, and update if the evidence supports it. Being open to expertise in areas outside your own is not weakness — it is how decisions improve.
What a Good Job Description Actually Looks Like
Specific about the problem, not just the task. "We need someone to lead the migration of our legacy API infrastructure to a microservices architecture over 12 months" is more useful than "responsible for API development."
Honest about requirements. Required is required. Preferred is preferred. Do not list eight "required" skills when four are genuinely required.
Single author or clear ownership. One person is responsible for the final version. Others can review — but the brief has a clear owner.
Reviewed by someone with domain expertise. Especially for technical roles where the description involves specific technologies, architectures, or practices.
Sells the role, not just lists it. Why would a good candidate want this role? What will they build? What does the team look like? What is interesting about this specific problem? A candidate reading your description is making a decision — give them the information they need to make it.
At MindHunt, we review job descriptions as part of every search brief — not to rewrite them, but to flag the issues before they affect the candidate pool. If you want a second opinion on a description before a search starts, get in touch.
Related reading: The IT Recruitment Process: What Goes Wrong · 7 Secrets to Successful IT Recruiting · Technical Recruitment: A Practical Process Guide
Written by
Vadym Lobariev
MindHunt is an AI powered recruitment firm for founders, C-level and hiring managers who are tired of posting and praying. We execute a proven sourcing process for your hardest roles and show you the work every week — so you can make hires with confidence, not hope.
