Job description template
A complete, India-market software engineer JD you can copy and adapt — plus what to screen for, what repels good engineers, and how the wording changes your ATS match rate.
Software engineering is the role where a bad job description costs you the most, because the strongest candidates are the ones with the least patience for reading one. An engineer with three good options open reads your JD for about as long as it takes to decide whether your team builds anything interesting and whether the requirements list was written by someone who has read code. If the answer to either is no, they close the tab. The template below is written to survive that test: it names the work, not the adjectives, and it separates what you genuinely cannot train from what you can.
Replace everything in [square brackets] before you post it.
Job title
Software Engineer
[Company name] builds [one sentence: what the product does and who uses it]. The engineering team is [size] and owns [what the team is responsible for].
We are hiring a Software Engineer to build and maintain [product area — e.g. the payments service, the customer-facing web app, the internal data platform]. You will own features end to end: scoping with product, writing and reviewing code, shipping to production behind our release process, and supporting what you ship. This is a hands-on individual-contributor role on a team of [n] engineers, and you will have a named area of ownership within your first quarter.
Experience: [x–y] years. If you are close to the band and the rest of the description fits, apply — we will tell you honestly where you land.
Location and work model: [city, office locality] — [on-site / hybrid: n days a week in office / fully remote]. State the actual expectation, including which days, if hybrid.
Reports to: [Engineering Manager / Tech Lead name or title]. Team: [team name].
Compensation: [state the band and the fixed/variable split, or state plainly that it is benchmarked to experience and discussed in the first call]. Also state ESOP policy, notice-period expectation and whether there is any bond or service agreement — candidates find out anyway, and finding out late is why offers get declined.
To apply: send your resume and, optionally, a link to code you are willing to talk about, to [email / apply link]. Our process is [n] rounds: [name them, and say how long the whole thing takes].
The template is the easy half. These are the decisions that decide whether the posting works.
The most common defect in Indian software engineer JDs is the technology list that reads like a procurement catalogue: React, Angular, Vue, Node, Django, Spring Boot, Kafka, Kubernetes, Redis, Elasticsearch. It is written to widen the funnel. It narrows it instead, because the engineers you want read it as evidence that nobody on the hiring side knows what the team does, while the engineers who are optimising for keyword coverage read it as an invitation.
Replace the list with the truth: the primary language, the framework the team ships in today, and the datastore. Everything else moves to nice-to-have or comes out entirely. If your team genuinely uses six technologies, name the two an engineer must be productive in from week one, and say that the rest is learned on the job — which is what actually happens.
Two sentences describing the actual product area beat any amount of culture copy. "You will work on the reconciliation service that settles merchant payouts" tells an engineer what the problems look like, what scale means here, and whether they will be bored. "Work on cutting-edge technologies in a fast-paced environment" tells them nothing, and it is the single most-copied line in the market, so it also tells them you copied it.
Bands drift upward during drafting — a role scoped for three years arrives at the JD asking for six, because someone added a requirement without removing one. Write the band, then read the must-haves and ask whether a person at the bottom of the band could hold every one. If not, the band is wrong or the must-haves are.
Also decide before publishing what you will do with a candidate who is a year short and clearly strong. If the answer is that you would interview them, say so in the JD. It costs one line and it is the difference between a good engineer applying and not.
Signals specific to software engineer applications — not generic screening advice.
Engineers are the most JD-literate audience you will write for, and they read for signals of what the job is really like. Four things reliably lose them.
If you screen with a JD-matching tool, the technology list is the highest-weight surface in the document, which is exactly why a padded list produces a padded shortlist. Every extra technology you name raises the score of candidates who list it and lowers the relative score of the engineer who is deep in the one that matters.
Naming conventions also cost you real matches, because engineers write the same technology several ways.
Other roles, hiring guides and recruiter tooling.
The role most often mis-scoped as a data scientist. Fix the scope and the pipeline fixes itself.
Lifecycle ownership, not talent acquisition with a bigger title. Scope it by headcount supported.
Early attrition is a JD problem. Disclose field-vs-inside and lead source up front.
Six roles, each with its own screening guidance
The components a job offer letter usually carries, the difference between an offer letter and an appointment letter, and the omissions that cause offers to be declined or disputed later.
A working method for shortlisting at scale: build the scorecard first, run two passes, know which filters are real and which are proxies, and calibrate before you trust anyone's judgement
Score applications against your own job description
JD screening scores every application against your own job description and shows the requirement-level gaps behind the score.