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.<\/p>\n\n\n\n
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 \u2014 or not \u2014 often happens before they reach the responsibilities section. This dynamic is well understood by anyone working in talent acquisition<\/a> inside IT companies, where the quality of a job posting is treated as a direct reflection of how the engineering organisation operates.<\/p>\n\n\n\n The most common mistakes fall into predictable categories. Vague responsibilities tell a candidate nothing about what the job involves day to day. Inflated requirements \u2014 asking for ten years of experience in a technology that has existed for six \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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?<\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Research published in the Harvard Business Review found that candidates \u2014 particularly women \u2014 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.<\/p>\n\n\n\n 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 \u2014 things a good hire can develop on the job or bring partially.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n For seniority levels, be specific. “Mid-level” means different things at different companies. Giving a concrete range \u2014 three to five years of commercial development experience, ideally with at least one production system at scale \u2014 is more useful than a label. The same principle applies when hiring for senior and leadership roles; misaligned expectations at the Tech Lead<\/a> level, for instance, are among the most common reasons those searches take significantly longer than planned.<\/p>\n\n\n\n <\/p>\n\n\n\n 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 \u2014 not because the company is untrustworthy, but because the candidate’s time is limited and postings with visible compensation are easier to evaluate quickly.<\/p>\n\n\n\n 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<\/a>, salary remains one of the top two factors developers weigh when considering a new role \u2014 clarity on this point is a signal of organizational maturity, not a negotiating weakness.<\/p>\n\n\n\n You do not need to publish a single number. A range \u2014 even a relatively wide one \u2014 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.<\/p>\n\n\n\n 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<\/a> 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 \u2014 and that is exactly what the JD should tell them.<\/p>\n\n\n\n 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?<\/p>\n\n\n\n Remote and hybrid arrangements, learning budgets, conference attendance, and equipment stipends all belong here \u2014 but they work best when stated factually. “We cover one conference per year and provide a \u20ac1,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.<\/p>\n\n\n\n The structure below is not prescriptive \u2014 adapt it to your context. It covers the elements that consistently appear in postings that generate strong applicant pipelines.<\/p>\n\n\n\n Role summary (3\u20135 sentences)<\/strong><\/p>\n\n\n\n What the team does, what this person will own, and what the immediate priorities are when they join.<\/p>\n\n\n\n Tech stack<\/strong><\/p>\n\n\n\n Specific technologies: languages, frameworks, databases, infrastructure, tooling. Separate what is primary from what is secondary.<\/p>\n\n\n\n What you’ll be doing<\/strong><\/p>\n\n\n\n Day-to-day work, team interactions, scope of ownership. Three specific sentences beat ten vague bullet points.<\/p>\n\n\n\n What we’re looking for<\/strong><\/p>\n\n\n\n Must-have requirements \u2014 keep to five or fewer if possible. Nice-to-have requirements, clearly labelled as such.<\/p>\n\n\n\n What we offer<\/strong><\/p>\n\n\n\n Compensation range. Remote\/hybrid\/on-site arrangement. Benefits that are concrete and verifiable. Growth and development opportunities.<\/p>\n\n\n\n About the team (optional but effective)<\/strong><\/p>\n\n\n\n Three to four sentences on team size, how the team works, and what a good culture fit looks like in practice \u2014 not in abstract values language.<\/p>\n\n\n\n Should I include salary if we haven’t finalized the budget yet?<\/strong><\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n Is it worth using a job description template?<\/strong><\/p>\n\n\n\n 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 \u2014 because it is. Edit every section to reflect the specific reality of this role at this company.<\/p>\n\n\n\n How do requirements lists affect who applies?<\/strong><\/p>\n\n\n\n Studies on job application behaviour show that candidates \u2014 particularly those from underrepresented groups \u2014 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.<\/p>\n\n\n\n What is the single most common mistake companies make in IT job descriptions?<\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n Does employer branding matter in a job description?<\/strong><\/p>\n\n\n\n Yes, but it works differently than most companies assume. Lengthy statements about values and culture tend to be skimmed or ignored. Specific details \u2014 the size of the engineering team, how code review works, what the on-call rotation looks like \u2014 are read carefully. Authentic specificity is more persuasive than polished generality.<\/p>\n\n\n\n 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 \u2014 they are evaluating you as carefully as you are evaluating them, and the job description is where that evaluation starts.<\/p>\n\n\n\n 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 \u2014 it requires knowing the role well enough to describe it accurately, and caring enough about the candidate experience to do so.<\/p>\n\n\n\n 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 \u2014 sourcing, screening, and matching \u2014 to people who do it every day work with a specialist in IT recruitment<\/a> rather than trying to compress months of market knowledge into a single internal hire.<\/p>\n\n\n\n Write it like you mean it. That alone puts you ahead of most of the competition.<\/p>\n\n\nStart with the tech stack \u2014 not the company history<\/strong><\/h2>\n\n\n\n
Write responsibilities like a day in the life<\/strong><\/h2>\n\n\n\n
Requirements: separate must-haves from nice-to-haves<\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/recruitment.by\/wp-content\/uploads\/2026\/04\/close-up-teacher-writing-agenda-1024x683.jpg\")
<\/figure>\n\n\n\nBe transparent about compensation<\/strong><\/h2>\n\n\n\n
Sell the role, not just the company<\/strong><\/h2>\n\n\n\n
A practical IT job description template<\/strong><\/h2>\n\n\n\n
FAQ<\/h2>\n\n\n\n
Conclusion<\/strong><\/h2>\n\n\n\n