Walmart SDE 3 Interview Experience

Round 1: Data Structures & Algorithms

I was asked two medium-level LeetCode problems. The interviewer was flexible, allowing me to use a Word document or an IDE. My approach involved clearly explaining my proposed solution first, and once the interviewer was satisfied, I proceeded to code it and dry-run with a few test cases. Running the code wasn't a mandatory step.

Round 2: Low-Level Design & High-Level Design

This round focused on designing the feeds section of Instagram/Facebook. I started by meticulously gathering requirements and asking numerous questions to define the scope, such as whether posts included only text or images, the information to be stored with each post for data modeling, consistency requirements (I assumed eventual consistency), and various user interaction methods (likes, comments, replies, nested replies, sharing, saving). Next, we discussed database design—what type of database for what kind of data—and I listed out table attributes. Scaling was the next topic, leading to a discussion on caching strategies and eviction policies. The interviewer then asked me to implement the caching logic for an LFU strategy. Fortunately, I had recently studied this, and I was able to write the necessary classes, interfaces, and caching logic. The LLD logic was written on a Word document, but it can vary by interviewer; they are primarily interested in design patterns and adherence to SOLID principles. I'd also recommend using a whiteboard to map out classes, though I knew what I wanted to do and didn't spend much time there.

Round 3: Hiring Manager

This round was heavily concentrated on my resume, with the interviewer asking in-depth questions about every line and technology I had mentioned, lasting for about 1 hour and 40 minutes. A significant portion of the time was spent discussing my projects; I had to explain the problem statement and expect 'why' for every answer I provided. We had extensive discussions about Microservices and monolithic architectures, including suitable systems for each, transition strategies from monolith to microservice, and the rationale behind adopting microservices. Many questions revolved around Kafka and its internals—topics, partitions, consumers, consumer groups, why partitions exist, factors affecting throughput, and the interplay between consumers and partitions. I also faced questions about GraphQL, as I had used it in previous projects, covering why we use it, its advantages, queries, mutations, and resolvers. I was then given a design problem: to create a system that picks tasks from a database and schedules them to run at a specific time. I had to identify all potential bottlenecks, such as queue sizes, partition counts, concurrent database connections, and network issues, to demonstrate my end-to-end debugging capabilities. Lastly, given my performance testing background, the interviewer asked how it was done in my past projects and the various testing types required before a project goes live. This final round was quite challenging, and I couldn't answer all questions, leading to me not being selected after the HM round. Nevertheless, this experience was incredibly valuable for preparing for my next interviews.