A good tech job description tells a qualified person, in under two minutes, what they would work on, what they would be paid, and whether they meet the bar. Lead with the work, include a real salary range, keep hard requirements to the few that truly screen people out, and cut everything that reads like boilerplate.
The posting is often the first contact a candidate has with your team. Strong engineers skim dozens of them, and they skip the ones that hide the pay or describe the company for four paragraphs before mentioning the job.
What to include, in order
A posting that works has these parts, roughly in this order:
- Title and level. Use a title people search for ("Senior Backend Engineer"), not an internal one ("Platform Ninja II"). State the level.
- The pay range and location. Base salary range, plus whether the role includes a bonus or equity. Where the person can work: on-site city, hybrid, or remote and in which states or time zones.
- What you will work on. Two to four sentences on the actual problems and systems. This is the section strong candidates read most carefully.
- What success looks like. What the person should have done after six months or a year.
- Requirements. Short and real (see below).
- Nice to have. Clearly labelled as optional.
- About the team and company. Size, stage, who they would work with, how the team works. Keep it brief.
- The process. The interview steps and how long it usually takes.
- Benefits and how to apply. Some states require these (see below).
Leave out lines that every company says: "fast-paced environment," "rock star," "competitive salary," "wear many hats." They take space and tell the reader nothing.
Salary ranges and state pay transparency rules
Put the range in the posting even where the law does not require it. Candidates look for it first, and without it you spend screening calls discovering that expectations are $40,000 apart.
In several states, it is also a legal requirement. Rules differ in who is covered and what counts, so check the labor department for each state where the job could be done, including remote roles. Based on each state's official guidance:
| State | Who is covered | What the posting needs |
|---|---|---|
| California | Employers with 15 or more employees | A pay scale: a good faith estimate of the salary or hourly range the employer reasonably expects to pay. It must be in the posting itself, not behind a link or QR code. Third-party recruiters posting for the employer must include it too. (CA Labor Commissioner) |
| Colorado | Employers, for internal and public postings | Compensation, information about benefits, and how and when to apply. (Colorado CDLE) |
| Washington | Employers with 15 or more employees | A wage scale or salary range, a general description of all benefits, and a general description of other compensation such as bonuses, commissions or stock options. Open-ended phrases such as "$60,000 per year and up" do not count as a range. (Washington L&I) |
| New York State | Employers with four or more employees | A compensation range (minimum and maximum annual salary or hourly pay believed accurate at posting) and a statement if the job is commission-based. New York City has its own law too. (NY DOL) |
| Illinois | Employers with 15 or more employees, for postings since January 1, 2025 | The pay scale and a general description of benefits and other compensation. A hyperlink to position-specific pay and benefits information is allowed. (Illinois DOL) |
Other states have passed similar laws, and rules change. This table is a starting point for checking, not legal advice.
How to set the range itself: use the Bureau of Labor Statistics pay data for the occupation as a baseline, then adjust for level, industry and location. For example, the BLS reports a May 2025 median of $135,980 for software developers, with a 10th percentile of $82,460 and a 90th percentile of $214,670 (BLS). Our software developer page has the full breakdown, and the other role pages cover occupations such as information security analysts and data scientists.
Make the range honest. A posted range of $70,000 to $240,000 is technically a range and practically useless. If one posting covers two levels, say so and give a range for each.
Requirements versus nice-to-haves
Every line in "Requirements" acts as a filter. Some candidates will not apply if they miss even one item, and a list of twelve "requirements" shrinks your pool far more than you intend.
Test each requirement with one question: would you reject an otherwise excellent candidate who lacks it? If not, it is a nice-to-have.
Useful requirements describe ability, not credentials or time served:
| Weak requirement | Better version |
|---|---|
| 7+ years of experience | Has designed and run a production service that other teams depend on |
| Bachelor's degree in computer science | (Remove, unless a degree is legally or contractually required) |
| Expert in React, Vue, Angular, Svelte | Builds front-end features in a modern framework; we use React |
| Knowledge of AWS | Has deployed and debugged services on a major cloud provider |
| Excellent communication skills | Writes clear design docs and pull request descriptions |
Three to six requirements is plenty for most roles. Put the specific tools you use under nice-to-haves unless the person truly has to be productive in them on day one.
If certifications matter for the role (common in security and networking), say which ones and whether they are required or preferred. Our certifications hub covers the common ones.
Inclusive wording
Wording affects who applies, and some wording creates legal risk. The EEOC says it is illegal for an employer to publish a job advertisement that shows a preference for, or discourages someone from applying because of, race, color, religion, sex, national origin, age (40 or older), disability or genetic information. Its own example: an ad asking for "recent college graduates" may discourage older workers from applying (EEOC).
Practical rules:
- Describe the work, not the person. "You will own the deployment pipeline" rather than "You are a young, hungry hacker."
- Avoid age signals. "Digital native," "recent graduate," and "high energy" all point at age.
- Use physical requirements only when they are real. "Must be able to lift 50 pounds" belongs in a data center technician role, not a backend engineering role.
- Drop jargon that signals an in-group. "Crushing it," "work hard, play hard," and sports metaphors tell some readers they will not fit.
- Use "you" and plain verbs. It reads more directly and avoids gendered pronouns.
- Say you will make accommodations during the interview process and how to ask for them.
An annotated example
Below is a posting for a fictional company, followed by notes on why each part is there.
Senior Backend Engineer (Payments) Remote (US) or hybrid in Denver, CO. $150,000 to $175,000 base salary, plus equity. [1]
What you will work on. You will own our payments service, which handles subscription billing for about 4,000 small business customers. In your first year you will migrate it from a legacy processor integration to a new one, and design the retry and reconciliation logic that keeps failed payments from turning into support tickets. [2]
What success looks like. After six months: the migration plan is agreed and the first customers are moved. After a year: the old integration is gone and billing-related support tickets have dropped. [3]
Requirements
- You have built and operated a backend service in production, including being on call for it.
- You have worked with a relational database at the level of designing schemas and reading query plans.
- You can write a design doc that other engineers can review and act on. [4]
Nice to have
- Experience with payment processors or financial reconciliation.
- Python or Go (we use both). [5]
About us. We are a 25-person company with a 7-person engineering team. You would report to the head of engineering and work most closely with one other backend engineer and our support lead. [6]
Benefits. Health, dental and vision insurance; 401(k) with employer match; 20 days of paid vacation plus sick leave; equity in the form of stock options with four-year vesting. [7]
Process. A 30-minute call with the hiring manager, a 90-minute paid technical exercise based on a simplified version of our billing code, and a 3-hour team interview. We aim to finish within three weeks. If you need an accommodation at any stage, tell us and we will arrange it. [8]
How to apply. Apply by November 30 through our careers page with a résumé or a link to your work. [9]
Notes:
- Title, level, location and pay come first. The role can be based in Colorado, so the posting includes compensation, benefits, and how and when to apply.
- The work is described in terms of real systems and real problems. A candidate can picture the first year.
- Success criteria tell senior candidates what they would be judged on and signal that the team has thought about it.
- Three requirements, all describing ability. No years-of-experience count, no degree.
- The languages are nice-to-haves. A strong engineer in another language can learn them.
- Team size and reporting line answer the questions candidates otherwise ask in the first call.
- This is the kind of general benefits description that Colorado and Washington ask for, and it is useful information for candidates everywhere.
- Publishing the process and its length signals respect for the candidate's time. The accommodation line costs nothing and matters to those who need it.
- An application deadline and method address the "how and when to apply" information Colorado asks for.
Before you publish
Read the posting as a candidate would: could a qualified person tell, in two minutes, what the job is, what it pays, and whether to apply? Then check the pay transparency rules for every state where the role can be done, and have someone outside the hiring team read it for jargon and unnecessary requirements.