Developer job description template

What a developer job description should accomplish

A developer job description template helps hiring managers turn a staffing request into a clear agreement about the work, the skills required, and how candidates will be evaluated. For MyDiscussions readers, it should also connect the hire to delivery priorities: maintaining a product, modernizing a platform, improving reliability, or building a new capability.

The strongest job descriptions answer three questions before listing technologies:

• What will this person own?
• What outcomes will show that they are succeeding?
• What support, constraints, and decision-making authority come with the role?

A list of programming languages cannot answer those questions. A useful description combines candidate-facing information with an internal hiring scorecard, so recruiters, interviewers, and engineering leaders assess the same role.

Define the role before writing the advertisement

Start with the business need, not the title of the person who recently left. A replacement hire may require different skills if the roadmap, architecture, or team structure has changed.

Establish scope, seniority, and ownership

Document these decisions before opening the requisition:

Seniority should describe behavior, not merely tenure. A senior developer is generally expected to navigate ambiguity, evaluate trade-offs, and improve team practices. A mid-level developer may independently deliver well-scoped work without owning cross-team architecture.

Do not label a role “junior” while requiring independent architecture, production escalation leadership, and mentoring responsibilities.

Separate necessities from preferences

Every requirement should pass a practical test: Would we reject an otherwise strong candidate who lacks this on their first day?

A must-have might be:

• Demonstrated ability to build and debug HTTP APIs.
• Experience writing automated tests for production software.
• Ability to investigate query performance in a relational database.
• A required credential or eligibility condition for a regulated project.

A preference might be familiarity with GitHub Actions, Terraform, or a particular cloud provider when the team can teach those tools.

Exact-stack experience can shorten onboarding. Transferable experience can widen the candidate pool. Choose based on delivery urgency and available mentoring capacity—not habit.

Copy-and-adapt developer job description template

Replace every bracketed field and delete sections that do not apply. This template is intended for a permanent employee; contractor engagements need a clearer statement of deliverables, acceptance criteria, and commercial terms.

Job title and employment details

Job title: [Level] [Backend / Frontend / Full-stack / Mobile / Platform] Developer

Team: [Team or department]

Reports to: [Manager role]

Location: [Country, region, office, or eligible remote locations]

Working arrangement: [Remote / hybrid / onsite, including attendance requirements]

Employment type: [Full-time / part-time / fixed-term]

Compensation: [Currency, salary range, and explanation of bonus or equity]

Working hours: [Expected overlap, time zone, and flexibility]

On-call: [Whether required, rotation expectations, and compensation or time-off policy]

About the team and opportunity

[Company] builds [product or service] for [users or customers]. Our [team name] team is responsible for [specific product area or platform capability].

We are hiring a [role] to help us [primary business or technical objective]. You will work with [collaborators] and contribute to [systems or workflows]. Current challenges include [two or three genuine problems, such as slow release processes, complex integrations, or legacy service migration].

Responsibilities

In this role, you will:

• Design, implement, test, and maintain [applications, services, interfaces, or infrastructure].
• Translate product requirements into technical tasks with clear acceptance criteria.
• Review code and explain implementation choices, including reliability, security, and maintainability trade-offs.
• Investigate defects using [logs, metrics, traces, or other diagnostic tools].
• Collaborate with [product, design, QA, security, data, or operations] throughout delivery.
• Maintain documentation for [APIs, architectural decisions, operating procedures, or onboarding].
• Participate in [deployment, incident response, or support responsibilities], with [support model].
• Contribute to [mentoring or architectural planning], where appropriate to the level.

What success looks like

During onboarding, you will:

• Set up the development environment and understand the team's delivery workflow.
• Learn the relevant architecture, data handling rules, and escalation procedures.
• Complete a scoped change with support from a teammate.

As you become established, you will:

• Deliver [representative feature or improvement] against agreed acceptance criteria.
• Own changes through testing, release, and post-release verification.
• Identify a practical improvement to [quality, accessibility, performance, or developer experience].

Over the longer term, you will:

• Independently own [scope appropriate to seniority].
• Contribute to [a relevant product or engineering objective].
• Help the team make better decisions through documentation, reviews, and collaboration.

Required qualifications

• Evidence of building and maintaining [relevant type of software].
• Working proficiency in [essential language or framework], or comparable experience where transferable skills are acceptable.
• Ability to write and maintain [unit, integration, or end-to-end] tests.
• Familiarity with version control, code review, and collaborative delivery.
• Ability to explain technical decisions and work through feedback.
• [Any genuinely necessary domain, security, or eligibility requirement.]

We welcome evidence from employment, open-source work, education, and other relevant projects. [Clarify which forms of experience are appropriate for this role.]

Preferred qualifications

• Experience with [specific vendor, framework, or platform].
• Familiarity with [domain or regulatory environment].
• Experience improving [performance, accessibility, reliability, or deployment workflows].
• Exposure to [a planned migration or secondary technology].

These are helpful additions, not requirements for applying.

Our technology environment

Our current environment includes:

• Languages and frameworks: [For example, TypeScript, React, Node.js.]
• Data systems: [For example, PostgreSQL and Redis.]
• Infrastructure: [For example, AWS, Docker, and Terraform.]
• Delivery and testing: [For example, GitHub Actions, Jest, and Playwright.]
• Observability: [For example, OpenTelemetry and Grafana.]

[Explain which technologies require existing proficiency and which can be learned after joining.]

Hiring process and application

Our process includes [stages], covering [technical skills, collaboration, and role-specific judgment].

The technical assessment uses [format], takes approximately [disclosed time commitment], and is evaluated against [criteria]. Our policy on documentation, search engines, and AI coding assistants is [policy].

To apply, submit [required materials] through [application channel]. A public GitHub profile is [optional/not required]. To request an accommodation or alternative assessment format, contact [channel].

[Add organization-approved benefits, equal-opportunity, applicant privacy, and work-authorization language appropriate to the hiring jurisdiction.]

Customize the template for the development specialty

Keep the core structure, but change the work examples and assessment evidence. A frontend developer and a platform developer should not receive identical responsibilities with different framework names.

Frontend and mobile developers

For frontend roles, specify whether the work involves product interfaces, design systems, content-heavy websites, or complex browser applications. React, Vue, and Angular experience may matter, but so can browser behavior, state management, performance, and accessibility.

If accessibility is part of ownership, describe the actual responsibility: keyboard interaction, semantic markup, screen-reader testing, and defect remediation. Reference the W3C Web Content Accessibility Guidelines rather than asking vaguely for “accessible code.”

For mobile roles, distinguish native Swift or Kotlin development from Flutter or React Native. Include release-store responsibilities, supported devices, offline behavior, and crash investigation when relevant.

Backend and full-stack developers

Backend descriptions should identify API design, data modeling, authorization, integrations, and operational expectations. “Build scalable systems” is too vague without the workload and constraints.

For full-stack roles, state the expected emphasis: predominantly backend with occasional interface work, or balanced ownership across both layers.

Broad ownership trades specialization for flexibility. Do not quietly combine frontend specialist, database administrator, cloud architect, and support engineer into one position.

Platform and security-sensitive roles

Platform roles need explicit internal customers and service boundaries. State whether the developer owns deployment tooling, Kubernetes workloads, infrastructure modules, or developer self-service workflows.

For security-sensitive work, use observable responsibilities: threat modeling, dependency remediation, secure code review, or secrets management. The NIST Secure Software Development Framework provides a useful reference for defining secure-development practices without relying on vague labels such as “security-minded.”

Turn the draft into a hiring process

Step 1: Agree on the first meaningful deliverables

Bring together the hiring manager, technical lead, and relevant product or delivery owner. Identify a few representative assignments the new developer will handle.

Examples include adding a payment-provider integration, migrating an endpoint, or improving a slow administrative interface. Validate that these assignments match the advertised level.

Step 2: Map each requirement to evidence

Build an internal scorecard before interviews begin.

Avoid scoring charisma as communication ability. Assess whether the candidate can explain decisions, clarify uncertainty, and collaborate on the actual work.

Step 3: Make the assessment resemble the job

A developer maintaining Django APIs should not face an interview dominated by unrelated algorithm puzzles. Use a bounded exercise such as diagnosing an endpoint defect or reviewing a proposed database migration.

State whether GitHub Copilot or other assistants are permitted. If permitted, evaluate verification and reasoning—not just generated output. Require no unpaid work that produces a usable company deliverable.

Step 4: Review feasibility and compliance

Ask a practitioner to check the technical requirements and a recruiter to check clarity. Have HR or legal review compensation disclosure, employment classification, location eligibility, accommodations, and privacy obligations where applicable.

Compensation should reflect the advertised scope. If the budget cannot support that scope, narrow the role rather than hiding expectations.

Step 5: Publish and calibrate

Keep titles, salary information, location rules, and requirements consistent across the careers page and job boards. If your careers site uses structured data, follow Google’s JobPosting documentation and keep markup aligned with visible content.

After early interviews, review whether candidates understand the role and whether interviewers apply the scorecard consistently. Change unclear criteria openly rather than adding hidden requirements.

Common mistakes that weaken developer job descriptions

• Requiring the entire stack. Mark foundational skills separately from tools that can be learned.
• Using years as the sole seniority filter. Describe ownership, ambiguity, and expected judgment.
• Hiding maintenance work. State the balance between new features, defects, migrations, and support.
• Omitting production duties. Disclose on-call expectations and available escalation support.
• Demanding public portfolios. Many capable developers cannot share proprietary work.
• Promising unrestricted remote work. Specify eligible locations and required working-hour overlap.
• Listing benefits without substance. Explain concrete policies rather than “great culture.”
• Measuring success by code volume. Prefer accepted outcomes, maintainability, and operational quality.

Maintain one approved source document with an owner and revision date. For related hiring and delivery planning documents, browse more Templates topics.

Frequently asked questions

How long should a developer job description be?

Keep the published description scannable enough that candidates can quickly find responsibilities, essential skills, compensation, location, and the hiring process. Preserve information that affects an application decision; move lengthy company history and detailed internal scorecards elsewhere.

Should a developer job description require a degree?

Only make a degree mandatory when it is genuinely necessary or imposed by a documented requirement. Otherwise, allow equivalent practical experience and evaluate relevant evidence. A degree alone does not demonstrate production debugging, testing discipline, or delivery judgment.

What is the difference between developer and software engineer job descriptions?

Organizations use these titles differently, and there is no universal boundary. Choose terminology that matches your internal job architecture and candidate market. Define the actual design, implementation, maintenance, and operational scope rather than relying on the title to communicate it.

How often should the template be updated?

Review it before every hiring round and whenever responsibilities materially change. Revisit the technical stack, compensation, working arrangements, and assessment process. Keep reusable policy language centrally maintained, but verify that each published role reflects the work the team needs today.