Chapter 02 · Section I · 16 min read
Writing JDs that attract the right people
The job description is your first filter — and most JDs written in Nepal filter in the wrong people, filter out the right ones, and bury the few facts a candidate actually wants to know.
The job description is the cheapest, most leveraged piece of recruiting work you will ever do. It runs unattended. It pre-screens before you see a CV. It tells a candidate whether to apply, whether to refer a friend, and whether to take the offer if it comes. And most JDs in Nepal — written by a hiring manager at 9pm, copy-pasted from a similar role on Merojob, lightly retitled — actively repel the candidates the company wants and attract the candidates it does not. AI cannot fix a confused brief. But once the brief is clear, AI can turn a five-line scribble from a tired engineering manager into a JD that filters honestly, in the time it takes to drink a tea.
Facts first. Tone second. Generation last.
The single most common mistake an HR generalist makes with a chatbot is the same mistake every other professional makes with one — asking it to write before telling it what is true. “Write a JD for a backend engineer” produces something fluent, polished, and entirely detached from your company, your stack, your salary band, and your team. The model has no facts, so it invents plausible ones. You end up shipping a JD that promises “competitive compensation” (meaningless), demands “5+ years of experience with cutting-edge technologies” (meaningless), and lists thirty must-haves because the model padded the role to look impressive.
The pattern that works is the one you have already seen elsewhere in this course: fact-first prompting. Before you ask for a single sentence of JD prose, give the model the entire factual skeleton in a short structured block. The model’s only job is to wrap your facts in language that a candidate will read and act on.
A working template, paste-ready for Claude or ChatGPT:
Draft a job description in plain English. Use only the facts below. Do not invent any technology, benefit, or requirement not provided. Do not use the words “rockstar”, “ninja”, “guru”, “10x”, or “work hard play hard”.
Company: a four-year-old payments company in Kathmandu, 38 people, profitable, regulated by NRB. Team: backend platform team, currently 5 engineers reporting to one lead. Stack: Go, PostgreSQL, Redis, deployed on AWS Mumbai, GitLab CI. Role: mid-level backend engineer. Location: Baluwatar office, hybrid (3 days in office). Salary band: NPR 1,40,000 to 1,90,000 per month, depending on experience. Must-haves: 3+ years building production backend services in any typed language, comfort with SQL, written English good enough for code review. Nice-to-haves: Go specifically, payments domain, on-call experience. What success looks like at six months: owning two services end to end, on the rotation, mentoring one junior. Tone: direct, inclusive, no corporate buzzwords. Lead with the work, not the perks.
The output is a clean JD you spend ten minutes editing instead of two hours writing. Crucially, because every fact came from you, the model has nothing to invent.
The structure the model needs
Most weak JDs are missing the same fields. Give the model these, in this order, and the output rarely needs more than a light edit.
Company in one paragraph. What the company does, how old, how big, regulated or not, profitable or funded. Two sentences. A senior candidate in Kathmandu’s small tech scene already knows you exist or can find out in ten seconds; the JD’s job is not to sell the company, it is to anchor the role.
The team and the manager. How many engineers, who they report to, what the team owns. This filters more than people realise. A senior engineer reading “team of two, reporting to the CTO” knows the role is very different from “team of fifteen, reporting to a team lead who reports to an engineering manager.”
The product and the stack. Concrete. Go, Postgres, Mumbai region — not “modern cloud-native technologies”. The candidate is deciding whether they will enjoy the day. Vague stack lines drive the best candidates to skip; they assume you do not know what you are using.
Location and working model. Office address (neighbourhood is enough), hybrid versus remote versus full in-office, expected office days. Nepali candidates increasingly factor commute and Kathmandu traffic into offer decisions; saying “Baluwatar, 3 days in office” gets you a more honest applicant pool than “flexible”.
Seniority and salary band. State the band. Yes, in rupees. The argument against — “it limits negotiation”, “competitors will see it” — is weaker than the argument for: a posted band cuts the number of applicants whose expectations are wildly off in either direction, and it signals that the company is not trying to underpay the under-informed. The best candidates filter on this line.
Must-haves vs nice-to-haves, kept honest. Five must-haves, maximum. Each must-have should be something that, if the candidate lacked it, you would actually reject them. The rest go in nice-to-haves. A JD with twenty must-haves signals to the candidate that you do not know what you want — and the strongest candidates, who can read that signal, do not apply.
Success at six months. Two or three concrete outcomes. This is the single most under-used field in Nepali JDs and the one senior candidates respond to most. It tells them what they will actually do, not what skills they will tick.
Tone instructions for the model. Direct, inclusive, no buzzwords. The model needs to be told.
Inclusive language and the words that quietly cost you applicants
There is a body of research — large enough now to take seriously — showing that certain words in a JD measurably reduce applications from women, from people without computer-science degrees, and from candidates outside the dominant social network of the company. The words are familiar. Rockstar. Ninja. Guru. 10x. Aggressive. Hustle. Work hard, play hard. Crushing it. Killer instinct. The line “we are a tight-knit family” reads as warm to insiders and exclusionary to outsiders; “fast-paced environment” reads as exciting to some and as code for “we will burn you out” to others.
The discipline is not to remove all character from the JD. It is to ask the model to surface and strip the words that filter out people you would have hired. The prompt instruction is one line: “Review this JD for language that has been shown to reduce applications from women and from candidates outside the dominant network. List each phrase and a neutral replacement.” The model does this surprisingly well. It will catch “rockstar”, suggest “skilled engineer”. It will catch “aggressive deadlines”, suggest “tight deadlines”. It will catch “we work hard and play hard”, and suggest you delete the sentence because it is filler.
The second discipline is to check the must-have list for the same effect. “5+ years” cuts roughly half the qualified women in Nepal’s small tech labour market, because women in this market are on average earlier in their careers; if 3 years would actually be enough, say 3 years. “Computer science degree” cuts every self-taught engineer and every bootcamp graduate; if a portfolio would actually be enough, say so. Each unnecessary must-have is a filter that catches the wrong fish.
Three Nepali-context examples
The same structure adapts across very different roles. The shape of the facts changes; the discipline does not.
1. The Kathmandu fintech backend engineer. Covered above. The hard parts are honest salary banding (the band is narrower than candidates assume), and the on-call expectation (payments companies need on-call; saying so up front saves a withdrawn offer in week three).
2. The Pokhara NGO programme officer. Different shape entirely. The facts block should specify: which donor funds the programme (DFID, USAID, GIZ — candidates have strong feelings), what districts the work covers, how much field travel, whether a motorbike licence is required, whether Nepali fluency includes writing reports in Nepali (often missed), whether English-language donor reports are part of the job. Inclusive language matters as much here — “must be willing to travel extensively to remote VDCs” filters out women with caring responsibilities more than it filters out men with the same responsibilities; if “five field visits a quarter, planned a month in advance” is the truth, say that instead.
3. The Lalitpur BPO team lead. Different again. The facts block: shift pattern (US night shift versus UK shift versus 24/7 rotation — this is the single biggest filter for BPO roles and is routinely hidden in JDs), team size, KPIs the lead is accountable for, cab facility, meal allowance, performance bonus structure. BPO candidates are highly sophisticated about JD reading because they apply often; vague JDs get vague applicants, and the company ends up hiring people who will leave at month four.
The “filters in vs filters out” pass
Once the JD draft exists, run one more prompt before publishing. Paste the draft back and ask: “For each line in this JD, tell me whether it filters in the ideal candidate, filters out the wrong candidate, or does neither. For every line that does neither, suggest cutting or rewriting.” The model will mark roughly a third of the lines in a typical first-draft JD as doing neither — “we are passionate about excellence”, “join our journey”, “we offer a competitive salary and benefits”. Cut them. The JD gets shorter. The applicants get more qualified. Nothing of value is lost.
Common mistakes, in order of damage
The same mistakes appear in JD after JD. The model can warn you about them if you ask it to, and you should.
Vague seniority. “Junior to senior backend engineer” means you do not know which role you are hiring for, and you will get a flood of applicants you cannot compare.
No salary band. Costs you the candidates who are good enough to filter on compensation and saves you nothing.
Thirty must-haves. Signals confusion. The strongest candidates assume the role is undefined and skip.
Buzzword company section. “We are reimagining the future of finance in South Asia” tells a candidate nothing they can act on. Two sentences about what the company actually does are worth ten of these.
Missing the team context. Candidates senior enough to matter will not join a role without knowing who they report to, how big the team is, and what it owns.
No “success at six months”. The single line most likely to convert a senior candidate from “interesting” to “applying”.
Check your understanding
Quick check
—Which approach to writing a JD with AI is most likely to produce a description that actually filters the right candidates?
Quick check
—A backend engineer JD opens with: We are looking for a rockstar 10x engineer who can crush deadlines and thrive in our fast-paced, work-hard play-hard culture. What is the most likely effect of this opening line on the applicant pool?
What comes next
A JD that filters honestly gets you the right applicants — but only from the channels you already post on. Most strong candidates in Nepal are not actively looking; they are reachable only through cold outreach. The next section is about using AI to write outreach that gets a reply, without sounding like every other recruiter in their inbox.