Background: 6 years of experience in Java, Spring Boot, Kafka and Solr, currently a lead developer at a SaaS company.
Rounds covered: Round 2 (LLD) and Round 3 (Hiring Manager / technical deep dive).
Round 2: Low-Level Design (about 70 mins)
Format: The interviewer shared a problem statement in a collaborative doc, and I shared my screen and coded in my own IDE. There were two interviewers, and one led.
Problem: Smart Locker Delivery System
A hub has 10-20 lockers in small, medium and large sizes. A small package fits any locker, and a large package fits only a large locker.
A delivery agent deposits a package and the system auto-allocates a locker.
The system generates an OTP for the customer, who picks up the package using the OTP.
Bookings have a TTL and expire after a set time.
The allocation strategy must be pluggable (smallest-fit, random, etc.).
The system must be thread-safe.
How it went
Requirements and classes (first 10 mins). I listed Locker, Package, Booking, a manager class, and the enums LockerSize, LockerState and PackageStatus. The interviewer asked me to be specific about fields and methods. I started with two locker states and corrected it to three: AVAILABLE, OCCUPIED, OUT_OF_SERVICE.
Strategy pattern. I proposed a LockerAllocationStrategy interface with smallest-fit and other implementations. The interviewer liked this and clarified that the strategy only selects a locker. Occupying it, generating the OTP and notifying the customer belong to the service.
Coding. I wrote the enums, Locker (id, size, mutable state) and Booking (id, locker, OTP, expiry, status, isExpired()) in the IDE. I walked through SmartLockerService at pseudocode level:
deposit: get a locker from the strategy, mark it occupied, generate a 6-digit OTP, set the expiry, create a booking, store it in a map keyed by OTP.
retrieve: look up the booking by OTP, check null, status and expiry, mark it delivered, free the locker, remove the OTP.
Concurrency (longest discussion). The interviewer kept pushing on it:
First I proposed a synchronized method, and he asked about performance.
Then I narrowed it to a synchronized block around only the “pick locker and mark occupied” step.
We discussed thread-safe structures: ConcurrentHashMap, Collections.synchronizedList, CopyOnWriteArrayList, and ReentrantLock per locker.
His point: only the check-and-occupy step needs to be atomic, so keep the critical section as small as possible.
Layering and design principles. He asked which class the client talks to. His feedback was to separate the customer-facing entry point (deposit and pickup) from admin operations (add locker, mark out of service), and to expose the service through a controller layer that validates requests.
What went well: clean class modelling, the Strategy pattern, and a clear explanation of the retrieve flow and edge cases.
What could have been better: I was slow to arrive at the service-layer separation (customer vs admin interfaces) and at fine-grained locking. The service logic stayed at pseudocode and wasn’t fully coded.
My questions: I asked about current engineering challenges. He described a roughly 10-year-old legacy codebase and ongoing modernisation.
Round 3: Hiring Manager / Technical Deep Dive (about 40 mins)
Format: Mostly conversational but deeply technical. It started with my intro and a deep-dive on my own project, then moved to follow-up fundamentals.
Topics and questions
Monolith → microservices. Why did you split it? Why did memory spike while indexing 1 lakh rows into Solr? Why not just read and push in batches of 5,000? My answer was debuggability, isolation, and real-time throughput via Kafka instead of batch latency.
Kafka. Role in the workflow, and the limit on consumers (bounded by partitions; I had 47). I also covered rebalancing, heartbeat and poll timeouts, and alerting on consumer lag.
My custom timeout design. I ran Solr indexing in a separate thread with a 60s wait, and parked slow events in a DB so the consumer wouldn’t be marked dead. He challenged this repeatedly: why not just set a client request timeout? I defended it by saying the timeout needed to cover application logic and not just the Solr call. He eventually accepted it, but the discussion was long.
Java 21 and virtual threads. What advantage, and does a virtual thread block on an I/O call?
Spring. Timeout annotations, AOP, custom annotations, and global exception handling. I knew @Service and @Component and handled exceptions with try/catch and custom exceptions, but I had no working knowledge of AOP or @ControllerAdvice.
Monitoring. Datadog for CPU and memory, and MSK for consumer lag, with alerts maintained by SRE.
GenAI search project. Intent detection with an LLM through Bedrock, then a RAG knowledge base, then a Solr query, then semantic re-ranking. He probed who computes the confidence score and what exactly RAG does in the flow.
Idempotency (the toughest part). I explained idempotency keys. Then: two parallel requests with the same key both read “not found” and both insert. What now? I fumbled. I suggested a queue and synchronized, then discussed MySQL locks, optimistic vs pessimistic locking, and the transaction annotation. I hadn’t implemented locking in production and said so.
Closing. He explained the proper fixes after the fact: unique composite indexes, optimistic and pessimistic locking, short-term locks, and scenario testing for concurrent calls.
What went well: a strong narrative on architecture and Kafka, honesty about what I hadn’t done, and a clear motivation for fintech.
Honest takeaway: He told me directly that he saw technical gaps and that for SDE-3 he expects much deeper knowledge (“deeper, more deeper”). He also asked how motivated I am and said technology can be learned in a couple of months if the person is driven. He said he’d check feedback from the other rounds before deciding. Logistics covered: 5-day office in Gurgaon and a notice period of about a month.
Key lessons for future candidates
Concurrency is a must at SDE-3. Know synchronized vs ReentrantLock vs concurrent collections, and keep critical sections small.
Idempotency under parallel requests: unique constraint, atomic insert, SELECT ... FOR UPDATE, optimistic versioning.
Spring internals: AOP, @ControllerAdvice, @Transactional, @Version, and timeout and retry patterns.
Kafka internals: consumer groups, rebalancing, offsets, lag.
Be ready to defend every design decision. Interviewers will push on it.
Separate customer-facing and admin interfaces in LLD, and keep the strategy responsible only for selection.
I left out names, the other candidate details in the transcript, and your personal and family details. I can turn this into a file (Word or Markdown), shorten it for a LinkedIn or LeetCode post, or add an outcome section once you hear back.
Verdict: Rejected ❌
I did not get the offer. The feedback after Round 3 matched what I felt in the room:
Round 2 (LLD): Good on class design and the Strategy pattern. I was slower to reach fine-grained concurrency and the service-layer separation, and the service logic stayed at pseudocode.
Round 3 (Hiring Manager): The gaps were in depth, not breadth. The hiring manager’s bar for SDE-3 was “go deeper, and deeper.” I struggled with the parallel-request idempotency scenario, locking (optimistic vs pessimistic), Spring AOP and global exception handling, and some of the finer details of my own Kafka and GenAI work.