Most technology job descriptions are written to protect the employer, not to attract the engineer. Here is one that ran recently, lightly disguised. Senior engineer. Eight years’ experience required. A list of nineteen technologies. A line about being a self-starter who thrives in ambiguity. A salary band described as competitive.
Reading it, you could not say what the person would do on a Tuesday. Neither could the candidates. It attracted very few applications, and the hiring manager concluded that the market was tight.
The market was not especially tight. The advertisement was unreadable.
Technology job descriptions have a translation problem, and it costs employers more than it costs candidates. Good engineers are not short of options and they will not spend twenty minutes decoding a description to work out whether a role is interesting. They move on. What is left in your pipeline is the people who applied to everything.
Why technology job descriptions filter out the wrong people
The instinct when writing a technical role is to protect against unqualified applicants by listing everything. It backfires in a specific and measurable way.
LinkedIn’s research on skills-based hiring found that job posts leading with responsibilities rather than requirements receive around 14 per cent more applications per view. The same body of work found recruiters are roughly five times more likely to search by skills than by degrees, and analysis from the Burning Glass Institute puts the share of postings that have dropped degree requirements at close to 45 per cent compared with 2019.
Long requirement lists do not filter for capability. They filter for confidence. The engineers who apply anyway when they meet twelve of nineteen criteria are not necessarily your strongest candidates, they are your boldest ones. Meanwhile the person who could do the job well, but reads the list literally, never applies.
Write the work, not the wish list
The most useful discipline we know is to answer one question in plain language before writing anything else: what will this person actually be doing in their first six months?
Not the vision. The work. Are they building something new, or holding something together? Is the codebase five years old or five months old? Will they be the only person who understands a system, or the fourth engineer on an established team? Is there on-call, and what does it genuinely look like?
Compare these two lines for the same job:
Responsible for maintaining and enhancing enterprise data infrastructure in a fast-paced environment.
Our reporting pipeline was built by one person who has since left. It breaks about once a fortnight and finance cannot close the month without it. Your first job is to make it boring.
The second is not more polished. It is more honest, and it will draw a specific kind of engineer, the kind who finds that problem satisfying rather than alarming. That is the entire objective of a job advertisement.
Separate what is teachable from what is not
Most technology job descriptions mix two very different things: capabilities that take years to build, and tools that a competent engineer picks up in a fortnight.
Distributed systems judgement is not teachable in a fortnight. A particular cloud provider’s console largely is. Knowing how to debug a production incident under pressure is hard-won. Knowing your specific CI tool is not.
Split your list in two. Be genuinely firm on the first group and explicitly relaxed about the second, and say so in the advertisement. A line as simple as “we use Terraform, but if you have done this with CloudFormation we are not worried” measurably widens a pipeline, and it signals that the people writing the ad understand the work.
Publish the salary
“Competitive” communicates one thing to experienced candidates: that the number is not competitive.
Withholding it does not preserve negotiating room so much as it filters out people with options, who have no reason to invest in a process that might end at a number they were never going to accept. Publishing a real band costs you very little and saves everyone the two interviews it otherwise takes to discover a mismatch.
Say what the title actually means
Technology titles are close to meaningless across organisations. A senior engineer at a forty-person company and a senior engineer at a bank are frequently doing unrelated jobs. Platform engineer, DevOps engineer, SRE and infrastructure engineer overlap so heavily that the title tells a candidate almost nothing on its own.
You do not need to fix the industry’s naming conventions. You do need one sentence establishing scope: who this person reports to, how many people are on the team, and what they own end to end. That sentence does more work than the title ever will.
A short test before you post
Give the draft to someone technical who does not work on that team and ask them three questions: what would this person do first, who would they work with, and why would somebody good want it?
If they cannot answer all three from the text, candidates will not be able to either, and the applications you get back will reflect that.
Technology is a sector Bantu is actively growing into, particularly as we establish our Middle East presence, and we are approaching it the way we approach every market: by understanding the work before writing about it. If you are hiring technical people and the role is proving difficult to describe, that conversation is often more useful than a search brief. You can talk to us about hiring, or read our take on why the human parts of hiring still decide outcomes.
