Hire Spring Boot developers

Spring Boot is the default framework for commercial Java services, and hiring for it means testing whether someone understands what the framework does rather than only which annotations to use.

What Spring Boot actually is

Spring Boot is an opinionated layer over the Spring framework that removes most of the configuration Spring historically required. It auto-configures components based on what is on the classpath, supplies sensible defaults, and produces a self-contained runnable application. It is the default choice for new Java services in most organisations by a very wide margin.

What you get is a comprehensive platform: dependency injection, web handling, data access, security, messaging, scheduling, validation and production monitoring endpoints, all designed to work together and all configurable through properties rather than code. For enterprise systems built by rotating teams over many years, that coherence is worth more than the flexibility it costs.

The hiring consideration is that the framework is very good at hiding what it does. A developer can be productive for years by adding annotations and following patterns, without understanding the container underneath. That works until something behaves unexpectedly at startup, or a transaction does not roll back as expected, and then the difference between the two kinds of developer becomes expensive.

The part that separates seniors from mid-levels

The application context is the foundation. At startup Spring scans for components, resolves their dependencies, applies auto-configuration based on the classpath and properties, and builds an object graph. Most confusing Spring problems are context problems: a bean not created because a condition was not met, two candidates for one dependency, or a circular reference. Developers who can read the startup report and the conditions evaluation output diagnose these in minutes; those who cannot resort to adding annotations until it works.

Transaction management is the second area and the one that produces the most consequential bugs. The transactional annotation works through a proxy, which has a specific and widely misunderstood consequence: calling an annotated method from within the same class bypasses the proxy entirely, so no transaction starts. The code looks correct, the annotation is present, and nothing happens. This single behaviour is responsible for a remarkable share of data consistency bugs in Spring applications.

The third is understanding what the persistence layer actually does. Spring Data generates repository implementations from method names, which is convenient and hides the queries completely. Combined with lazy loading and the persistence context lifecycle, it produces the N plus one problem, the detached entity exception, and queries far more expensive than the code suggests. A senior Spring developer inspects generated SQL as a matter of routine.

Where Spring Boot is used

The label “Spring Boot developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Enterprise back ends

Internal systems in banking, insurance, telecoms and logistics, which is the framework's heartland.

Microservice estates

Service fleets in containers, usually the modernisation target for an older monolith.

Financial services

Payment, trading and settlement systems, where the framework's maturity and transaction handling are valued.

Public sector and healthcare

Long-lived regulated systems with extended support requirements.

Integration services

Middleware connecting enterprise systems, frequently over messaging.

Legacy modernisation

Moving applications off application servers and older Spring versions, a large share of available work.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Spring Boot versions are still supported

Spring Boot publishes clear support windows for each release line, including a commercial extended support option, so whether an application is on a supported version is a matter of record.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 4 are still maintained and 4 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Spring Boot alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Java or Kotlin

The language. Kotlin is increasingly common and fully supported.

Spring Data JPA with Hibernate

Persistence, and the source of most performance surprises.

PostgreSQL or Oracle

The data store, Oracle in older estates and PostgreSQL in newer work.

Spring Security

Authentication and authorisation, powerful and genuinely difficult to configure correctly.

Maven or Gradle

Build and dependency management, with Spring's dependency management handling version alignment.

JUnit with Testcontainers

Testing against real dependencies in containers rather than mocks.

Spring Boot Actuator with Micrometer

Health, metrics and production monitoring endpoints.

Kafka or RabbitMQ

Messaging, very common in the estates where Spring dominates.

Related skills that frequently appear on the same specification: Java, SQL, Android and Kotlin, AWS, Kubernetes.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

The application context and auto-configuration

The framework's foundation, and where annotation-level knowledge runs out.

• Strong answer: Explains component scanning, conditional configuration and bean lifecycle, and has debugged a context failure using the conditions report.
• Warning sign: Cannot explain why a bean was not created beyond checking the annotation is present.

Transactional self-invocation

A specific, common and expensive bug that separates real experience from tutorial knowledge.

• Strong answer: Knows that calling an annotated method internally bypasses the proxy, and can explain how to avoid it.
• Warning sign: Unaware, which means they have probably shipped the bug without knowing.

Spring Data and generated queries

Where Spring applications become slow.

• Strong answer: Inspects generated SQL, uses fetch joins or entity graphs, and has fixed an N plus one problem.
• Warning sign: Relies on derived query methods without ever checking what they produce.

Spring Security configuration

Powerful, complex, and misconfiguration is a security problem rather than a bug.

• Strong answer: Understands the filter chain, can explain how a request is authorised, and has debugged a rule that did not apply.
• Warning sign: Copies a security configuration without being able to explain what it permits.

Testing approach

Spring makes both good and useless testing easy.

• Strong answer: Slices the context for speed, uses Testcontainers for integration tests, and avoids loading the full application for every test.
• Warning sign: Every test starts the whole application, making the suite slow enough that people skip it.

Configuration and profiles

Enterprise applications accumulate configuration and environments diverge.

• Strong answer: Externalised configuration, typed properties, validation at startup, and secrets from a vault.
• Warning sign: Credentials in property files committed to the repository.

Version upgrades

Recurring work, and Spring Boot major versions have brought substantial changes.

• Strong answer: Has taken an application across a major version and can describe what broke.
• Warning sign: Has only worked on applications that were never upgraded.

Warning signs in a Spring Boot codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Transactional self-invocation

• What you see: An annotated method called from another method in the same class.
• What it costs: No transaction starts, so nothing rolls back on failure and partial writes persist silently.
• The fix: Move the transactional method to another component, or restructure so the call crosses a proxy boundary.

The N plus one query

• What you see: Iterating entities and touching a lazily loaded association.
• What it costs: Hundreds of round trips, with latency growing as data grows and nothing visible in development.
• The fix: Fetch joins or entity graphs, and log generated SQL in development so the pattern is obvious when written.

Field injection

• What you see: Dependencies injected directly into fields rather than through the constructor.
• What it costs: Dependencies are hidden, the class cannot be constructed in a test without the framework, and circular references are concealed until startup.
• The fix: Constructor injection. It makes dependencies explicit and the class usable without Spring.

Entities used as API models

• What you see: Persistence entities returned directly from controllers.
• What it costs: The database schema becomes the public contract, lazy loading fails during serialisation, and internal fields leak.
• The fix: Map to dedicated response objects. The small amount of extra code buys a real boundary.

Full context in every test

• What you see: Every test annotated to start the entire application.
• What it costs: A suite slow enough that developers stop running it, which removes the benefit entirely.
• The fix: Use test slices for focused tests and reserve the full context for genuine end-to-end cases.

Catching and logging broadly

• What you see: Wide exception handling that logs and continues.
• What it costs: Failures hidden and the application continuing in an inconsistent state, with the real cause lost.
• The fix: Handle what you can handle, let the rest reach a boundary that decides deliberately.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Spring Boot developer.

Junior

Implements endpoints and repositories in an existing service. Needs review on transactions and query behaviour.

Mid-level

Owns a service or module including tests and data access. Can debug a context failure and read generated SQL.

Senior

Owns service architecture, transaction and consistency design, security configuration and performance under load. Can run a major version upgrade.

Staff

Owns the estate's shared libraries, version policy, cross-service contracts and the decomposition strategy.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New service

• Usual team: One to two developers.
• What governs it: Quick when the domain is clear. Integration with existing enterprise systems is the real scope.

Major version upgrade

• Usual team: One senior developer.
• What governs it: Spring Boot major versions have brought real changes. Scoped by dependency count and test coverage.

Monolith decomposition

• Usual team: Two to three developers plus domain knowledge.
• What governs it: The database is the project. Splitting the code is the straightforward half.

Performance remediation

• Usual team: One senior developer, time-boxed.
• What governs it: Usually persistence layer. Generated SQL and connection pool behaviour are the first places to look.

Security review

• Usual team: One senior developer.
• What governs it: Spring Security misconfiguration is common and the findings are usually significant.

Migration work you may actually be hiring for

A large share of Spring Boot work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

An older Spring Boot major version to current

• Why teams do it: Security support, current dependencies and a supported Java baseline.
• What to watch: Major versions have changed the required Java version and moved package names. Use the published migration guide and available tooling, and expect third-party starters to be the blocker rather than Spring itself.

An application server deployment to a standalone Spring Boot application

• Why teams do it: Simpler deployment and an end to shared-container configuration problems.
• What to watch: Anything relying on server-managed resources such as connection pools, transactions or security realms needs an explicit replacement. Move one application at a time.

XML configuration to annotations and auto-configuration

• Why teams do it: Less configuration to maintain and alignment with how the framework is documented.
• What to watch: They coexist, so this is incremental. There is little value in converting working configuration nobody is touching.

Field injection to constructor injection

• Why teams do it: Explicit dependencies, testability without the framework, and circular references surfaced at compile time.
• What to watch: Mechanical and safe, and it frequently reveals classes with far more dependencies than anyone realised. That revelation is usually the more valuable outcome.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Spring Boot developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which Spring Boot and Java versions the application targets, and whether upgrading is in scope.
• Whether the codebase is Java, Kotlin, or both.
• What the persistence approach is, and how much logic lives in the database.
• Whether Spring Security is configured and by whom, since this is where misconfiguration concentrates.
• Whether this is a monolith, a service in a fleet, or a decomposition project.
• How old the oldest part of the codebase is, because most Spring work is inherited.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Spring Boot work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Spring Boot developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Spring Boot developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Spring Boot frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Annotation familiarity without framework understanding. Ask about the context and about transactional proxying. Both expose the gap quickly.

No SQL ability. Spring Data hides the database completely. In enterprise work this catches up with you.

No upgrade experience. Major versions have introduced breaking changes. Someone who has never upgraded will underestimate it.

Greenfield-only experience. Most Spring work is inherited. Ask how they approach a large codebase with partial tests.

Hiring Spring Boot developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Spring Boot developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Is Spring Boot the right choice for new Java services?

For most commercial work, yes, mainly because of the ecosystem and the hiring pool. Almost any problem you meet has been met before and documented, and developers recognise the structure immediately. Lighter frameworks exist and are good, and they are worth considering for specific reasons such as startup time in serverless contexts rather than as a general preference.

Why did our transaction not roll back?

The most common cause by a wide margin is self-invocation: a transactional method called from another method in the same class, which bypasses the proxy so no transaction ever starts. The annotation is present, the code looks right, and nothing happens. It is worth checking this first whenever consistency behaves unexpectedly.

Why is our Spring Boot application slow?

Usually the persistence layer. The N plus one problem is the most common, followed by connection pool exhaustion and queries that look simple but generate expensive SQL. Turning on SQL logging in development and watching the query count per request typically identifies it quickly, and the fix is often a few lines.

Should we use Java or Kotlin with Spring Boot?

Both are fully supported and Kotlin has become common. Kotlin offers null safety and less ceremony; Java has the larger pool and more existing code. Treat them as one hiring pool with a preference rather than two, because developers move between them readily on the JVM.

How difficult are Spring Boot major upgrades?

Real work, and manageable if done on the cadence. Major versions have brought baseline Java version requirements and package changes that touch many files. The mechanical parts are well documented and tooling helps. Applications that skip several majors face a much harder job, as always.

Is Spring Security worth the difficulty?

Yes, because the alternative is writing authentication and authorisation yourself, which is a reliably bad idea. It is genuinely hard to configure and the documentation assumes more context than most developers have. The practical advice is to have someone who has done it before set it up, and to test what the configuration actually permits rather than trusting that it does what was intended.

Do we need microservices with Spring Boot?

No, and the framework is perfectly good for a well-structured monolith. Spring Boot's association with microservices is historical rather than necessary. Split services when you need independent deployment, independent scaling or independent team ownership, not because the framework is associated with the pattern.

How do we test Spring Boot applications well?

Slice the context so most tests load only what they need, and use containers for real dependencies in integration tests rather than mocking repositories. The failure mode to avoid is a suite where every test starts the whole application, because it becomes slow enough that people stop running it and the tests stop providing any protection.