Groww SDE-2 Interview Experience | 1.5 YOE | September 2026
Summary
I interviewed for an SDE-2 position at Groww, completed a machine‑coding round and a system‑design round, but was rejected shortly after the interview.
Full Experience
Background: 1.5 YOE, 2024 batch Role: SDE-2
Sharing my Groww SDE-2 interview experience.
Round 1 — Machine Coding
Duration: 1 hour
The interviewer joined around 10 minutes late.
Problem
// Problem: Brokerage Calculator
// Build a brokerage calculator system that calculates charges for stock trades based on different broker plans and trade types. (extensions: marketing campaigns - discount trades on particular trade days etc.)
// Core Requirements
// 1. Support Trade Types:
// Equity Delivery: Buy/sell stocks for delivery
// Equity Intraday: Buy/sell stocks on same day
// Futures & Options (F&O): Derivatives trading
// 2. Support Broker Plans:
// Regular Plan:
// Equity Delivery: 0.5% per trade
// Equity Intraday: 0.03% per trade
// F&O: 0.05% per trade
// Pro Plan:
// Equity Delivery: ₹20 per trade
// Equity Intraday: ₹10 per trade
// F&O: ₹15 per trade
// Ultra Plan:
// All trades: ₹10 flat per trade
// Additional Charges (apply to all plans):
// STT (Securities Transaction Tax): 0.1% on sell side for delivery, 0.025% on sell side for intraday
// GST: 18% on brokerage amount
// Transaction Charges: ₹10 flat per trade
// Functionality:
// Calculate all the charges for each trade
// Generate detailed breakdown (brokerage, STT, GST, transaction charges, total)
// Validate inputs (negative amounts, invalid trade types)
// Sample Input:
// List [ Trade Id | Segment | Trade Type | Buy/sell | Amount | Plan ]
// e.g.
// [
// T1 | EQ | Delivery | Sell | ₹100,000 | Regular
// T2 | FO | Intraday | Buy | ₹200,000 | Ultra
// ]
// Expected Output:
// List [ Trade Id | Base Brokerage | STT | Transaction Charges | GST | Total Charges]
// e.g.
// [
// T1 | ₹500 | ₹100 | ₹10 | ₹90 | ₹700
// ]
// Basically print for Tradetype=Sell
// .5/100*100,000=500
// .1/100*100,000=100
My Solution
Click to expand C++ solution
#include<bits/stdc++.h>
using namespace std;
enum TradeType{
EQUITY_DELIVERY,
EQUITY_INTRADAY,
FUTURE_OPTIONS
};
enum TradeAction{
BUY,
SELL
};
enum Plan{
REGULAR,
PRO,
ULTRA
};
class Trade{
public:
string tradeID;
double amount;
TradeAction action;
TradeType type;
Plan plan;
Trade(string tradeID, double amount, TradeAction action, TradeType type, Plan plan):
tradeID(tradeID),
amount(amount),
action(action),
type(type),
plan(plan){}
};
class BrokerPlan{
public:
Plan plan;
virtual double getBaseBrokerage(Trade* trade)=0;
};
class RegularPlan:public BrokerPlan{
public:
map<TradeType,double>mp;
RegularPlan(map<TradeType,double>mp):mp(mp){
plan=REGULAR;
}
double getBaseBrokerage(Trade* trade)override{
return mp[trade->type]*trade->amount/100;
}
};
class ProPlan:public BrokerPlan{
public:
map<TradeType,double>mp;
ProPlan(map<TradeType,double>mp):mp(mp){
plan=PRO;
}
double getBaseBrokerage(Trade* trade)override{
return mp[trade->type];
}
};
class UltraPlan:public BrokerPlan{
public:
double brokerage;
UltraPlan(double brokerage):brokerage(brokerage){
plan=ULTRA;
}
double getBaseBrokerage(Trade* trade)override{
return brokerage;
}
};
class BrokerageCalc{
public:
double GSTPercent,transactionCharge;
map<TradeType,double>sttPercentPerTypeEquity;
BrokerPlan* brokerPlan;
BrokerageCalc(
map<TradeType,double>sttPercentPerTypeEquity,
double GSTPercent,
double transactionCharge,
BrokerPlan* brokerPlan
):
sttPercentPerTypeEquity(sttPercentPerTypeEquity),
GSTPercent(GSTPercent),
transactionCharge(transactionCharge),
brokerPlan(brokerPlan){}
double calculateSTT(Trade* trade){
if(trade->type==FUTURE_OPTIONS){
cout<<"No STT for F&O\n";
return 0;
}
double charge=trade->amount*
sttPercentPerTypeEquity[trade->type]/100;
cout<<"STT charge: "<<charge<<"\n";
return charge;
}
double calculateGST(double brokerage){
double charge=brokerage*GSTPercent/100;
cout<<"GST charge: "<<charge<<"\n";
return charge;
}
double calculateBaseBrokerage(Trade* trade){
double charge=brokerPlan->getBaseBrokerage(trade);
cout<<"Base brokerage charge: "<<charge<<"\n";
return charge;
}
bool validate(Trade* trade){
return trade->amount>0 &&
(trade->type==EQUITY_DELIVERY ||
trade->type==EQUITY_INTRADAY ||
trade->type==FUTURE_OPTIONS);
}
double calcCharges(Trade* trade){
if(!validate(trade)){
cout<<"Invalid trade!!\n";
return 0;
}
if(trade->action==BUY){
cout<<"No charges for BUY trade\n";
return 0;
}
cout<<"tradeID: "<<trade->tradeID<<"\n";
cout<<"Transaction charge: "<<transactionCharge<<"\n";
double b=calculateBaseBrokerage(trade);
double totalCharges=
b+
calculateGST(b)+
calculateSTT(trade)+
transactionCharge;
cout<<"Total charges="<<totalCharges<<"\n";
return totalCharges;
}
};
int main(){
map<TradeType,double>RegularMp={
{EQUITY_DELIVERY,0.5},
{EQUITY_INTRADAY,0.03},
{FUTURE_OPTIONS,0.05}
};
BrokerPlan* plan=new RegularPlan(RegularMp);
double GSTPercent,transactionCharge;
GSTPercent=18.0;
transactionCharge=10;
map<TradeType,double>sttPercentPerTypeEquity={
{EQUITY_DELIVERY,0.1},
{EQUITY_INTRADAY,0.025}
};
BrokerageCalc* calc=new BrokerageCalc(
sttPercentPerTypeEquity,
GSTPercent,
transactionCharge,
plan
);
Trade* trade1=new Trade(
"T1",
100000,
SELL,
EQUITY_DELIVERY,
REGULAR
);
calc->calcCharges(trade1);
delete trade1;
delete plan;
delete calc;
return 0;
}
I had some small bugs while implementing the solution.
When the interviewer said we were up on time(he gave extra 10mins compensating for being late), my code was still not running. I asked him to wait another 2–3 minutes, debugged it, and eventually got the code running.
I took around 5–10 minutes extra. Time management was fairly something that I was being judged on.
Round 2 — HLD
Duration: 1 hour
The interviewer again joined around 10 minutes late.
The question was:
Let's design a GTT order service. We already have an order service built.
Exchanges <> Order service
Order service places an order on exchange.
Order service also listens to order updates from the exchange.
Buy(10, Reliance, MKT), Sell(10, Reliance, Limit, 100)
Buy(10, Reliance, Limit, 100), Sell(10, Reliance, MKT)
Order at exchange: the validity of order is day.
At the end of the day all orders on the exchange are dropped.
GTT order service => Good Till Trade
GTT_Buy(10, Reliance, MKT) =>
I did the pre calc before designing
10M DAU
10% does order booking
Lets say around 10order per user
Lets say 10%GTT orders
1M GTT orders/day
Here consistency matters, GTT orders should not be dropped
HLD Diagram
My HLD diagram for the discussion:
My approach
My basic idea was:
- As soon as we get an order in Order Service, check whether it is a GTT order.
- If it is GTT, add the
orderIdto Redis. - When we receive a trade/update from the exchange, check if it was a GTT order and remove the
orderIdfrom Redis. - Schedule a cron job at the end of the day.
- The cron job iterates over all orders present in Redis and places the order on behalf of the user by sending it to Order Service.
I explained this flow and was asked several questions around it.
Kafka
I had placed Kafka after the Gateway and before Order Service.
My reasoning was that there could be a large number of concurrent users placing orders, so Kafka could somewhat absorb the pressure and Order Service could consume at its own rate.
The interviewer then asked:
A user wants to see the order history. How would we do that?
I initially gave a vague answer that we could have an Order History Service and query the Order Service.
Then I was asked about the fact that we were updating the Order DB only after the trade was done.
So I added a Validator Service after Kafka:
Gateway
|
Kafka
|
Validator
|
Order DB
The validator would validate the order and accordingly update the Order DB, so orders with statuses like PENDING / NOT_PLACED would also be present in the DB.
Then came another question:
Given a user placed an order and it is still in Kafka, and the user wants to see their history, how would you handle that?
I initially tried to simulate the flow like an IRCTC Tatkal booking, where there could be some kind of buffer/loader.
The interviewer insisted on a better approach.
At that point I suggested that along with Kafka, we could also store the order in Redis and update Redis after validation.
Then he asked:
What if publishing succeeds but writing to Redis fails, or Redis succeeds but publishing to Kafka fails?
I said we would need to make the operations atomic, potentially using something like the Outbox Pattern.
I also mentioned that this could be inefficient given the volume of orders.
As an alternative, I suggested using Redis Streams instead of Kafka so that we could potentially make the operations atomic using Lua scripts.
However, I wasn't confident that Redis Streams would be the right solution for this volume, and I eventually couldn't take this part further.
Notifications
The interviewer then asked:
If we want to notify users that their GTT will be placed, how would we do that?
I suggested creating a Notification Service which the GTT Service would call for every order.
The Notification Service could then handle push/message/email notifications.
In hindsight, I think I should have discussed decoupling these services asynchronously as well.
Outcome
The interview completed within the scheduled time.
I was somewhat thinking that the interview had gone well and was expecting a possible pass.
However, I received the rejection around 1.5 hours after the interview.
The main thing I took away from the HLD was that the interviewer kept drilling down into consistency, intermediate states, and failure scenarios, rather than stopping at the high-level architecture.
Would love to hear how others would handle the Kafka → Order DB → order history problem, especially the case where an order is still sitting in Kafka but the user wants to see it immediately.
Interview Questions (2)
Brokerage Calculator
Build a brokerage calculator system that calculates charges for stock trades based on different broker plans and trade types. The system must support trade types (Equity Delivery, Equity Intraday, Futures & Options) and broker plans (Regular, Pro, Ultra) with specific percentage or flat fees. Additional charges include STT, GST, and a flat transaction charge. The solution should validate inputs, compute base brokerage, STT, GST, transaction charges, and produce a detailed breakdown for each trade.
Design GTT Order Service
Design a Good‑Till‑Trade (GTT) order service that works with an existing order service and exchanges. The system must handle order placement, order updates from exchanges, and ensure that GTT orders persist across the day (while regular orders are dropped at day‑end). Requirements include handling high concurrency, providing immediate order‑history visibility even when an order is still in the pipeline, ensuring consistency, and supporting notifications when a GTT order is finally placed.