Java Spring Boot 10 Years Interview Experience [Best Skills Ever]

Summary — context

• Interview with “D” — Senior Java / Spring Boot developer (10 years).
• Interviewer/host: Fan.
• Project: internal CI/workflow tool (“Quark”) and a monitoring/validation platform supporting ~17 applications. The discussion covered architecture, validation, Spring Boot best practices, DevOps, performance, and practical troubleshooting.

Project architecture and data flow

• Three major components:
  • React frontend.
  • Backend: Spring Boot REST APIs.
  • Validation/metadata component: Spring Boot microservice.
• Metadata flow:
  1. Each application uploads a large JSON metadata file to Google Cloud Storage (GCS).
  2. The validation microservice reads the file, performs complex business validation (including unit-test coverage gating), and on success uploads validated metadata to a destination GCS location.
  3. The backend reads validated metadata and exposes health/metrics (accessible via Grafana/Kibana/Splunk URLs).
• Architecture notes:
  • Componentized rather than a “pure” microservices mesh: separate deployments and scaling for frontend, backend, and validator.
  • Components communicate indirectly via GCS artifacts rather than direct REST calls.

DevOps, CI/CD and deployment

• CI/CD:
  • In-house CI product “Quark” used in place of Jenkins.
  • Pipeline: build JAR → push to Artifactory → deploy to Kubernetes.
  • CI gating requires tests and JUnit coverage (example gate: >80% coverage) before validated metadata is accepted.
• Containerization and Kubernetes:
  • Docker image packaging and Kubernetes deployment used.
  • Common pitfalls:
    • Externalized config/files must be mounted and correct paths provided in Kubernetes (works locally on Docker Desktop but can fail on cluster if paths are wrong).
    • Logback configuration and log file paths must be container-aware.
  • Spring Boot’s embedded Tomcat (executable JAR) simplifies deployment but trades off some server-level control.
• Git workflow:
  • Fork, frequently pull latest changes, resolve merge conflicts using IDE tools (IntelliJ/Eclipse).
  • Rebase mentioned to keep feature branches current.

Spring Boot specifics & best practices

• @SpringBootApplication includes @EnableAutoConfiguration, @ComponentScan, and @Configuration. Auto-configuration finds beans in the base package; use @Primary or @Qualifier to resolve bean conflicts.
• Actuator:
  • Add spring-boot-starter-actuator to monitor health and expose endpoints used in CI gating.
  • Protect actuator endpoints in production (IP whitelisting, HTTPS, role-based access).
• Properties and profiles:
  • Use application.properties and profile-specific files (e.g., application-dev.properties, application-staging.properties) to vary DB/URL/config without code changes.
• Transactions:
  • Use @Transactional for rollback semantics (example: save user details + payment — roll back saved details if payment fails).
  • External/distributed transactions (JTA) acknowledged but not used in D’s projects.
• Exception handling and validation:
  • Global error handling via @RestControllerAdvice to centralize exception handlers (leveraging AOP concepts).
  • Standardize API error responses (fields like error, errorCode) and map codes/messages in properties for user-friendly messages.
• Other Spring features:
  • Spring Security (JWT), Spring Data JPA (repositories/JPQL), optional Flyway referenced, Spring Boot caching support.

Validation architecture & techniques (major focus)

• Problem characteristics:
  • Metadata JSON files are large, deeply nested, and may contain recursive references (parent → child → sub-child back to parent).
  • Validation rules are complex and conditional (e.g., if URL is Grafana then dataSourceId must be present).
  • Standard annotation-based validation (javax.validation) was insufficient for conditional and recursive rules.
• Implemented approach:
  • Deserialize JSON into POJOs.
  • Use custom validators and per-element traversal to validate nested structures.
  • Use Java Predicate-based checks for conditional business rules and Optional to avoid NPEs when reading properties.
  • Keep validation logic in service/validator layer rather than relying solely on controller-level annotations.
• CI gating:
  • The validation pipeline enforces unit tests and coverage thresholds before uploading validated metadata to the destination GCS.

Security & authentication

• Authentication:
  • JWT tokens used; previously used OAuth provider in other contexts.
  • Credentials stored encrypted in GCS for this implementation (services query storage to validate).
• Authorization:
  • Mapping of user → allowed applications; JWT token used for subsequent requests.
• API security strategies:
  • JWT, role-based endpoint access, IP whitelisting, HTTPS. MFA suggested for frontend.

Caching & performance

• Caching approaches:
  • In-memory cache using Spring Boot’s default caching (used in current project).
  • External cache (Redis) used in prior projects but experienced reliability issues (Redis outages); critical data must not rely solely on cache.
• Parallel processing:
  • Parallel streams useful for CPU-bound, independent operations (e.g., filtering large lists).
  • Avoid parallel streams for ordered or global-consistency operations (e.g., sorting, ordered reductions).
• Performance tools:
  • Dynatrace for tracing and leak detection.
  • Java Flight Recorder and Eclipse Memory Analyzer for CPU/memory analysis.

Concurrency, memory and serialization

• Concurrency:
  • synchronized rarely used; prefer event-driven approaches (pre-insert/post-insert listeners) for async/event actions.
• Memory:
  • Use profilers and tracing (Dynatrace) and heap analyzers to investigate leaks.
  • Newer JVM GCs like ZGC mentioned for low-pause requirements.
• Serialization/deserialization:
  • JSON ↔ POJO conversions are typical; need careful handling for complex JSON.
  • Configure deserializer beans via configuration to make the pipeline consistent and place validation in the appropriate layer (service vs controller).

Design patterns and architecture decisions

• Patterns discussed:
  • Post/Redirect/Get (PRG) to avoid duplicate submissions.
  • Builder pattern for complex object construction.
  • Singleton: Spring beans are singletons by default.
  • MVC with constructor injection preferred for immutability and testability.
• Microservices vs monolith guidance:
  • Microservices: good for fine-grained scaling, independent deployment, resilience when many teams and services exist.
  • Monolith: simpler to manage for small apps; easier deployment/maintenance when scale is limited.
  • Recommendation: choose based on scope/scale — no universal answer.

Testing, process and team practices

• Agile process:
  • 1-week sprints, with separate dev-only or test-only stories and frequent demos to management.
• CI gating:
  • Unit tests and coverage checks enforced in pipeline (example: >80% coverage as a gate).

Tools and IDEs

• Preferred IDE: IntelliJ (also Eclipse used).
• API testing: Postman.
• Source control: Git (common commands: pull, commit, push, rebase via IDE).

Example coding notes (Stream API)

• Filter integers whose string starts with digit ‘1’:
  • Convert to string and use startsWith("1") or substring(0,1).equals("1"), then distinct() and collect() to a list.
• Find top 3 max/min numbers:
  • Sort and use limit(3) or sort with comparator and limit, then collect().

Practical troubleshooting anecdotes

• Docker Desktop vs cluster differences:
  • Problems arose because externalized resource mounts and logback file paths worked locally but failed on the cluster until corrected.
• Redis outages:
  • Redis instability forced fallback to in-memory cache; lesson: avoid relying solely on a volatile external cache for critical data.

Career advice / closing points

• Don’t copy-paste solutions from Google/ChatGPT without understanding them — dig into fundamentals to learn and produce robust long-term solutions.

Main speakers / sources

• D — Interviewee (Senior Java / Spring Boot developer, 10 years experience).
• Fan — Interviewer / host.