Last updated: August 13, 2026
Most Java developer job descriptions do one of two things wrong. Either they list 20 required skills and scare off qualified candidates who meet 14 of them, or they’re so generic that the right candidates can’t tell what the role actually involves day to day. Both outcomes waste weeks of pipeline time.
This guide covers what a Java developer JD needs to work, section by section, plus a ready-to-copy template adapted for nearshore hiring from Costa Rica.
Why Most Java Developer JDs Attract the Wrong Candidates
The most common culprit is the skill list. Someone from engineering writes down every technology that has ever touched the codebase. Recruiting adds a few more from a previous role’s JD. The resulting list has 22 bullet points, six of which contradict each other (Java 8 experience required, but also Kotlin experience preferred, on a Spring Boot 3.x codebase).
The second problem is vague seniority language. “Senior Java developer” means different things to every team that posts it. At some companies it means 3 years and a code review or two. At others it means owning a distributed system under production load. Candidates read seniority labels without a definition and apply or don’t apply based on a best guess about your culture.
The third problem, specific to remote and nearshore Java roles, is no mention of collaboration expectations. Will they be on camera for standups? Is async Slack the primary communication channel? Do they write PR comments and documentation in English? These specifics matter to candidates considering a role and they matter to your team once someone starts.
The 7 Sections Every Java Developer JD Needs
The structure matters as much as the content. Candidates scan before they read. A well-organized JD gets read; a wall of text gets skipped.
1. Role summary (3 to 5 sentences)
What the developer will actually build. Not “join our dynamic team” and not a company history lesson. What system are they working in, at what scale, and who does it serve? A specific summary filters candidates far better than a vague one.
2. Primary responsibilities (5 to 8 bullet points)
Describe what the person will do, not what skills they need. “Design and implement RESTful microservices in Spring Boot 3.x” tells candidates more about the role than “experience with microservices required.”
3. Required technical skills
The non-negotiables. If you won’t interview someone who doesn’t have it, it belongs here. Seven items maximum. If you have more than seven required skills, something on the list is actually a preferred skill.
4. Preferred technical skills
What would make a candidate stronger but won’t disqualify them if missing. This is where Kafka, Kubernetes, specific cloud certifications, and secondary frameworks live.
5. Experience level definition
Not years. Context. What kind of systems has this person owned, at what scale, and with what degree of architectural autonomy? See the experience level section below for specific language.
6. Collaboration and communication expectations
Especially important for remote roles. Time zone requirements, meeting attendance, written communication standards, English proficiency level required. Don’t leave any of this implicit.
7. Engagement model and compensation range
Contract, contract-to-hire, or direct hire. Whether this is fully remote, hybrid, or on-site. And if you can, a salary or rate range. JDs with compensation ranges attract more qualified applicants and waste less of everyone’s time.
Required vs. Preferred: How to Split Java Skills
This is the most practical decision you’ll make when writing the JD. Here’s how to split the Java ecosystem for a typical Spring Boot microservices role in 2026:
| Skill | Require for Mid | Require for Senior | Notes |
|---|---|---|---|
| Java 17 or 21 | Required | Required | Specify the LTS version. Java 8 or 11 only = red flag for modern systems. |
| Spring Boot 3.x | Required | Required | If you’re on 2.x, note it. Spring Boot 3 requires Java 17+ and has breaking changes. |
| REST API design | Required | Required | Not just consumption. If they’ll design endpoints, say design experience required. |
| JPA / Hibernate | Required | Required | PostgreSQL or MySQL preference can go in the notes, not as a separate required skill. |
| Spring Security | Preferred | Required | Only require if auth/AuthZ is part of the role scope, not just adjacent to it. |
| Docker / Kubernetes | Preferred | Preferred | If the developer won’t touch infra, list as preferred. Requiring it shrinks your pool. |
| Apache Kafka | Preferred | Preferred | Require only for event-driven architecture roles where Kafka is daily work. |
| AWS / GCP | Preferred | Preferred | Specify platform. “Cloud experience” is not meaningful. |
| Unit / integration testing | Required | Required | JUnit 5, Mockito. If you code review PRs without tests, say so in the JD. |
Experience Level Definitions That Work
Years of experience is the laziest proxy for seniority and the one candidates game most easily. Define what you mean by experience level in terms of what the person has actually done:
| Level | What They’ve Owned | Architectural Autonomy | Typical Java Depth |
|---|---|---|---|
| Junior (1 to 3 yrs) | Individual features under guidance, bug fixes, test suites | Low: implements defined specs | Core Java, basic Spring Boot, simple CRUD services |
| Mid (3 to 6 yrs) | Full features end-to-end, API design, database schema ownership | Medium: proposes approaches, executes independently | Spring ecosystem depth, ORM tuning, API versioning |
| Senior (6+ yrs) | Service ownership, cross-team API contracts, production incidents | High: initiates architecture decisions, mentors others | JVM internals, concurrency, distributed systems patterns |
| Staff / Principal | Multi-service architecture, org-wide technical standards | Leads: defines patterns adopted by multiple teams | Platform design, performance at scale, security architecture |
One line in the JD referencing one of these definitions saves 10 screening calls. Something like: “We define mid-level as having owned complete API features end-to-end, not just implemented stories handed down from a tech lead” communicates more than “3 to 5 years of Java experience required.”
Adapting the JD for Nearshore Java Hiring
A JD written for a local hire will work for a nearshore hire, with four additions.
Time zone requirement, stated clearly. “Costa Rica (UTC-6 year-round) required” or “candidates must be available US Central business hours” tells the candidate exactly what’s expected. Don’t write “US time zone preferred” and then be surprised when you get applications from UTC+5 candidates.
English proficiency level. “Business-level English” means nothing. “Written: sufficient to write clear PR comments and Slack messages without daily editing. Spoken: sufficient to participate in live standups and explain technical decisions to a US engineering lead” means something. State the actual bar.
Remote collaboration tools. List what you use: Jira, GitHub, Slack, Zoom, Confluence, or whatever your stack is. Candidates with experience on your exact tool set ramp faster. This takes two lines and helps.
Team integration expectations. Are they a member of your scrum team, attending all ceremonies? Or are they a specialist called in for specific components? The difference matters to candidates considering the role and to your team lead managing the integration.
Skip the JD. Get Screened Profiles.
Kore BPO pre-screens nearshore Java developers before you see a resume. Profiles in 2 to 5 business days.
Complete Java Developer Job Description Template
Copy, adapt, and use. Replace [bracketed fields] with your specifics:
Job Title
[Mid-Level / Senior] Java Developer – [Contract / Direct Hire], Remote (Costa Rica)
Role Summary
We’re looking for a [mid-level / senior] Java developer to join our [team name] team, working on [brief description: e.g., “a Spring Boot microservices platform serving 2M+ API calls per day for US healthcare clients”]. You’ll own [feature set / service name / architecture area] and work directly with our US-based engineering team in [time zone, e.g., US Central].
Primary Responsibilities
- Design, build, and maintain Spring Boot microservices in [Java 17 / Java 21]
- Write and maintain REST APIs consumed by [internal services / mobile clients / third-party integrations]
- Own database schema design and ORM layer using JPA/Hibernate with [PostgreSQL / MySQL]
- Write unit and integration tests using JUnit 5 and Mockito as part of normal development, not as an afterthought
- Participate in code reviews, sprint ceremonies, and async technical discussions in English
- Collaborate with [product manager / tech lead / QA team] to scope and deliver features within sprint cycles
- [Add role-specific responsibilities: e.g., “Contribute to event-driven pipeline using Apache Kafka”]
Required Technical Skills
- Java 17 or Java 21 production experience in a team codebase
- Spring Boot 3.x: service structure, dependency injection, REST controllers, exception handling
- JPA / Hibernate with a relational database (PostgreSQL preferred)
- Unit and integration testing (JUnit 5, Mockito)
- Git-based workflow with pull requests and code review participation
- REST API design: versioning, error responses, status code standards
- [Add one or two role-specific requirements]
Preferred Technical Skills (not required)
- Spring Security or Spring Cloud experience
- Apache Kafka or another message broker
- Docker; Kubernetes exposure a plus
- AWS or GCP deployment experience
- [Add your stack-specific preferences]
Experience Level Definition
We define [mid-level] as having owned complete API features end-to-end, designed schemas for new data models, and delivered within a team sprint cadence without requiring spec handholding. We define [senior] as having owned a production service, contributed to architecture decisions, and mentored at least one junior team member.
Communication and Collaboration
- Location: Costa Rica (UTC-6, year-round). Must be available during US [Central / Eastern] business hours for standups, code reviews, and sprint ceremonies.
- English proficiency: written clarity sufficient for PR comments, Slack threads, and technical documentation; spoken clarity sufficient for video standups and design conversations.
- Tools: [Jira / Linear] for tickets, GitHub for code, Slack for async communication, Zoom for video.
- Availability: core overlap hours are [e.g., 9 AM to 1 PM US Central]. Remaining hours are flexible.
Engagement Model
[Contract / Contract-to-Hire / Direct Hire]. Rate or salary range: [include if possible]. Start date: [target date or ASAP].
Common Java JD Mistakes That Shrink Your Candidate Pool
Listing Spring Boot 2.x and Java 17 in the same required section. Spring Boot 2.x officially reached end-of-life in November 2023. Requiring it signals that your codebase is behind and that you haven’t updated the JD since the migration was promised but not completed. Either require 2.x and 3.x experience, or just require 3.x.
Requiring 10 years of Java experience. Java 1.0 launched in 1996. A developer with 10 years of Java would have started in 2016 and may have spent years on frameworks and patterns that no longer exist in modern Spring Boot. Specify depth, not duration.
“Strong communication skills required” with no definition. Every JD says this. It means nothing without a specific standard. For a nearshore Java developer who will attend live standups and write PR comments for a US team, “business-level English, both written and spoken” is specific. “Strong communication skills” is not.
No mention of what they’re actually building. “Join an innovative team working on next-generation cloud infrastructure” tells a candidate nothing that helps them decide whether to apply. One sentence describing the actual system type and scale filters candidates better than six sentences of company description.
Requiring a degree when your actual filter is depth. Most strong Java developers at the senior level are self-taught in significant ways, particularly in the microservices and cloud-native space. If you’ll interview people without a CS degree, don’t require one in the JD. It screens out candidates and signals something about your evaluation criteria that experienced developers will notice.
Frequently Asked Questions
How long should a Java developer job description be?
Between 400 and 700 words for the text of the JD itself, not counting the template boilerplate. Shorter than that and you’re missing sections that filter candidates effectively. Longer and you’re likely repeating yourself or listing skills that belong in a different bucket. The job description’s job is to help the right people self-select in and the wrong people self-select out. That doesn’t require 1,500 words.
Should I specify Java 17 or Java 21 in the job description?
Specify the version you’re actually running. Both Java 17 and Java 21 are active LTS versions as of 2026, and fluency in one transfers well to the other. If you’re still on Java 11, say so but note whether you’re planning a migration, since senior candidates may weigh that in their decision. Listing just “Java” without a version tells candidates you haven’t thought carefully about the JD, which is not the signal you want to send.
What’s the right number of required skills for a Java developer JD?
Five to seven required skills is the practical maximum. More than that and you’re either listing preferred skills as required (which screens out qualified candidates) or describing a unicorn role that doesn’t exist at your budget. Keep required skills to the true non-negotiables. Everything else goes in preferred. The distinction between required and preferred is the most important editorial decision in writing a Java developer JD.
Should I include a salary or rate range in the Java developer JD?
Yes, if at all possible. JDs with compensation ranges consistently attract more qualified applicants and reduce time-to-close because candidates know before applying whether the role fits their expectations. For nearshore Java developers from Costa Rica, monthly all-in rates typically range from $3,500 to $13,000 depending on seniority and specialization. Publishing a range also signals organizational maturity to senior candidates who have learned to be skeptical of “competitive compensation” as a placeholder. See the Nearshore Java Developer Salary Guide for current rate benchmarks.
What should a Java JD include for fully remote nearshore roles?
Beyond the standard technical requirements, a nearshore Java developer JD needs four additions: a specific time zone requirement (not just “remote”), a stated English proficiency standard (not just “communication skills”), the collaboration tools in use, and the sprint and meeting cadence expected. Leaving these implicit leads to mismatched expectations in the first two weeks, which is exactly when first impressions between a nearshore developer and a US team are being formed. For help sourcing pre-screened nearshore Java developers, see Kore BPO’s nearshore Java developer page.
Disclosure: Kore BPO is a nearshore staffing agency. This article reflects our direct experience sourcing Java developers from Costa Rica for US engineering teams.
Related Articles
Find Your Nearshore Java Developer
Kore BPO sources, screens, and places nearshore Java developers from Costa Rica. Profiles in 2 to 5 business days, $0 upfront fees.
View Nearshore Java Developers