How to Write a Job Description That Attracts Engineers

A job description does one job: it makes a specific person, currently employed and not looking, decide that a reply is worth their evening. Most of them fail at that, and they fail in predictable ways.

This is about engineering roles specifically, because engineers read these documents more sceptically than anyone else in the market. They have seen a thousand of them, they can tell within two paragraphs whether the writer has met the team, and they have options.

Start with what they'll build, not who you are

The most common structure is: three paragraphs about the company, then responsibilities, then requirements. By the time the reader reaches anything about the actual work, they're gone.

Invert it. The first thing an engineer wants to know is what problem they'd be working on, and it should be specific enough that it couldn't be pasted into another company's advert.

Compare:

You will design, develop and maintain scalable backend services in a fast-paced environment.

with:

You'd own our payments service — currently a Node monolith handling around 40,000 transactions a day — through a split into separate services. The first six months are that migration; after it, the roadmap is card and wallet support for three new markets.

The second one tells a reader whether they want the job. The first one is true of every backend role that has ever existed, which means it carries no information at all.

You don't need impressive numbers. You need real ones. "A small internal tool used by twelve people in operations, which is currently three PHP files and needs to become something maintainable" is a perfectly attractive role to some engineers, and being honest about it filters for them.

Cut the stack list down to what you actually need

The requirements section is where most engineering adverts do their damage. A list of fourteen technologies with "5+ years" attached to several of them does two things, both bad:

It filters out the people you want. There is good evidence that strong candidates — and disproportionately women — apply only when they meet nearly everything listed, while weaker candidates apply regardless. A padded list doesn't raise your bar; it changes who is willing to reply.

It signals that you don't know what the job needs. An engineer reading "React, Angular, Vue, Node, Python, Go, Kubernetes, Terraform, AWS, GCP" concludes one of two things: the role is badly defined, or the company is one person short of a functioning team and this is the wish list.

Split the list in three and label it honestly:

• Essential — what someone genuinely cannot do the job without. Aim for three or four items.
• Useful — what would shorten the ramp-up.
• We'll teach you — what you're happy for someone to learn on the job.

The third category is the one almost nobody writes, and it does more work than the other two combined. It tells a candidate that this is a place where learning is expected rather than penalised, and it opens the role to people who are one technology away from perfect.

Years of experience are a poor proxy

"5+ years of React" is not a requirement; it is a guess at one. React changed substantially within that window, and someone who has spent three years building complex interfaces will beat someone who has spent seven maintaining one.

If seniority genuinely matters, say what you actually need: has led a project end to end, has been on call for a production system, has mentored someone junior. Those are things you can ask about in an interview. Years are not.

Put the salary in

This is the highest-impact change available and the one most companies resist.

Engineers in Pakistan — and everywhere else — have learned that "market competitive salary" means "we want to find out your number first". A range costs you nothing you weren't going to spend anyway, and it earns you three things: replies from people whose expectations already fit, no wasted final rounds that die on money, and the presumption that you are straightforward to deal with.

If you genuinely cannot publish a range, publish the band you're hiring into and say what determines the position within it. Saying nothing is the worst option.

State it in the terms candidates use locally: monthly and gross, in PKR, unless you have a reason to do otherwise. An annual USD figure is not a favour to the reader; it's arithmetic homework.

Be specific about remote, hybrid and hours

"Remote-friendly" is not information. Nor is "flexible working". These phrases have been used to describe everything from full asynchronous remote to four days in an office.

Say:

• Remote, hybrid or on-site — and if hybrid, how many days and which.
• Where you need the person to be. A role open to anyone in Pakistan is different from one that needs someone who can reach Islamabad.
• What hours overlap you actually need. This is the single most important line for a cross-border role, and the most commonly omitted. Pakistan is UTC+5. "Some overlap with our US team" means nothing; "at least four hours of overlap with US Eastern, so roughly 6pm–10pm PKT twice a week" means everything.

Vagueness here doesn't widen your pool. It just moves the disappointment to a later stage, after both of you have spent time.

Describe the interview process up front

Tell people what they're agreeing to: how many stages, what each one is, roughly how long the whole thing takes, and whether there's a take-home.

If there is a take-home, say how long it should take and mean it. An unpaid exercise advertised as "about two hours" that genuinely takes eight is the fastest way to lose the exact candidates who have other options and families.

A process described honestly is also a commitment you can be held to, which is why publishing it tends to make companies tighten it.

The six things that lose you readers

In rough order of how often we see them:

1. "Rockstar", "ninja", "guru". These read as dated at best. They also correlate, in a lot of engineers' experience, with places that expect heroics instead of planning.
2. "Work hard, play hard" and "fast-paced environment". Widely read as long hours.
3. "We're like a family." Read as: boundaries will be a problem.
4. A wall of company boilerplate before any mention of the work.
5. "Competitive salary" with no number.
6. No named team, no named manager, no sense of who they'd sit with. Engineers are choosing colleagues as much as a company.

Replace each with something concrete. Not "fast-paced" but "we ship weekly and the on-call rota is one week in six". Not "like a family" but "the team is five engineers, and you'd report to the head of engineering". Concrete claims can be checked, which is exactly why they're believed.

Say who you are, briefly, at the end

Company context still matters. It just isn't the opening.

Two short paragraphs at the bottom — what the company does, how many people, funding or profitability if relevant, what stage the product is at — is plenty. An engineer who has read the role and liked it will read this. One who hasn't, won't, no matter where you put it.

A structure that works

If you want a template:

1. The role in one sentence — what they'd own.
2. What you'd work on — three or four sentences, specific, with real numbers even if unimpressive.
3. The stack — what you use, honestly, including the legacy parts.
4. What we need — three or four essentials, then useful, then what you'll teach.
5. Salary range, location, hours.
6. The interview process — stages and timeline.
7. About us — two paragraphs.

That's typically 400 to 600 words. Anything much longer is usually padding, and padding is what readers skim past on their way to the salary that isn't there.

The honest test

Read your description and ask: could a competitor publish this unchanged, with their name at the top?

If yes, it says nothing about your role. Every sentence that survives that test is doing work; every sentence that doesn't is taking up space where the reasons to reply should be.

---

If you're hiring engineers in Pakistan, our IT recruitment page covers how we work technical briefs, and the guide to hiring remote teams here covers the time zone and contracting decisions that a job description has to reflect. Planning a start date? Notice periods and employment norms explains why five to six weeks is the realistic figure.