Как написать вакансию, которая привлечёт сильных IT-специалистов

Most companies spend weeks — sometimes months — sourcing IT candidates. They pay for job board credits, tap their networks, and brief recruitment partners. Then they paste a job description together in twenty minutes and wonder why the quality of applicants doesn’t match the effort.

The job description is not an administrative checkbox. It is the first thing a candidate reads about your company. For senior developers, it functions as a filter: they use it to decide whether your company is worth their time. Get it wrong, and no amount of sourcing will save your pipeline.

This guide is written from the perspective of recruiters who have reviewed thousands of IT applications and spoken with hundreds of developers about why they apply — or don’t. What follows is practical advice specific to tech hiring, not adapted from generic HR templates.

Why most IT job descriptions fail

The average IT job posting is a document written for the company, not for the candidate. It opens with three paragraphs about the company’s mission, lists twenty-odd requirements, half of which are aspirational, describes the role in language so vague it could apply to four different positions, and says nothing about salary.

Senior developers have seen thousands of these postings. They know within thirty seconds whether a description was written thoughtfully or assembled from a template. The decision to keep reading — or not — often happens before they reach the responsibilities section. This dynamic is well understood by anyone working in talent acquisition inside IT companies, where the quality of a job posting is treated as a direct reflection of how the engineering organisation operates.

The most common mistakes fall into predictable categories. Vague responsibilities tell a candidate nothing about what the job involves day to day. Inflated requirements — asking for ten years of experience in a technology that has existed for six — signal that no one has thought carefully about what the role actually needs. And missing salary information reads, at this point, as either disorganization or an intention to lowball.

None of this means your job description needs to be a literary achievement. It needs to be honest, specific, and structured in a way that makes sense to someone who reads dozens of these a week.

Start with the tech stack — not the company history

If there is one thing senior developers check first, it is the technology stack. Not the company vision. Not the team culture statement. The stack.

A developer’s skills, experience, and day-to-day satisfaction are all tied to what they build with. Whether the role involves React or Angular, PostgreSQL or MongoDB, a monolith or microservices — these details determine whether this is a job worth reading further. Burying the stack in paragraph four, or omitting it entirely, guarantees that a significant portion of qualified candidates will not make it to paragraph two.

List the stack clearly and specifically near the top of the posting. Name the languages, frameworks, databases, cloud infrastructure, and any notable tools or platforms. If there is a legacy system that will be part of the role, mention it — developers respect honesty about technical debt far more than they respect pretending it does not exist. If you are actively modernizing the stack, say so.

What you should avoid is listing technologies as buzzwords without context. «We use cutting-edge technologies including AI and blockchain» communicates nothing. «We’re building a data pipeline in Python on AWS, using Airflow for orchestration and dbt for transformation» communicates a great deal.

Write responsibilities like a day in the life

The responsibilities section is where most job descriptions collapse into a list of abstract verbs. «Responsible for designing, developing, and maintaining scalable systems.» «Collaborating with product and design teams.» These sentences are technically true of almost any software engineering role, which means they are effectively meaningless.

What a candidate actually wants to know is: what will I do? Who will I work with? What problems will I be solving, and how much ownership will I have over the solutions?

Try writing one or two sentences that describe a concrete challenge the person in this role will face. The backend team is currently migrating a monolithic payment service to a microservices architecture — the person joining will own two of those services end to end, from design through deployment. That single sentence tells a candidate more than six bullet points of generic responsibilities.

Include the team structure: how many engineers, how the team is organized, whether there is a dedicated QA function or whether developers own testing, how product decisions get made. Senior candidates in particular want to understand the working environment before they apply.

Requirements: separate must-haves from nice-to-haves

Research published in the Harvard Business Review found that candidates — particularly women — are significantly less likely to apply when they do not meet every stated requirement, even when the role does not actually demand all of them. A list of fifteen requirements does not make your company look rigorous; it makes it look like no one has thought carefully about what the role needs.

The most effective approach is to split requirements into two explicit tiers. The first covers what someone genuinely cannot do this job without. The second covers skills or experience that would be advantageous but are not blockers — things a good hire can develop on the job or bring partially.

Be honest with yourself when building the first tier. If someone could succeed in this role with four years of relevant experience instead of seven, write four. If the GraphQL knowledge is something the team could transfer in the first month, it does not belong in the must-have list. Inflated requirements filter out exactly the candidates who might otherwise have been great hires, and they make your posting less competitive against companies who have calibrated more carefully.

For seniority levels, be specific. «Mid-level» means different things at different companies. Giving a concrete range — three to five years of commercial development experience, ideally with at least one production system at scale — is more useful than a label. The same principle applies when hiring for senior and leadership roles; misaligned expectations at the Tech Lead level, for instance, are among the most common reasons those searches take significantly longer than planned.

Be transparent about compensation

Salary transparency has moved from a nice-to-have to a practical necessity in IT hiring. Candidates who are actively looking scan dozens of postings a week. Those without salary information get deprioritized — not because the company is untrustworthy, but because the candidate’s time is limited and postings with visible compensation are easier to evaluate quickly.

The common objection to including a salary range is that it will anchor expectations or invite negotiation. In practice, a visible range filters the pipeline: candidates who would find the compensation unacceptable do not apply, which saves everyone time. According to the Stack Overflow Developer Survey, salary remains one of the top two factors developers weigh when considering a new role — clarity on this point is a signal of organizational maturity, not a negotiating weakness.

You do not need to publish a single number. A range — even a relatively wide one — is enough to signal that the company has thought about compensation and is willing to be open about it. If the range varies significantly based on experience, say so.

Sell the role, not just the company

Many job descriptions spend more words on the company than on what makes this particular role worth taking. Candidates can look up your company on LinkedIn, read your blog, and check Glassdoor. There is extensive data on how candidates research employers before deciding whether to apply, and most of that research happens outside the job description itself. What they cannot easily find is why this specific position is interesting — and that is exactly what the JD should tell them.

This does not mean writing marketing copy. It means being specific about what makes this role compelling. Is the team small enough that the person joining will have real influence over technical decisions? Is there a genuine path to a senior or lead position within a realistic timeframe? Is there a meaningful technical challenge that does not exist in most companies?

Remote and hybrid arrangements, learning budgets, conference attendance, and equipment stipends all belong here — but they work best when stated factually. «We cover one conference per year and provide a €1,000 annual learning budget» is more credible than «we invest in your growth.» One honest paragraph about what it is actually like to work on this team will outperform a polished list of benefits every time.

A practical IT job description template

The structure below is not prescriptive — adapt it to your context. It covers the elements that consistently appear in postings that generate strong applicant pipelines.

Role summary (3–5 sentences)

What the team does, what this person will own, and what the immediate priorities are when they join.

Tech stack

Specific technologies: languages, frameworks, databases, infrastructure, tooling. Separate what is primary from what is secondary.

What you’ll be doing

Day-to-day work, team interactions, scope of ownership. Three specific sentences beat ten vague bullet points.

What we’re looking for

Must-have requirements — keep to five or fewer if possible. Nice-to-have requirements, clearly labelled as such.

What we offer

Compensation range. Remote/hybrid/on-site arrangement. Benefits that are concrete and verifiable. Growth and development opportunities.

About the team (optional but effective)

Three to four sentences on team size, how the team works, and what a good culture fit looks like in practice — not in abstract values language.

FAQ

Should I include salary if we haven’t finalized the budget yet?

If you genuinely cannot commit to a range yet, it is better to write «competitive, dependent on experience» than to omit salary entirely. But wherever possible, do the internal work to establish a range before posting — senior candidates will often ask for compensation information before agreeing to a first call, and «we haven’t decided yet» is a weak position to be in.

Is it worth using a job description template?

Templates are useful as a starting structure, not a finished product. They ensure you don’t forget a section. The risk is that copy-pasting produces text that reads as generic — because it is. Edit every section to reflect the specific reality of this role at this company.

How do requirements lists affect who applies?

Studies on job application behaviour show that candidates — particularly those from underrepresented groups — are significantly less likely to apply when they do not meet every stated requirement. Keeping the must-have list tight, and clearly labelling the rest as preferred, has a measurable effect on both the volume and diversity of applicants.

What is the single most common mistake companies make in IT job descriptions?

Writing the requirements section before the responsibilities section. When you know what the person will actually do, you can work backwards to what they genuinely need. Most inflated or inaccurate requirements lists come from writing them in isolation, without grounding them in the real scope of the role.

Does employer branding matter in a job description?

Yes, but it works differently than most companies assume. Lengthy statements about values and culture tend to be skimmed or ignored. Specific details — the size of the engineering team, how code review works, what the on-call rotation looks like — are read carefully. Authentic specificity is more persuasive than polished generality.

Conclusion

A well-written job description does not guarantee a great hire. But a poorly written one will quietly filter out many of the best candidates before you ever get the chance to speak with them. The developers you most want to hire are typically not desperate — they are evaluating you as carefully as you are evaluating them, and the job description is where that evaluation starts.

The effort required to write a genuinely good posting is not enormous. It means being specific about the stack, honest about the scope, transparent about compensation, and clear about what the role actually offers the person taking it. None of that requires marketing skills — it requires knowing the role well enough to describe it accurately, and caring enough about the candidate experience to do so.

Companies that find the gap between candidates who apply and candidates who are actually suitable frustratingly wide often discover the problem starts here, with a posting that speaks to the wrong people or signals the wrong things. Those that prefer to hand the entire process — sourcing, screening, and matching — to people who do it every day work with a specialist in IT recruitment rather than trying to compress months of market knowledge into a single internal hire.

Write it like you mean it. That alone puts you ahead of most of the competition.