Q: Are you still working with Wells Fargo?
A: Yes, I was working with Wells Fargo until recently. My role there was as a Java
developer in a Spring Boot-based microservices project. I’m now exploring new
opportunities for better growth and exposure to cloud technologies.
Q: The project you worked on — was it a maintenance or a development
project?
A: It was a complete development project. I was involved from the design phase through
implementation and deployment, building microservices from scratch using Java 17,
Spring Boot, and Kafka.
Q: How about the code repository in that project?
A: We used GitHub Enterprise for source control. Each developer created feature
branches, raised pull requests, and followed standard branching strategies like main,
develop, and feature/*.
Q: What is your experience in building microservices?
A: I’ve been building and maintaining Spring Boot microservices for about five years, using
REST for synchronous calls, Kafka for asynchronous messaging, and Docker/Kubernetes
for containerization.
Q: What are the design patterns you follow to build microservices?
A: We used Circuit Breaker (Resilience4j), Retry and Fallback, API Gateway, Repository,
and DTO patterns for clean architecture and fault tolerance.
Q: Can you explain about the Circuit Breaker pattern?
A: Circuit Breaker prevents repeated calls to a failing service. It has Closed, Open, and
Half-Open states. Implemented using Resilience4j with fallback methods for stability.
Q: How exactly does inter-service communication happen between
microservices?
A: We used REST APIs over HTTP for synchronous calls and Kafka for asynchronous
communication to decouple services.
Q: Why do we need to have a Zookeeper in the Kafka system?
A: Zookeeper manages Kafka brokers, coordinates leader election for partitions, and
tracks cluster metadata. In new Kafka versions, it’s being replaced by KRaft mode.
Q: The one which you worked earlier — was it an Agile project?
A: Yes, we followed Agile Scrum with two-week sprints, daily stand-ups, sprint planning,
and retrospectives. Jira was used for tracking.
Q: What are the milestones or things you celebrate as part of the design
process?
A: We celebrated sprint completions, UAT sign-off, and release deployments. During
design, we reviewed architecture and confirmed NFR compliance before development.
Q: Suppose you got a requirement, completed it, testing is done, client
testing is also finished — but later, the client wants to add extra points not
covered in the user story. How will you handle it?
A: I’d validate if the new points are enhancements or defects. If enhancements, I’d explain
they’ll be added as new user stories for the next sprint to maintain transparency.
Q: What if the client asks to fix it as a defect even though it’s a new change?
A: I’d explain that a defect means deviation from acceptance criteria. If it’s new, I’d provide
reference to the original story and suggest a change request or discuss with PO for a quick
fix.
Q: Can you explain your overall CI/CD process?
A: We used GitHub Actions for CI/CD. CI ran unit tests, SonarQube, Checkmarx scans.
CD built Docker images and deployed via Kubernetes with environment-based approvals.
Q: You created a feature branch and made some code changes, but
meanwhile, other changes were merged into main, causing merge conflicts.
How will you handle them?
A: I’d pull the latest main branch, merge into my feature branch, resolve conflicts manually,
test again, and raise a fresh pull request for review and merge.