Full Stack Java Developer Interview Questions

A Full Stack Java Developer sits at the intersection of solid backend architecture and dynamic frontend experiences, wielding the Java ecosystem to build scalable, end-to-end solutions. Consider this: because the role demands proficiency across the entire technology stack—from database optimization and API design to responsive UI implementation and DevOps pipelines—interviews for these positions are notoriously comprehensive. Whether you are a candidate preparing for the next career leap or a hiring manager designing an assessment loop, understanding the depth and breadth of full stack Java developer interview questions is the first step toward success Took long enough..

Core Java Fundamentals: The Bedrock of the Backend

Before diving into frameworks, interviewers validate your command over the language itself. These questions test not just syntax knowledge, but your understanding of how the JVM manages memory, concurrency, and execution.

1. Explain the difference between ArrayList and LinkedList. When would you use one over the other? This classic question probes your grasp of data structures. ArrayList is backed by a dynamic array, offering O(1) random access but O(n) insertion/deletion in the middle. LinkedList uses a doubly-linked list, providing O(1) insertion/deletion at known positions but O(n) access. Key takeaway: Use ArrayList for read-heavy workloads; LinkedList for frequent structural modifications.

2. How does the Garbage Collector (GC) work in Java? Explain Generational Hypothesis. Modern interviews go beyond "it cleans memory." You must explain the Young Generation (Eden, Survivor spaces), Old Generation, and Metaspace. Discuss Minor GC vs. Major GC, and mention specific collectors like G1GC, ZGC, or Shenandoah for low-latency requirements. Understanding Stop-the-World events and tuning flags (-Xms, -Xmx, -XX:+UseG1GC) signals senior-level expertise Most people skip this — try not to..

3. What is the difference between ==, .equals(), and hashCode()? This tests the contract between equals and hashCode. If two objects are equal according to equals(), they must have the same hashCode(). Violating this breaks HashMap and HashSet behavior. Be ready to override both methods correctly, ideally using Objects.hash() and Objects.equals() for null safety And that's really what it comes down to..

4. Describe Java Concurrency utilities: ExecutorService, CompletableFuture, and Virtual Threads (Project Loom). Thread management has evolved. Explain the thread pool lifecycle, the difference between submit() and execute(), and how CompletableFuture enables asynchronous composition (thenApply, thenCompose, allOf). With Java 21+, Virtual Threads are a notable development; explain how they decouple platform threads from application threads, allowing massive throughput with blocking-style code Easy to understand, harder to ignore..

Spring Boot & The Backend Ecosystem

Spring Boot is the de facto standard for Java microservices. Expect deep dives into its internals, not just annotation usage.

5. What is Auto-Configuration? How does @SpringBootApplication work? Break down the three annotations it combines: @Configuration, @EnableAutoConfiguration, and @ComponentScan. Explain the role of spring.factories (or META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports in Spring Boot 3+) and how ConditionalOnClass, ConditionalOnMissingBean, and ConditionalOnProperty drive the "magic."

6. Explain the Bean Lifecycle and Scopes. Detail the phases: Instantiation -> Property Population -> Aware interfaces (BeanNameAware, ApplicationContextAware) -> BeanPostProcessor (postProcessBeforeInitialization) -> @PostConstruct / InitializingBean -> BeanPostProcessor (postProcessAfterInitialization) -> Ready for Use -> @PreDestroy / DisposableBean. Contrast Singleton (default), Prototype, Request, Session, and Application scopes.

7. How do you handle Transactions? What is @Transactional propagation? This is critical for data integrity. Define ACID properties. Explain Propagation types: REQUIRED (default), REQUIRES_NEW (suspends current, starts new), NESTED (savepoints), and MANDATORY. Discuss Isolation Levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable) and the pitfalls of rollbackFor (default rolls back only on unchecked exceptions) And that's really what it comes down to..

8. Spring Security: JWT vs. Session/Cookie. How do you implement Stateless Auth? Walk through the filter chain (SecurityFilterChain). Explain how UsernamePasswordAuthenticationFilter works, where JwtAuthenticationFilter fits, and how SecurityContextHolder stores the Authentication object. Discuss CSRF protection (disable for stateless APIs), CORS configuration, and method-level security (@PreAuthorize) Worth keeping that in mind..

9. Database Access: JPA/Hibernate Pitfalls (N+1, LazyInitializationException). The N+1 problem is the most famous performance killer. Explain how fetching a List<Author> and iterating author.getBooks() fires 1 + N queries. Solutions: Entity Graphs, @NamedEntityGraph, JOIN FETCH in JPQL, or Batch Fetching (hibernate.default_batch_fetch_size). Explain Open Session in View (OSIV) anti-pattern and why spring.jpa.open-in-view=false is recommended It's one of those things that adds up..

Frontend Integration: Bridging the Gap

A full stack developer must speak the language of the browser. Modern Java stacks typically pair with React, Angular, or Vue That alone is useful..

10. How do you structure a Spring Boot + React (or Angular) project? Discuss two main approaches:

• Monorepo / Single Artifact: Frontend build output (npm run build) copied into src/main/resources/static or templates. Served via WebMvcConfigurer or Spring MVC static resource handling. Simple deployment (one JAR), but couples build cycles.
• Separate Deployments: Backend as REST API (or GraphQL), Frontend hosted on Nginx, Vercel, Netlify, or S3/CloudFront. Requires handling CORS, Authentication token storage (HttpOnly Cookies vs. LocalStorage/Memory), and Proxy configuration during local dev (proxy in package.json or Vite server.proxy).

11. Server-Side Rendering (SSR) vs. Client-Side Rendering (CSR) vs. Static Site Generation (SSG). While Java handles the API, you must advise on frontend rendering strategies And it works..

• CSR: Standard React/Vue/Angular. Fast navigation after initial load, poor SEO, slow First Contentful Paint (FCP).
• SSR (Next.js, Nuxt, Angular Universal): HTML generated per request. Great SEO, dynamic data. Higher server cost.
• SSG / ISR (Incremental Static Regeneration): HTML generated at build time. Best performance/CDN caching. Stale data risk mitigated by ISR.
• HTMX / Thymeleaf / JTE: Mention the "HTML-over-the-wire" renaissance where Java templates render fragments, reducing JS bundle size significantly.

12. API Design: REST vs. GraphQL vs. gRPC.

• REST: Resource-oriented, HTTP verbs, caching via headers, versioning in URL (/v1/users). Over-fetching/Under-fetching issues.
• GraphQL: Single endpoint, client specifies shape. Solves over-fetching. Complexity in caching, N+1 on resolver level (solved by DataLoader),

DataLoader), and potential for malicious query depth/complexity attacks (mitigated by query cost analysis and depth limiting).

• gRPC: Contract-first (Protobuf), HTTP/2, binary serialization, native code generation for type-safe clients. Ideal for inter-service communication in microservices (low latency, streaming support), but requires a proxy (like Envoy or gRPC-Web) for browser clients. Spring Boot 3+ offers first-class gRPC support via spring-boot-starter-grpc.

13. Real-time Communication: WebSockets, SSE, and WebFlux. When the server must push data (notifications, dashboards, collaborative editing):

• WebSockets: Full-duplex, stateful. Use spring-boot-starter-websocket with STOMP over SockJS for fallback. Scale with Redis-backed message broker (@EnableWebSocketMessageBroker + RedisMessageBroker).
• Server-Sent Events (SSE): Unidirectional (server→client), HTTP/1.1 friendly, auto-reconnect, lighter weight. Native support in WebFlux (Flux<ServerSentEvent>) and MVC (SseEmitter).
• RSocket: Application-layer protocol providing reactive streams semantics (request-response, fire-and-forget, request-stream, channel) over TCP/WebSocket. Excellent for service-to-service reactive pipelines.

Quality Assurance: The Testing Pyramid in Practice

14. Unit Testing: JUnit 5, Mockito, and Testcontainers.

• JUnit 5: Use @ParameterizedTest for edge cases, @Nested for hierarchical organization, and Extensions (e.g., MockitoExtension, SpringExtension).
• Mockito: Prefer @Mock/@InjectMocks over manual mock(). Use ArgumentCaptor for complex argument verification. Avoid over-mocking; test behavior, not implementation details.
• Testcontainers (Critical): Spin up real PostgreSQL, Kafka, Redis, LocalStack (AWS), or WireMock in Docker containers for integration tests. Annotate with @Testcontainers and @Container. This eliminates the "works on H2, fails on Postgres" gap. Use @DynamicPropertySource to inject container ports into Spring context.

15. Integration Testing: @SpringBootTest vs. Sliced Tests.

• @SpringBootTest(webEnvironment = RANDOM_PORT): Full context startup. Slow but real. Use TestRestTemplate or WebTestClient.
• Sliced Tests (Faster, Focused):
  • @WebMvcTest: Controllers + MVC infrastructure (filters, converters). Mock service layer.
  • @DataJpaTest: Repositories + TestEntityManager + embedded DB (or Testcontainers). Auto-rollbacks transactions.
  • @JsonTest: Serialization/deserialization logic only.
  • @RestClientTest: RestClient/WebClient contract testing with MockRestServiceServer.

16. Contract Testing: Pact / Spring Cloud Contract. Prevent breaking API changes in microservices It's one of those things that adds up..

• Consumer-Driven Contracts (Pact): Consumer writes test defining expectations → Generates Pact file → Provider verifies against Pact file in CI.
• Spring Cloud Contract: Producer defines contracts (Groovy/YAML) → Generates producer stubs (WireMock) + producer tests. Consumers use stubs via @AutoConfigureStubRunner.

17. Architectural Fitness Functions: ArchUnit. Enforce architecture rules as unit tests Simple, but easy to overlook..

@ArchTest
static final ArchRule no_cycles = noClasses()
    .should().beAssignableTo(CycleInDependencies.class); // Simplified
// Real rules: layers (controller -> service -> repo), no logic in entities, naming conventions, banned dependencies (e.g., no `java.sql.*` in service layer).

Observability & Operations: Running in Production

18. The Three Pillars: Logs, Metrics, Traces (OpenTelemetry).

• Structured Logging: JSON format (Logstash/ECS layout) via Logback/Log4j2. Include traceId, spanId (MDC) for correlation. Never log PII/Secrets.
• Metrics (Micrometer + Prometheus + Grafana):
  • JVM/System: GC pauses, thread counts, CPU, Memory (built-in).
  • HTTP: http.server.requests (latency, status, uri). Cardinality control: Replace dynamic path params (/users/123) with pattern (/users/{id}) via WebMvcTagsProvider / WebFluxTagsProvider.
  • Business: Custom counters (order.created, payment.failed) with meaningful tags (region, tier).
• Distributed Tracing (OpenTelemetry / Micrometer Tracing):