I’m a senior backend developer with 25 years of experience, mostly in Singapore. In my recent role, I led a migration from a legacy Java app to Spring Boot microservices, which improved deployment frequency by 3x. I’m strongest in Java, Spring Boot, and database optimization. I’ve also worked with React, CI/CD, and I’m currently deepening my Kafka and Kubernetes skills. I’m looking for a role where I can help modernize enterprise systems

· Prepare 6 project stories in STAR format.

· Do 2 mock interviews before the next real one.

API started failing in production. What do you do?

First, I'd assess impact: all users or a subset. Then I'd check application logs and correlation IDs. Next I'd determine whether failures originate from the application, database, or downstream dependencies. If the issue is critical, I'd initiate incident response, stabilize the system, and identify rollback options

First, I’d check the last 30 minutes of logs for that API. Second, I’d verify if the failure is consistent or intermittent. Third, I’d roll back the last deployment if nothing else changed. If no dashboard exists, I’d add structured logging immediately

First I would confirm whether the issue is user-specific or system-wide. Then I would check logs, trace IDs, recent deployments, and downstream dependencies. If needed, I would isolate the failing service and roll back the last change. The goal is to restore production quickly while preserving evidence for root-cause analysis

IMPACT

Who is affected?

All users? Specific users?

EVIDENCE

Logs

Metrics

Alerts

Recent deployments

ISOLATE

Application?

Database?

External service?

Infrastructure?

STABILIZE

Rollback

Restart

Disable feature

Failover

ROOT CAUSE

Why?

How to prevent recurrence?

Convert Java application to Spring Boot REST API with minimal changes.

I'd preserve the service layer, expose it through REST controllers, externalize configurations, replace direct JDBC with Spring Data where appropriate, and migrate incrementally using strangler pattern principles

Increase from 200 APIs/minute to 2000 APIs/minute.

If I cannot change infrastructure, I’d first optimize database queries and add caching. Then I’d profile the API to find bottlenecks. Finally, I’d use connection pooling and async processing if the workload allows

Key lesson:
Always clarify constraints first:
“Am I allowed to add more servers, change code, or only tune the existing setup?”

Step 1

Measure.

What is the bottleneck?

CPU?

Memory?

Database?

Thread pool?

Connection pool?

External API?

Step 2

Tune.

Tomcat threads.

JDBC pool.

Cache.

SQL optimization.

Connection reuse.

Step 3

Load test.

Step 4

Then scale horizontally.

Only then talk about Kubernetes.

6. PostgreSQL Migration

I would first inventory Oracle-specific constructs such as packages, sequences, global temporary tables, materialized views, and PL/SQL procedures. Then I'd classify what can be automatically converted and what requires manual redesign into PostgreSQL functions, sequences, and partitioning. Finally, I'd perform reconciliation testing

AI Question

I use GenAI to accelerate repetitive tasks such as generating unit test skeletons, documentation, and boilerplate. However, all generated output is reviewed carefully, especially for security-sensitive banking applications.

PREP Framework

Point

"My first step is impact assessment."

Reason

"Because the resolution approach differs."

Example

"For example, if all users fail, I'd suspect infrastructure."

Point

"Then I'd investigate logs."

This makes you sound like an architect.

Stop Overselling

My strongest contribution is leading enterprise Java modernization initiatives while remaining hands-on with troubleshooting and delivery

40%

Production scenarios

· API failures

· Thread dumps

· Memory leaks

· DB bottlenecks

· WebLogic incidents

· Scaling

20%

Migration scenarios

· Oracle → PostgreSQL

· Monolith → Spring Boot

· WebLogic → Kubernetes

· EJB → Spring

20%

Multithreading

· Deadlocks

· Executor tuning

· ThreadLocal leaks

· Atomic vs LongAdder

· Virtual Threads

10%

Spring Boot internals

· Transactions

· AOP

· Security

· Performance

10%

Behavioral questions

· Why change?

· Conflict management?

· Leadership examples?

· Production incidents you handled.

Action:
Review these terms before your next interview:

· Strangler pattern

· Circuit breaker

· Bulkhead

· CQRS (if relevant)

· Orchestration vs choreography

scenario-based interviews with strict s

I’m a senior Java developer. In my last project, I migrated a legacy system to Spring Boot microservices, reducing deployment time by 40%.

· We used Spring Boot to solve slow startup and manual config. I set up auto-configuration and externalized properties.
Prepare 3–4 crisp stories (migration, performance, scaling, debugging).

· Practice answering “What problem did you solve?” in 60 seconds.

Scenario 1: Production APIs Suddenly Fail

Interviewer

All APIs are failing in production. What do you do?

First, I'd assess the impact: whether all users are affected or only a subset. Then I'd investigate recent deployments, application logs, and correlation IDs to identify whether the issue originates from the application, database, or downstream services. I'd also check infrastructure health such as thread pools and connection pools. Once identified, I'd stabilize the system by rolling back the release, restarting affected components, or redirecting traffic if required. Finally, I'd perform root cause analysis and implement preventive measures.

Scenario 2: Throughput Must Increase from 200 to 2000 APIs/minute

Interviewer

How would you do it?

I wouldn't immediately scale infrastructure. First, I'd identify the bottleneck using metrics: CPU, memory, database response times, Tomcat threads, and JDBC pool utilization. Then I'd optimize inefficient SQL, introduce caching where appropriate, and tune thread pools and connection pools. I'd validate improvements using load testing. Only if capacity is still insufficient would I introduce horizontal scaling through clustering or container orchestration.

Scenario 3: Deadlock in Production

Interviewer

Users complain the system hangs.

I'd immediately capture thread dumps using jstack or kill -3 and look for Java-level deadlocks. If confirmed, I'd identify the conflicting locks and determine whether a restart is necessary. For permanent resolution, I'd redesign the locking strategy using consistent lock ordering or move critical concurrency control to the database using transactional locking.

Scenario 4: Oracle to PostgreSQL Migration

Interviewer

How would you approach it?

I'd first inventory Oracle-specific constructs such as packages, sequences, materialized views, PL/SQL procedures, and temporary tables. Then I'd classify them into automatically convertible components versus those requiring redesign. I'd migrate schemas and data incrementally, rewrite Oracle-specific logic into PostgreSQL functions where necessary, and perform reconciliation testing to ensure functional equivalence.

Scenario 5: Memory Leak

Interviewer

Production JVM keeps crashing.

I'd capture heap dumps and analyze them using Eclipse MAT to identify dominant objects and retention paths. I'd correlate this with GC logs and thread dumps to determine whether the issue is caused by caching, ThreadLocal misuse, session growth, or application bugs. Once identified, I'd fix the leak, validate under load, and establish monitoring thresholds.

Scenario 6: Monolith to Spring Boot

Interviewer

How would you migrate?

I would avoid a big-bang rewrite. I'd use an incremental strangler approach, preserving existing business logic while exposing selected functionality through Spring Boot REST APIs. Configuration would be externalized, testing automated, and migration performed feature by feature to minimize business risk.

Scenario 7: High Database Response Time

Interviewer

APIs are slow because of database delays.

I'd identify the slow SQL using AWR reports or query monitoring tools. Then I'd examine execution plans, indexes, and statistics. I'd eliminate unnecessary database round trips, batch operations where appropriate, and tune connection pools. If needed, I'd introduce caching for frequently accessed read-only data.

Scenario 8: External Service Dependency Failure

Interviewer

Downstream SOAP service becomes unavailable.

I'd implement resilience patterns such as timeouts, retries with exponential backoff, and circuit breakers to prevent cascading failures. Depending on business requirements, I'd either queue requests for later processing or return meaningful fallback responses while maintaining audit trails.

Scenario 9: Duplicate Payment Processing

Interviewer

Same payment processed twice.

I'd first identify whether duplicate requests originated from retries, redelivered messages, or user actions. To prevent recurrence, I'd implement idempotency using unique transaction references and enforce constraints at the database level. In financial systems, idempotency is critical because retries are expected.

Scenario 10: WebLogic Stuck Threads

Interviewer

Multiple stuck thread alerts.

I'd collect thread dumps and identify whether threads are blocked on database calls, external dependencies, or synchronization locks. I'd review JDBC pool metrics and recent changes. If necessary, I'd stabilize the environment by isolating problematic components, then implement fixes such as query optimization, timeout configurations, or lock redesign.

Scenario 11: ThreadLocal Leak

Interviewer

Explain ThreadLocal issues.

ThreadLocal itself isn't a problem, but in application servers using thread pools, failing to clear ThreadLocal values can cause memory leaks because worker threads live for a long time. Therefore, ThreadLocal values should always be removed in a finally block.

Scenario 12: Banking Transaction Consistency

Interviewer

Two withdrawals happen simultaneously.

I'd ensure transactional consistency using database locking mechanisms such as SELECT FOR UPDATE or optimistic locking with version checks. In clustered environments, I prefer database-level controls because JVM synchronization only protects a single instance.

Golden Rule for Senior Interviews

When asked any scenario, think:

Impact → Investigate → Stabilize → Prevent

Situation → Investigation → Resolution

Don't start with technologies.

Better closing:

“Based on our discussion, is there any specific area — like migration, scaling, or debugging — where you’d like me to go deeper?”

Area Action Item

Introduction 60 sec: role + recent project + measurable impact.

Scenario answers First 3 concrete steps. Clarify constraints.

Closing Ask specific, forward-looking question.

· Tell me about yourself.

· Describe a Spring Boot migration you worked on.

· How do you debug an API failure in production?

· How do you migrate a legacy Java app with minimal change?

· How do you handle traffic growth from 200 to 2000 requests per minute?

· Explain orchestration vs choreography.

· How do you convert Oracle SQL to PostgreSQL with minimal impact?

· What is your experience with CI/CD and deployment?

· How have you used AI in development or testing?

· Why are you looking for a change now?

backend Java/Spring Boot, migration, database tuning, deployment, and troubleshooting. Keep React, Kubernetes, Kafka, and AI as supporting skills unless the role specifically asks for them.

How do you debug an API failure in production?

1. Clarify the symptom.

2. one user, one service, or everyone.

3. Reproduce or isolate the issue.

4. Inspect logs, metrics, and trace IDs.

5. Form a root-cause hypothesis and validate it.

6. Fix, retest, and monitor.

My first step is to confirm the scope of the issue, whether it is one user, one API, one service, or a system-wide failure. Then I try to reproduce the problem and check recent changes, logs, error codes, and trace or request IDs. If it is a microservices flow, I follow the request across services and compare the failing path with a successful one. After I identify the root cause, I apply the fix, run regression tests, and monitor the system to ensure the issue does not return

Try answering this in 45 seconds:

· “An API is failing in production. What do you do first?”

Your ideal order should be:

· scope,

· reproduce,

· inspect evidence,

· isolate cause,

· fix,

· verify.

1. State the problem briefly.

2. Explain what you tried.

3. Explain why it was still unresolved.

4. Say how you escalated or worked around it.

5. End with what you learned.

I worked on a production issue where the root cause was not immediately clear. I checked logs, reproduced the problem, and compared failing and working requests. I was able to narrow it down, but I could not fully resolve it within my scope because it required dependency-team changes. I escalated it with evidence, helped verify the fix after their update, and learned to isolate the issue faster by checking upstream/downstream dependencies earlier.

1. Identify the current Spring Boot and Java versions.

2. Review breaking changes and incompatible libraries.

3. Migrate one module or endpoint first.

4. Keep old and new flows running in parallel if needed.

5. Test thoroughly after each step.

6. Monitor logs and performance after deployment.

Avoid saying only “adapter pattern” unless you explain what problem it solves. In your case, say that it helps keep the legacy path working while the new Spring Boot APIs are introduced gradually.

For a Spring Boot migration, I normally follow an incremental modernization strategy. First I assess the application to understand the architecture, module boundaries, external integrations, database access, and any framework or JDK constraints. I also identify which parts are tightly coupled and which parts can be moved with minimal change.
Next, I define the migration path. In many cases I prefer a strangler-style approach, where I place a layer in front of the legacy system and gradually route selected functionality to the new Spring Boot implementation. I usually begin with a simple, low-risk module so I can validate the patterns, update the dependency management, and make sure the new configuration works correctly.
Once that part is stable, I refactor the build, properties, security settings, and any outdated libraries. I also verify API compatibility, database connectivity, and test coverage. If the migration affects multiple services or modules, I move step by step and keep monitoring logs and runtime behavior after each release. The main goal is to reduce risk, preserve business continuity, and prove stability before expanding the migration further.

· “I assess first.”

· “I migrate in stages.”

· “I keep the old path working when needed.”

· “I test after each step.”

· “I monitor after release.”

“The current legacy application is harder to maintain, more vulnerable to security issues, and slower to change.”

“That increases support effort, delivery time, and operational risk.”

“I would migrate incrementally to Spring Boot so we reduce risk while modernizing the platform.”

“We would validate each step with testing and monitoring.”

“The result is a more supportable system with lower long-term cost and better agility.”