How to Pass the Flipkart SDE 2 Machine Coding Round

Engineers across the Indian tech industry often view the Flipkart SDE-2 machine coding round as an incredibly intense technical evaluation. It isn't your standard algorithmic whiteboard session. Instead, this 90-minute crucible demands that you build a fully functional, object-oriented, and highly extensible system from scratch. You can't rely on external frameworks. Interviewers evaluate you on whether your code actually runs, sure, but they care just as much about how beautifully you structure it. One classic, recurring problem in this specific round is designing an in-memory multi-tier cache system. We're going to break down exactly how you should architect, code, and explain a modular cache system. You'll learn how to handle dynamic eviction and concurrency so you can walk into your Flipkart interview ready to perform.

The Flipkart SDE-2 Hiring Process

Before we look at the code itself, you need to understand exactly where the machine coding round fits into the broader Flipkart hiring pipeline. When evaluating SDE-2 candidates, Flipkart expects a very strong grasp of Low-Level Design (LLD), High-Level Design (HLD), and robust coding practices. The entire process typically breaks down into four main rounds.

Think of the machine coding round as a strict filter. If your code doesn't compile or fails to meet the basic functional requirements by the 90-minute mark, the interview almost always results in a no-hire. Let's look at exactly how to tackle the multi-tier cache problem step-by-step.

How do you design a configurable multi-tier cache system?

When the interviewer hands you the multi-tier cache problem, the requirements usually follow a specific pattern. You need to design a cache system that supports multiple levels like L1, L2, and L3. Each level needs its own capacity and its own distinct eviction policy, such as LRU or LFU. When a read occurs, the system should check L1 first. If that results in a miss, it checks L2, and so on down the chain. Upon finding a hit in a lower level, the data must be promoted up to the higher levels. Conversely, when a level reaches its full capacity, writing new data has to trigger an eviction. That evicted data should then be demoted to the next lower level. Finally, the entire system must remain thread-safe to handle concurrent read and write operations smoothly.

Core Architecture and Entity Modeling

Separation of concerns is the absolute key to acing Flipkart's LLD round. Don't make the mistake of cramming your cache logic, storage logic, and eviction logic into a single massive God class. Instead, break the entire system down into modular components using standard design patterns.

Start by defining a generic 'EvictionPolicy' interface with methods like 'keyAccessed(Key key)' and 'evictKey()'. This setup allows you to implement an 'LRUEvictionPolicy' using a Doubly Linked List and a HashMap. You can also implement an 'LFUEvictionPolicy' using multiple Doubly Linked Lists mapped by frequency, all without touching the core cache logic. Doing this perfectly demonstrates the Strategy Pattern in action.

Next up, define a 'Storage' interface featuring 'add', 'remove', and 'get' methods. A 'HashMapBasedStorage' class will then implement this interface. Keeping your storage completely separate from your eviction logic means you can easily swap out an in-memory map for a file-based storage mechanism later if the interviewer asks for it.

Finally, create a 'CacheLevel' class that composes both the 'Storage' and the 'EvictionPolicy'. Your 'CacheLevel' will also need to hold a reference to the 'nextLevel', which acts as a pointer to the next CacheLevel object. This effectively forms a Chain of Responsibility pattern to handle cache misses.

Implementing the Eviction and Tier-Propagation Logic

Managing the movement of data between tiers is easily the hardest part of this problem. Let's trace a standard read and write operation so we can understand the underlying orchestration.

• Read Operation (GET): Start your search at L1. If you find the data, return it and notify the L1 eviction policy that the key was accessed. If you don't find it, recursively call GET on L2. If L2 returns the value, you now have to promote it to L1, which means writing the value directly to L1.
• Write Operation (PUT): When you promote data to L1 or simply write new data, check if L1 is full. If it is, call 'evictKey()' on L1's eviction policy. You'll remove that evicted key from L1's storage and immediately call PUT on L2 with the evicted key-value pair.
• Cascading Evictions: If L2 happens to be full when receiving the demoted data from L1, L2 must evict its own data down to L3, and so on. You must handle this cascading effect either recursively or iteratively within the 'CacheLevel' class.

When you explain this architecture to the Flipkart interviewer, make sure to emphasize the time complexity. For an LRU policy, accessing, adding, and evicting a key should all be O(1) operations. The total time for a cache miss that cascades down to level N will be O(N). This remains optimal because N—the number of tiers—is typically very small.

Ensuring Thread Safety and Concurrency Control Across Tiers

Flipkart deals with massive scale on a daily basis. Because of this, your interviewer will inevitably ask what happens if multiple threads try to read and write to your cache simultaneously. If your code relies on standard HashMaps and unsynchronized linked lists, it will completely fail under concurrent load.

The naive approach involves slapping a 'synchronized' block on the entire 'get' and 'put' methods of the cache. While this technically ensures thread safety, it absolutely destroys performance by forcing all threads to wait in a single-file line. You have to discuss finer-grained locking.

A much better approach is to use Java's 'ReadWriteLock' at the 'CacheLevel'. Multiple threads can acquire the read lock simultaneously to fetch data. However, if a thread needs to write—or if a read triggers an eviction or promotion that modifies the internal state of the eviction policy—it must acquire the write lock. You can score even more points by discussing lock striping or using a 'ConcurrentHashMap' for the storage layer. Just remember that you still need to synchronize the storage updates with the eviction policy updates in the doubly linked list. This prevents nasty race conditions where a key exists in storage but goes missing from the eviction queue.

How to Structure and Demo Your Code Under Time Pressure

When you have 20 minutes left on the clock, you absolutely must have a running program. Flipkart interviewers don't want to sit there watching a main method that requires manual user input via Scanner. They expect to see a clean driver class that programmatically demonstrates all the requirements.

• Create a 'MultiTierCache' facade class to act as your entry point. This class should abstract away the linked list of CacheLevels.
• Instantiate a 3-tier cache in your Main class. Configure L1 with a capacity of 2 and LRU, and set L2 with a capacity of 3 and LFU.
• Write a sequence of 'put' operations that deliberately overflows L1. This clearly demonstrates the cascading eviction down to L2.
• Write a 'get' operation that intentionally forces a cache miss in L1, hits in L2, and triggers a promotion back to L1.
• Print the state of the cache showing the keys present in each tier after every major operation. Overriding the 'toString' method in your CacheLevel class makes this visual output crystal clear for the interviewer.

Common Pitfalls to Avoid in Flipkart's LLD Evaluation

A surprising number of strong candidates fail the machine coding round. They don't fail because they lack logic, but because they mismanage the highly specific constraints of the format. You need to avoid a few common traps.

First, watch out for over-engineering. Don't waste 45 minutes building a complex dependency injection framework or custom exception hierarchies. Stick to simple constructors and standard RuntimeExceptions. Second, avoid handing in code that fails to compile. A 90% complete solution that compiles and runs is vastly superior to a 100% complete solution throwing a NullPointerException on startup. Always test your code incrementally.

Finally, don't tightly couple your data types. If your cache only accepts Strings, you'll lose major points for a lack of extensibility. Use Generics like CacheLevel<Key, Value> so the system can cache literally any object type. It's a simple change, but it heavily signals your maturity as a Java or C++ developer.

Wrapping Up Your Flipkart Prep

Cracking the Flipkart SDE-2 machine coding round requires a delicate balance of speed, clean object-oriented design, and a solid understanding of core data structures. The multi-tier cache problem serves as the perfect playground to demonstrate all three of these skills. By separating your storage from your eviction policies, handling promotions and demotions cleanly, and addressing concurrency head-on, you show the interviewer that you're truly ready to build systems at Flipkart scale.

Practice building this exact system from scratch using a strict 90-minute timer. Once you master the basic boilerplate and the underlying design patterns, you'll find that almost every machine coding problem follows the exact same rhythm, whether they ask for a parking lot, a message queue, or a cache.