What Should a Senior Java Developer Actually Know?

1. Deep Knowledge of Core Java

A senior Java developer should be comfortable with the language beyond everyday syntax.

This includes object identity and equality, references, immutability, initialization order, inheritance, polymorphism, interfaces, records, sealed classes, exceptions, generics, collections, streams, lambdas, method references, and modern language features.

More importantly, the developer should understand where these features become dangerous or confusing.

For example, overriding equals() without a compatible hashCode() implementation can create subtle collection bugs. Mutable objects used asHashMap keys can become effectively unreachable after the fields involved in hashing change. Poorly designed inheritance hierarchies can make otherwise simple code hard to evolve.

Senior developers should be able to explain these behaviors, recognize them in code reviews, and choose designs that reduce the chance of future mistakes.

Collections and Generics

A senior engineer should understand the behavioral and performance differences among common collection types rather than selecting them from habit.

That includes the implications of ordering, hashing, comparator consistency, mutability, iteration, synchronization, memory overhead, and expected access patterns.

Generics should also be understood beyond basic type parameters. Bounded type parameters, wildcards, PECS-style reasoning, type erasure, generic API design, and the limitations of the type system are all useful knowledge when designing reusable libraries and application boundaries.

Streams and Functional Style

Senior developers should know when streams improve clarity and when they hide control flow.

They should understand lazy evaluation, intermediate and terminal operations, stateless and stateful operations, collectors, side effects, short-circuiting, parallel streams, and the cost of creating unnecessarily complicated pipelines.

The goal is not to replace every loop with a stream.

The goal is to choose the clearest abstraction for the job.

3. JVM, Memory, and Garbage Collection

A senior Java developer does not need to be a JVM engineer, but should understand enough of the runtime to diagnose real production problems.

Useful knowledge includes stack and heap behavior, object allocation, reachability, garbage collection, generations, class loading, JIT compilation, references, memory leaks, allocation pressure, and the difference between application memory problems and JVM configuration problems.

A developer should understand that garbage collection does not prevent every type of memory leak.

If the application accidentally retains references to objects that are no longer useful, those objects remain reachable and therefore cannot be collected.

Senior engineers should be able to investigate symptoms such as increasing heap usage, frequent collections, long pauses, out-of-memory errors, excessive allocation, or poor latency.

They should know how to approach the problem using evidence: GC logs, heap dumps, profiles, thread dumps, metrics, and production traces.

5. Databases, SQL, JPA, and Transaction Management

Senior backend developers need strong database reasoning even when an ORM generates most SQL automatically.

They should understand relational modeling, primary and foreign keys, normalization, indexes, joins, query plans, constraints, transactions, isolation levels, locking, and the performance implications of different access patterns.

With JPA or Hibernate, this also includes persistence-context behavior, entity state, dirty checking, lazy and eager loading, cascade rules, relationship mapping, batching, and the N+1 query problem.

Senior developers should not assume that a clean object model automatically produces efficient database behavior.

They should be able to inspect generated SQL, use execution plans, understand why an index helps or does not help, and recognize when the ORM abstraction is creating unnecessary cost.

Transaction design is equally important.

A transaction that is too large can increase contention and lock duration. A transaction that is too small can expose inconsistent intermediate states. Distributed operations may require patterns such as idempotency, retries, optimistic locking, or a transactional outbox instead of trying to force one database transaction across multiple services.

7. Microservices, Messaging, and Distributed Failure

Many senior Java roles involve systems that cross process, service, or database boundaries.

At that point, failure becomes a normal part of the system rather than an exceptional event.

Senior developers should understand timeouts, retries, exponential backoff, idempotency, duplicate messages, message ordering, delivery guarantees, dead-letter handling, circuit breakers, partial failures, and eventual consistency.

They should understand why “exactly once” is often more complicated than it sounds and why business-level idempotency is frequently required even when infrastructure provides delivery guarantees.

Messaging systems introduce additional design questions.

What is the unit of ordering? Can a message be processed twice? What happens if the consumer updates the database and crashes before acknowledging the message? How should poison messages be handled? How will schemas evolve?

Senior developers should be comfortable reasoning about these scenarios before they appear as production incidents.

9. Testing Strategy, Not Just Unit Tests

Senior developers should understand how different testing layers provide different kinds of confidence.

Unit tests are useful for isolated logic. Integration tests verify behavior across real components. Contract tests can reduce integration surprises between services. End-to-end tests validate critical user journeys but are slower and more expensive to maintain.

The skill is not maximizing test count.

It is designing a test strategy that catches important failures at a reasonable cost.

Senior engineers should also think about determinism, testability, fixtures, database state, external dependencies, concurrency, retries, and the risk of tests that pass while the real system remains unsafe.

Production monitoring is part of the reliability story too. Not every failure can be discovered before deployment.

11. Performance and Capacity Reasoning

Senior developers should understand performance as a system property rather than a collection of micro-optimizations.

Useful concepts include latency, throughput, percentiles, queues, bottlenecks, CPU, memory, I/O, connection pools, database contention, serialization cost, network calls, cache behavior, and backpressure.

They should know that average latency can hide severe tail latency and that optimizing a method responsible for 1% of the request time rarely solves a system-wide problem.

Profiling and measurement should come before optimization.

Senior engineers should also reason about capacity: what happens when traffic doubles, a downstream dependency becomes slower, or a queue grows faster than workers can drain it?

Performance work is often about understanding where the system stops scaling gracefully.

13. Code Design and Maintainability

Senior developers write code for future developers, not only for the current compiler.

They should understand cohesion, coupling, encapsulation, dependency direction, composition, abstraction, domain boundaries, and the cost of premature generalization.

Design patterns can be useful vocabulary, but patterns should not be applied simply because they exist.

The goal is to make future change easier.

Sometimes that means introducing an abstraction. Sometimes it means deleting one.

Senior developers should recognize when code is difficult because the problem is inherently complex and when it is difficult because the design is unnecessarily complicated.

Senior Developers Can Still Have Significant Knowledge Gaps

Seniority does not imply equal depth across every Java topic.

A developer who has spent years building Spring applications may know dependency injection and persistence extremely well while rarely dealing with advanced concurrency.

Another developer may understand JVM performance deeply but have limited experience with distributed messaging.

Someone working in mature internal systems may have little exposure to public API security or large-scale traffic.

This is normal.

Modern backend engineering is too broad for every developer to have equal expertise in every area.

The useful question is not whether gaps exist.

That question matters because learning is much more efficient when it is directed at specific weaknesses rather than at everything that could possibly be learned.

How Do You Know If Your Java Knowledge Is Senior Level?

Job titles are imperfect signals.

A better approach is to examine the depth of your reasoning across different areas.

Can you explain why a concurrent design is thread-safe rather than simply saying that it uses a concurrent collection?

Can you explain why a query becomes slow, how you would verify the cause, and what trade-offs an index introduces?

Can you design an asynchronous order-processing flow that handles retries and duplicates without producing duplicate business effects?

Can you explain when optimistic locking is preferable to pessimistic locking?

Can you investigate long GC pauses using actual evidence?

Can you explain why a system should use eventual consistency in one place and stronger consistency in another?

These questions expose much more than years of experience.

Algonique's Java skill assessment is designed around this idea: evaluate understanding across individual topics, identify demonstrated strengths and gaps, and use the result to decide what deserves attention next.

Senior Java Developer FAQ