Job Description Writing Guide for Engineering Managers

Writing a software engineering job description (JD) is one of the most important — and most commonly done poorly — communication tasks for an engineering manager. A well-written JD attracts the right candidates, filters out poor-fit applications, and signals the quality of your engineering culture. A poor JD is either generic, misleading, or packed with jargon. This guide shows you how to write effective JDs in English.

---

The Purpose of a Job Description

A job description serves three audiences:

1. Candidates — helps them self-select in or out based on real information
2. Hiring team — aligns interviewers on what you’re looking for
3. Your organisation — ensures a consistent definition of the role

A JD is also a marketing document — for candidates with multiple offers, the quality of your JD signals the quality of your team.

---

Job Description Structure

1. Job Title

The title must be accurate and searchable.

Good practice:

• Use industry-standard titles: Backend Engineer, Staff Software Engineer, Site Reliability Engineer, Data Engineer
• Specify seniority explicitly: Senior, Staff, Principal, Junior
• Optionally add technology if it’s central: Senior Go Backend Engineer

Avoid:

• Internal code names: “Level 4 IC” (meaningless to candidates)
• Inflated titles: “Full Stack Ninja”, “JavaScript Wizard”
• Ambiguous level: “Engineer” with no seniority signal

---

2. About the Role (2–4 sentences)

A brief, honest summary of what the role does — not marketing copy.

Template:

“We’re looking for a Senior Backend Engineer to join the Payments team at Acme Corp. You’ll design and build the payment processing services that handle €50M in daily transactions, working closely with product and infrastructure. This is a senior IC role with significant scope to influence system architecture and team practices.”

What to include:

• The team / product area
• What the engineer will build or own
• Scope (senior IC, tech lead, hands-on manager, etc.)

---

3. Responsibilities

List what the person will actually do. Use bullet points. Use active verbs in present tense.

Verb patterns:

• Design and implement…
• Own and maintain…
• Collaborate with [X] to…
• Lead the technical direction for…
• Define and enforce…
• Contribute to…
• Mentor junior engineers on…
• Participate in on-call rotation…

Example (Senior Backend Engineer):

- Design, implement, and maintain backend services for the Payments platform
- Lead technical design for new features and review designs from other engineers
- Own operational reliability for your services — participate in on-call rotation
- Collaborate with product managers and designers to refine requirements
- Mentor mid-level engineers through code review and pair programming
- Contribute to engineering-wide practices: code standards, tooling, processes

Anti-patterns: ❌ “Be responsible for backend development” — too vague ❌ Listing 15+ responsibilities — candidates stop reading ❌ “And other duties as assigned” — signals the JD wasn’t thought through

---

4. Requirements

Separate required skills from nice-to-have skills. This matters more than most managers realise — studies show that men apply when they meet 60% of requirements; women typically apply only when they meet 100%. Putting too many items in the “required” section deters good candidates.

Structure:

## Requirements (Must Have)
- 4+ years of experience in backend software engineering
- Proficiency in at least one of: Go, Java, Kotlin, Python
- Experience designing and operating distributed services in production
- Strong understanding of databases (relational and/or NoSQL)
- Experience with RESTful API design

## Nice to Have
- Experience with payment systems or financial services
- Familiarity with Kafka or other event streaming
- Experience with Kubernetes and container orchestration
- Knowledge of PCI DSS requirements

Language for requirements:

• “4+ years of experience in…” — be specific about experience level, not just years
• “Proficiency in…” — for core skills
• “Familiarity with…” — for secondary or nice-to-have skills
• “Experience designing and operating…” — specifies production experience, not just knowledge

Avoid: ❌ Years of experience with specific technologies (“5+ years of React experience”) — React hasn’t existed that long for some technologies; it penalises career changers ❌ Educational requirements (“BSc in Computer Science required”) — unless genuinely required ❌ Jargon acronyms without explanation (“Must know CQRS, DDD, SAGA, ACID, CAP”) ❌ Subjective requirements (“passionate about technology”, “rockstar developer”)

---

5. What You’ll Work With (Tech Stack)

Be explicit about the technology stack — candidates need to understand what they’re building with.

Example:

## Tech Stack
- Languages: Go (primary), Python (tooling, ML pipelines)
- Infrastructure: AWS (ECS Fargate, RDS PostgreSQL, SQS)
- Observability: Datadog, PagerDuty
- CI/CD: GitHub Actions, ArgoCD
- Data: Kafka for event streaming, Redis for caching

---

6. About the Team

Describe how the team works — size, structure, practices. Candidates are choosing a team as much as a role.

Example:

“The Payments team is 7 engineers, 1 EM, and 1 PM. We follow agile practices with 2-week sprints and a weekly architecture review. Half the team is remote. We have strong documentation culture and conduct blameless post-mortems after incidents.”

---

7. Compensation and Benefits

Be transparent. Salary ranges in JDs are increasingly expected (and legally required in some regions). Hiding them wastes everyone’s time.

Example:

“Salary range: €80,000 – €110,000 depending on experience. Benefits include: private health insurance, €2,000 annual learning budget, remote-friendly with optional Prague office access, 25 days PTO.”

---

Language Patterns

Active, specific verbs

Weak	Strong
be responsible for	own, lead, drive, design, build
work on	implement, develop, maintain
help with	contribute to, support, enable
have experience in	proficiency in, strong background in

Inclusive language checklist

• Avoid gendered language (“he or she” → “they”)
• Avoid culturally specific idioms (“rockstar”, “ninja”, “killer instinct”)
• Use “experience in” rather than “expertise in” for non-core requirements
• Avoid unnecessarily excluding requirements (“must have worked at a startup”)

---

Common Mistakes Engineering Managers Make

Copying-pasting from another JD

Results in generic, uninspiring descriptions that don’t reflect your actual role or team.

Over-specifying tools, under-specifying outcomes

“5 years of Kubernetes” is less meaningful than “experience operating containerised services in production at scale.”

Not involving the hiring team

The JD should reflect what interviewers are actually assessing — misalignment leads to inconsistent interviews.

Inflating seniority requirements

“Senior required” for a role that junior or mid-level engineers could do well — reduces candidate pool for no good reason.

---

Practice

Expand your hiring and management vocabulary with the Engineering Manager English exercise set and see all resources in the Engineering Manager learning path.