Passing the Groww SDE Machine Coding Interview

Groww's engineering culture puts a massive premium on execution. In the fast-paced fintech space, a single unhandled race condition or a poorly optimized database query doesn't just cause a slow page load—it loses real people real money. If you're chasing a Software Development Engineer (SDE) role there, the hurdle that usually trips candidates up isn't a standard algorithmic brain-teaser. It's the machine coding round.

Interviewers expect you to build a fully functional, extensible, and concurrency-safe system from scratch in just 90 to 120 minutes. We aren't talking about scribbling pseudocode on a whiteboard here. You need to write production-grade code that actually compiles, runs, and handles tricky edge cases gracefully. You are essentially proving that if you were handed a feature ticket on your first day, you could architect the core domain logic without needing constant hand-holding.

The Groww SDE Interview Process

Before diving into the code, you need to understand where the machine coding round fits into the overall hiring pipeline. Groww uses this round as their primary filter. If your code doesn't compile, or if your design is a tangled mess of hardcoded variables, you will not advance to the system design round.

The 120-Minute Game Plan

Time management is the single biggest point of failure in this round. Candidates often spend 45 minutes drawing UML diagrams and then panic when they realize they have to write 500 lines of Java in 45 minutes. Here is a battle-tested timeline to keep you on track:

• Minutes 0-15 (Clarification & Scope): Do not touch your keyboard. Ask clarifying questions. Are we supporting just limit orders, or market orders too? Do we need to handle partial fills? Write down the exact scope and sketch a rough class diagram on paper.
• Minutes 15-30 (Skeleton & Interfaces): Set up your project structure. Create your core entities (User, Order, Trade), enums (OrderStatus, OrderType), and the interfaces for your services. Get the boilerplate out of the way.
• Minutes 30-75 (Core Business Logic): This is where you write the heavy lifting—the order matching engine, the SIP state machine, or the portfolio calculator. Focus on thread safety and correct data structures here.
• Minutes 75-90 (Driver Class & Testing): Write a `main` method that simulates a real-world scenario. Create a few users, place overlapping orders, and print the results to the console. Prove that your code works.
• Minutes 90-120 (Review & Extension): The interviewer will review your code, ask why you chose certain data structures, and throw a new feature request at you to test your architecture's extensibility.

Deep Dive 1: Designing a Concurrency-Safe Stock Brokerage Engine

One of the most common Groww machine coding questions asks you to build an in-memory stock exchange or brokerage engine. The prompt usually goes like this: 'Design an engine that can accept buy and sell orders for different stocks and execute trades when the prices match.' The real challenge here lies in order matching and concurrency.

The Order Matching Algorithm

You have to match incoming buy and sell orders based on price-time priority. If you rely on naive list iteration, you'll hit an O(N) time complexity per order—completely unacceptable for a trading engine. Instead, set up two Priority Queues for each stock ticker: a Max-Heap for Buy orders (highest price gets priority) and a Min-Heap for Sell orders (lowest price gets priority).

Whenever a new order hits the system, you peek at the opposing heap. If a new Buy order for RELIANCE comes in at 2500 INR, you check the Sell heap. If the lowest willing seller is asking for 2490 INR, you have a match. You execute the trade at the seller's price (since their order was resting in the book first), deduct the quantities, and repeat until the new order is either fully filled or the next best sell price is higher than 2500 INR.

• Order Class: Holds the orderId, ticker, quantity, price, timestamp, and OrderType (BUY/SELL). Make the timestamp highly precise (e.g., nanoseconds) to resolve ties in price.
• OrderBook Class: Manages the heaps. You will need one OrderBook instance per stock ticker.
• Matching Engine Service: Contains the core logic for comparing the top of the heaps, generating Trade objects, and handling partial fills (where an order is only partially executed and the remainder stays in the heap).
• Trade History: A simple in-memory list or map so you can query executed trades for a specific user or ticker.

Handling Concurrency Without Bottlenecks

If you put a `synchronized` keyword on your global `placeOrder` method, you have failed the interview. That approach locks the entire exchange, meaning a trade for HDFC blocks a trade for TCS. This is a massive red flag for a company like Groww.

Instead, use a `ConcurrentHashMap<String, OrderBook>` to store your order books by ticker. Inside the `OrderBook` class, use a `ReentrantLock`. When an order comes in for RELIANCE, you fetch the RELIANCE OrderBook and acquire its specific lock. This ensures that trades for different stocks process completely in parallel across different threads, maximizing throughput while maintaining strict thread safety for individual order books.

Deep Dive 2: Designing an Idempotent SIP Scheduler

Designing a Systematic Investment Plan (SIP) scheduler is another frequent prompt. The system needs to deduct funds and execute mutual fund purchases on a specific date every single month. Your main technical hurdles here are idempotency, fault tolerance, and state management.

If the system crashes mid-execution, restarting it absolutely cannot result in charging the user twice. To handle this, you need to build a robust state machine for the SIP execution. A single monthly run for an SIP should track statuses like SCHEDULED, PAYMENT_INITIATED, PAYMENT_SUCCESS, ORDER_PLACED, and COMPLETED.

Mastering Idempotency Keys

Imagine your thread pool picks up SIP ID 4599 for execution. It calls the banking API to debit 5000 INR. The bank deducts the money, but your server experiences a network timeout before receiving the 200 OK response. Your system thinks the payment failed. A naive retry mechanism will charge the user another 5000 INR tomorrow.

You also need a sweeping mechanism. A scheduled cron job should periodically scan your in-memory database for SIP executions stuck in PAYMENT_INITIATED for more than 15 minutes. The sweeper thread will query the payment gateway for the status of that idempotency key and push the state machine forward to PAYMENT_SUCCESS or back to SCHEDULED.

Deep Dive 3: The Mutual Fund Portfolio Tracker

A third variation of the Groww LLD round asks you to build a portfolio tracker. Users can buy and sell units of mutual funds on different days at different Net Asset Values (NAVs). Your job is to calculate their current portfolio value, their total invested amount, and their realized versus unrealized gains.

The trap here is the sell logic. If a user buys 100 units of a fund at 10 INR, and later buys 50 units at 12 INR, they own 150 units. If they decide to sell 120 units, which specific units are sold? Tax laws generally require First-In-First-Out (FIFO) accounting. Your system must accurately reflect this.

• InvestmentLot Class: Instead of just tracking total units, track individual purchases. An InvestmentLot holds the fundId, purchaseDate, quantity, and purchasePrice.
• FIFO Selling Logic: When a sell order for 120 units arrives, iterate through a queue of InvestmentLots. Fully consume the 100 units from the 10 INR lot, then consume 20 units from the 12 INR lot, leaving exactly 30 units in the 12 INR lot.
• Realized Gains Calculation: As you consume units from the lots, calculate the profit. For the first lot, profit is 100 * (SellPrice - 10). For the second lot, profit is 20 * (SellPrice - 12). Add these up to get the total realized gain for the transaction.

Design Patterns That Will Save You

Writing clean code is just as important as writing working code. Groww evaluators look for specific design patterns that prove you know how to build maintainable software. Hardcoding massive if-else blocks will cost you the interview.

Use the Strategy Pattern for algorithms that might change. For example, if you are building the stock broker, create an `OrderMatchingStrategy` interface. Implement a `PriceTimePriorityStrategy`. This shows the interviewer that if Groww wanted to launch a new exchange using a Pro-Rata matching algorithm, you could plug it in without touching the core engine.

Use the Observer Pattern for event handling. When a trade executes, you need to update the buyer's portfolio, update the seller's portfolio, and send an email notification. Instead of tightly coupling these actions inside the matching engine, have the engine emit a `TradeExecutedEvent`. Let the `PortfolioService` and `NotificationService` subscribe to these events and react independently.

The Evaluation Rubric and Live Refactoring

During the final 20 to 30 minutes of the round, the interviewer will review your work against four main pillars: functionality, code quality, concurrency handling, and extensibility. Once they verify the code works, they will throw a curveball requirement your way to see how your architecture holds up.

For example, if you built the stock broker, they might say: 'Great, now implement Stop-Loss orders.' A Stop-Loss order sits dormant until the stock price drops to a certain trigger price, at which point it converts into a regular market order.

If you built a modular system, you won't panic. You will create a new `StopLossManager` class that observes trades. You will store pending stop-loss orders in a separate data structure. Whenever a trade executes, the `StopLossManager` checks if the new market price triggers any dormant orders. If it does, it simply formats them as standard market orders and pushes them into your existing `OrderBook` queues. You implement the entire feature without modifying a single line of your core matching logic, perfectly demonstrating the Open-Closed Principle.

Mastering these design patterns takes serious practice, especially when you have a ticking clock in the background. Build a mental library of reusable LLD components—thread-safe singletons, strategy interfaces, event buses, and state machines—long before the interview. The candidates who pass are the ones who don't have to invent these patterns on the fly; they just have to assemble them.