Company Round Scenarios

Tests whether you know how to use thread dumps and profilers to find a runaway loop or lock contention that logs alone won't show.

Tests whether you know this is the classic signature of a memory leak — objects still reachable that shouldn't be — and how heap dump analysis finds it.

Tests whether you know GC pause time depends on more than heap occupancy — fragmentation, GC algorithm choice, and region sizing matter too.

Tests whether you know slow leaks (unbounded caches, listener leaks, ThreadLocal misuse) take time to surface and aren't tied to a deploy.

Tests whether you know low CPU with high queuing usually points to threads blocked waiting on I/O, not a CPU bottleneck.

Tests whether you know these aren't synonyms — coupling, communication protocols, and team ownership all differ.

Tests whether you know DDD is the actual discipline behind 'good service boundaries,' not just a buzzword to drop.

Tests whether you know config, backing services, and stateless processes matter more than the rest for this architecture style.

Tests whether you can push back on premature decomposition instead of defaulting to microservices as automatically 'better.'

Tests whether you know blocking I/O versus a reactive Netty core is the real reason Gateway replaced Zuul 1.

Tests whether you connect the choice to blocking vs non-blocking behavior, not just API ergonomics.

Tests whether you know how to design idempotent processing instead of trying to guarantee exactly-once delivery, which most brokers don't offer by default.

Tests whether you know how an idempotency key on the client request prevents duplicate processing server-side.

Tests whether you know to separate transport-layer success from application-layer correctness — caching, replication lag, or stale reads are common culprits.

Tests whether you can actually design an idempotency-key mechanism end to end, not just name the pattern.

Tests whether you know binary Protobuf and HTTP/2 streaming pay off for low-latency internal service calls, not public APIs.

Tests whether you know cursor pagination stays correct even as rows are inserted or deleted mid-scroll.

Tests whether you know consumer-driven contracts let services deploy independently without a shared integration environment.

Tests whether you know circuit breakers, timeouts, and bulkheads are what actually stop one slow dependency from taking down everything downstream.

Tests whether you know how failure-rate threshold, sliding window size, and slow-call-duration settings actually control breaker sensitivity.

Tests whether you know how a propagated correlation/trace ID and distributed tracing (Zipkin, Jaeger) turn this into a solvable problem.

Tests whether you know modern Kafka has real tools to avoid the classic stop-the-world rebalance pain.

Tests whether you know exact-match routing versus wildcard-pattern routing versus broadcast, and when each fits.

Tests whether you know a persisted 'already processed' record is what actually makes a handler safe to call twice.

Tests whether you know this is a cache avalanche/stampede, and can name real mitigations like jittered TTLs or request coalescing.

Tests whether you know a hot key can bottleneck a cluster regardless of total capacity, and how local caching or key splitting helps.

Tests whether you know why a distributed counter (like Redis-backed) is needed instead of an in-memory counter on each instance.

Tests whether you know to check for connection leaks (unclosed connections), a misconfigured pool size, or a sudden spike in concurrent traffic post-deploy.

Tests whether you know how to spot N+1 via SQL logging or an APM tool, and fix it with fetch joins or EntityGraph.

Tests whether you know low CPU with rising lag usually points to a slow downstream call inside the consumer, not a compute-bound processing loop.

Tests whether you know to route unprocessable messages to a dead-letter topic instead of blocking the whole partition indefinitely.

Tests whether you know rebalances can reassign a partition before an offset commit lands, and why consumer-side idempotency is the real fix.

Tests whether you know to check load balancer deregistration delay, DNS caching, and connection draining settings.

Tests whether you know to check rollout status, readiness probes, and whether the deployment is stuck on a failing pod.

Tests whether you know about @RefreshScope and Spring Cloud Bus for propagating config changes to live instances.

Tests whether you know to check for missing dependency caching, network-bound repository access, and parallel build configuration in CI.

Tests whether you know a naive lock can still let a stale, slow process act after losing the lock — fencing tokens close that gap.

Tests whether you know there's an actual formula behind pool sizing, not just picking a round number and hoping.

Tests whether you know the isolation-strength versus operational-complexity tradeoff between the two approaches.

Tests whether you know CDC lets you build a denormalized read store without touching the write-side service's code at all.

Tests whether you know dual credentials and a gradual rollover are what make rotation invisible to running traffic.

Tests whether you know real JWT vulnerabilities beyond 'just check the signature.'

Tests whether you know to allowlist domains and specifically block internal metadata IP ranges like 169.254.x.x.

Tests whether you know Istio or Linkerd can automate certificate exchange and rotation instead of hand-rolling it per service.

Tests whether you know Broken Object Level Authorization and Excessive Data Exposure are the two most common real-world findings.

Tests whether you know keys should be hashed at rest, prefixed for fast lookup, and support rotation and per-key rate limiting.

Tests whether you know to check gateway-level timeouts, connection pool limits, and TLS/handshake issues that never reach the backend's own logs.

Tests whether you know to suspect load-balanced instances serving stale data, race conditions, or a caching layer with inconsistent state.

Tests whether you know to check the execution plan, missing indexes, and whether staging data volume was too small to expose the problem.

Tests whether you know to check container logs, exit codes, resource limits (OOMKilled), and health check configuration.

Tests whether you suspect an unbounded thread pool or a blocked downstream call causing threads to pile up, rather than assuming it's simply high traffic.

Tests whether you identify lock contention and coarse-grained locking as the culprit, and know to narrow lock scope or use concurrent collections instead of blanket synchronization.

Tests whether you'd profile startup phases (classpath scanning, bean creation, connection pool warmup) to find the actual bottleneck, instead of guessing at JVM flags.

Tests whether you connect a delayed slowdown to something accumulating over time -- a leak, growing cache, or connection pool starvation -- rather than looking for a code regression.

Tests whether you look for a shared bottleneck -- a single database, a sticky-session load balancer, a lock -- that caps throughput regardless of instance count.

Tests whether you have a structured triage process -- assess impact, mitigate first, then root-cause -- rather than jumping straight to a code fix under pressure.

Tests whether you treat RCA as a separate step from the fix -- documenting the actual cause and adding a guardrail -- rather than closing the ticket once the symptom disappears.

Tests whether you'd check execution plans and indexes before reaching for more hardware, and whether you can tell a query problem from a connection-pool or lock-contention problem.

Tests whether you know thread pool isolation gives stronger isolation at higher resource cost than semaphore-based limiting.

Tests whether you know jitter is what prevents every client from retrying in lockstep and re-creating the thundering herd.

Tests whether you know the point is deliberately injecting failure to verify circuit breakers and fallbacks actually work, not just exist.

Tests whether you know one throws immediately (open circuit) while the other silently returns a default value — different failure philosophies.

Tests whether you know RED is request-oriented (Rate/Errors/Duration) while USE is resource-oriented (Utilization/Saturation/Errors).

Tests whether you know OTEL is the vendor-neutral standard that replaced Sleuth starting in Spring Boot 3.

Tests whether you know multi-window burn-rate alerting catches real problems faster than a single static threshold alert.

Tests whether you know async profilers, JFR, and sampled distributed traces are the real tools for this exact situation.

Tests whether you can name a pattern and the real problem it solved in your codebase, rather than reciting a textbook definition with no project tied to it.

Tests whether you can narrate real ownership with specific decisions and trade-offs at each stage, rather than a generic recitation of the tech stack.

Tests whether you can describe a specific incident and your actual state of mind handling it, rather than a generic claim of staying calm under pressure.

Tests whether you understand how the frontend is structured and talks to your backend -- state management, API boundaries -- even as a primarily backend engineer.

Tests whether you can demonstrate maturity and focus on the work over title/ego, with a concrete reasoning rather than a rehearsed platitude.

Tests whether you can show self-awareness and a plan to seek feedback and improve, rather than defensiveness or a scripted non-answer.

Tests whether you can articulate a situational judgment -- when to move fast alone versus when to gather context first -- instead of picking one extreme as a universal rule.

Tests whether you can name the actual bottleneck you found and measure the before/after, rather than a vague claim of 'we optimized the queries'.

Tests whether you can speak concretely about where AI tooling fit into your actual workflow -- code review, codegen, ops -- rather than a generic 'yes, Copilot' with no detail.

Tests whether you know the actual tooling in your pipeline (SCA/SAST scanners, dependency alerts) and who triages findings, not just that security 'exists somewhere'.

Tests whether you can describe a genuine concurrency problem you solved -- parallel batch processing, async I/O -- with the actual synchronization mechanism used, not a textbook example.

Tests whether you can name concrete constraints -- strict consistency, auditability, regulatory compliance, idempotency on money movement -- rather than a vague 'it's more serious'.

Tests whether you can show genuine flexibility and a plan to ramp up on the unfamiliar side, rather than a reflexive preference for only your comfort zone.

Tests whether you describe end-to-end accountability -- design, edge cases, monitoring after launch -- rather than ownership meaning just writing the code.

Tests whether you can describe grounding the discussion in data and shared goals to find common ground, rather than deferring to seniority or picking a side.

Tests whether you can ground a hard call in explicit, pre-agreed criteria communicated transparently, rather than an outcome that looks arbitrary or favoritist.

Tests whether you know which workload shape (stateless, ordered/stable identity, one-per-node) each object type is built for.

Tests whether you know KEDA scales on external event sources (like Kafka lag) that HPA's CPU/memory metrics can't see.

Tests whether you know a JVM's real memory footprint is bigger than just -Xmx, and getting this wrong causes OOMKilled or CPU throttling.

Tests whether you know PodDisruptionBudget, readiness gates, and backward-compatible DB migrations all need to align.

Tests whether you know how eliminating the thread-per-request ceiling changes what's actually achievable at scale.

Tests whether you know limitRate() and the onBackpressure operators exist specifically to protect a slow consumer.

Tests whether you know GraalVM native images and CRaC are the real levers, not just 'use a smaller JAR.'

Tests whether you know unit tests should dominate by volume, with fewer integration and even fewer end-to-end tests above them.

Tests whether you know spinning up a real containerized database beats mocking the persistence layer for genuine confidence.

Tests whether you know high coverage can still hide weak assertions, and mutation testing is what actually catches that.

Tests whether you know an immutable, append-only store with correlation IDs is what makes an audit trail actually trustworthy.

Tests whether you know this needs a strangler-fig approach with an anti-corruption layer, not a risky one-shot cutover.

Tests whether you know active-active needs conflict resolution while active-passive trades that complexity for slower failover.

Tests whether you know to add characterization tests and extract leaf domains first, rather than attempting a risky big-bang rewrite.

Tests whether you can combine a Git-backed config server, environment overlays, and secret management into one coherent design.

A real Flipkart interview scenario testing whether you can design atomic inventory control under extreme concurrent load.

A real Walmart interview scenario testing whether you can combine four separate fixes into one coherent architecture.

A real Walmart interview scenario testing whether you've thought through what happens when your own fix becomes the new bottleneck.

A real Walmart interview deep-dive testing whether you can distinguish three commonly-confused caching failure modes and fix each correctly.

Tests whether you connect the fixed time to a scheduled job or resource leak, and know the JVM-metrics-then-heap-dump investigation order.

A real PayPal coding-round question testing whether you can recognize and implement a budget-constrained optimization pattern.

A real Google interview question testing whether you can trade off between recomputation and storage under a tight space constraint.

A real Google data-structure-design round testing whether you know bucket sort variations solve this cleanly.

A real PhonePe interview question testing whether you can design for financial correctness under partial failure.

A real Atlassian interview question testing whether you can model a highly configurable, permission-heavy domain at scale.

A real Accenture interview question that looks simple but tests genuine understanding of hashing internals.

One of the most commonly asked service-based-company questions — tests whether you understand the proxy mechanism, not just the annotation's existence.

Tests whether you can go beyond 'one is thread-safe' into the actual locking/CAS mechanism that makes it so.

Tests whether you look at what changed besides code -- traffic volume, a downstream dependency's health, DB query plans (stale stats causing a plan flip), or GC behavior -- since a latency jump with no deploy means the cause is external or environmental, not a code regression.

Tests whether you'd start with request rate and error rate correlated against latency (to see if it's a load-driven spike) and then drill into per-endpoint and per-dependency breakdowns, rather than opening every dashboard at once with no hypothesis.

Tests whether you suspect tail-latency causes invisible to average metrics -- GC pause spikes, lock contention, a slow downstream dependency affecting only some requests, or connection pool queueing -- since healthy aggregate metrics with a tail-latency problem points at something intermittent, not systemic.

Tests whether you'd pull a thread dump while the hang is happening to see exactly what each thread is blocked on (a lock, an I/O call, a connection pool wait) -- logs show what happened, a thread dump shows what's happening right now, which is what a hang needs.

Tests whether you suspect a resource with a hard ceiling unrelated to CPU -- connection pool size, thread pool queue depth, or a downstream dependency's own capacity limit -- since low CPU with rising latency under load means something is queueing, not computing.

Tests whether you check everything around the query -- serialization/deserialization cost, N+1 queries elsewhere in the request, downstream service calls, or connection pool acquisition wait -- since a fast query rules out the DB but says nothing about the rest of the request path.

Tests whether you'd diff the error distribution by endpoint/user segment to isolate which code path regressed, and check whether health checks even exercise the failing path -- a shallow health check passing tells you almost nothing about business-logic correctness.

Tests whether you systematically diff environment-specific factors -- config/secrets, data volume and shape, network topology, and scale (concurrency staging never sees) -- rather than assuming 'it's a flaky prod issue' without identifying the actual delta between environments.

Tests whether you'd segment by user/request attributes (region, device, specific data shape) to find the pattern behind 'random' -- true randomness is rare; it usually correlates with something your aggregate dashboards are averaging away.

Tests whether you'd capture a heap dump near the crash point and analyze dominator trees/retained size in a tool like Eclipse MAT to find what's holding references, rather than guessing based on code review alone -- production-only leaks often depend on data volume or traffic patterns local testing never reaches.

Tests whether you compare JVM-reported heap usage (via GC logs or JFR) against the container's actual RSS -- if RSS keeps growing while heap usage stays flat/bounded, the leak is native (direct ByteBuffers, native library allocations, Metaspace), not something a heap dump will show.

Tests whether you'd check if the cache has any eviction policy at all (unbounded caches are the real bug, not caching itself) and trace whether removing/bounding it breaks correctness elsewhere that relies on it being warm -- rather than ripping it out and assuming the symptom alone justifies that.

Tests whether you connect parallelism in the app to a proportional increase in concurrent DB connections/queries -- the app layer scaled, but the database's connection pool or query capacity didn't, so the bottleneck simply moved downstream instead of disappearing.

Tests whether you check the invalidation ordering -- is the cache invalidated before or after the DB write commits, and is there a race where a read repopulates the cache with the old value between the write and the invalidation -- rather than just assuming the cache TTL is too long.

Tests whether you'd grab a thread dump (or two, a few seconds apart) immediately -- it's the fastest single artifact that reveals blocked threads, lock contention, or a busy-spinning loop, giving you a concrete lead before you've spent any of your 10 minutes guessing.

Tests whether you can narrate real ownership with specific decisions and trade-offs at each stage (requirements ambiguity resolved, design choices made, what broke during rollout) rather than a generic SDLC recitation that could describe any project.

Tests whether you can show a systematic troubleshooting process (forming a hypothesis, narrowing scope, the specific tool or data that confirmed the root cause) rather than just describing the symptom and the eventual fix with the investigation skipped over.