Loading...
A practical coaching guide to crack the Groww Software Development Engineer-I interview — covering every round, what interviewers look for, and how to prepare.
Let's be real — Groww is one of the most exciting fintech companies to work at in India right now. They're scaling fast, the engineering culture is strong, and the SDE-I role is genuinely competitive. That also means they're not going to hand you an offer just because you can reverse a linked list.
Here's the thing most candidates miss: Groww's interviews are designed to test whether you can think like an engineer, not just memorize solutions. The interviewers — many of whom are senior engineers who've shipped real financial products — are checking whether you're someone they'd trust to write code that handles people's money.
Let's walk through the full process so you know exactly what's coming.
Groww's SDE-I process typically spans 3–5 rounds across 1–2 weeks. Here's the typical structure:
| Round | Format | Duration | Focus |
|---|---|---|---|
| Round 1 | Online Assessment (OA) | 60–90 mins | DSA, Problem Solving |
| Round 2 | Technical Interview I | 45–60 mins | DSA + CS Fundamentals |
| Round 3 | Technical Interview II | 45–60 mins | System Design (LLD) + DSA |
| Round 4 | Hiring Manager / Bar Raiser | 45–60 mins | Culture, Depth, Problem Solving |
| Round 5 (sometimes) | HR Round | 20–30 mins | Behavioral, Offer Discussion |
Not every candidate goes through all five. Sometimes rounds 2 and 3 are combined. But don't assume you'll get fewer — prepare for the full gauntlet.
The OA is purely a filter. The interviewer (well, the algorithm) is checking: can this person solve medium-difficulty DSA problems under time pressure? Think LeetCode Medium — sometimes with one Hard thrown in.
Typical topics covered:
Most candidates get tripped up by not reading the constraints carefully. If n can be up to 10^6, your O(n²) brute force is going to TLE every time. Read the constraints before you write a single line.
A common trap is jumping into code without thinking through the approach. Even in an OA, spend the first 5 minutes thinking — not typing.
Here's a classic that trips up candidates — finding the longest subarray with sum equal to k:
def longest_subarray_with_sum_k(arr, k):
prefix_sum = 0
max_len = 0
sum_index_map = {}
for i, num in enumerate(arr):
prefix_sum += num
if prefix_sum == k:
max_len = i + 1
if (prefix_sum - k) in sum_index_map:
max_len = max(max_len, i - sum_index_map[prefix_sum - k])
# Only store first occurrence
if prefix_sum not in sum_index_map:
sum_index_map[prefix_sum] = i
The interviewer is checking: Did you recognize the prefix sum pattern? Did you handle the "first occurrence" edge case? Did you get O(n) or did you go O(n²)?
This is a live coding round with a Groww engineer. They want to see clean thinking, not a polished solution. The signal they're looking for is your problem-solving process — how you break down a problem, communicate your reasoning, and handle feedback.
Expect 1–2 DSA problems. After coding, they'll often pivot to CS fundamentals: DBMS, OS, OOPs, or Networking basics.
Here's the phrasing that lands well with Groww interviewers:
That last line is golden. It signals collaboration, not performance.
Because Groww is a fintech company, they care about data consistency and reliability. Expect questions like:
These aren't trick questions. They're checking whether you understand the why behind the tools you'll use.
This is where most SDE-I candidates stumble. Groww takes LLD seriously. The interviewer is checking if you can design a clean, extensible system using OOP principles — not just write functions that work.
Typical LLD problems for SDE-I level:
The classic mistake is jumping to code immediately. The interviewer wants to see your class diagram first. Think entities, relationships, and responsibilities before writing a single method.
Here's a quick example. For a Parking Lot system, before coding anything, you'd say:
"Let me identify the key entities: ParkingLot, Floor, Slot, Vehicle, Ticket. A ParkingLot has multiple Floors. Each Floor has multiple Slots. A Slot can hold one Vehicle at a time. When a Vehicle enters, we generate a Ticket..."
Then you'd sketch the classes:
// Clean OOP structure — this is what Groww interviewers love to see
public class ParkingSlot {
private String slotId;
private VehicleType type;
private boolean isOccupied;
private Vehicle currentVehicle;
public boolean assignVehicle(Vehicle vehicle) {
if (!isOccupied && this.type == vehicle.getType()) {
this.currentVehicle = vehicle;
this.isOccupied = true;
return true;
}
return false;
Notice: Singleton pattern, clean separation of concerns, extensible design. That's what earns points here.
Here's the insider knowledge: this round isn't just behavioral. Yes, there'll be questions like "Tell me about a time you disagreed with your team" or "What's your approach when you're stuck on a problem?" But Groww's hiring managers often throw in a surprise DSA or design question too.
They're checking depth. Anyone can memorize STAR stories. The hiring manager wants to know: do you have genuine curiosity? Do you take ownership? Are you someone who will raise the bar for the team?
Use the STAR-L framework (Situation, Task, Action, Result, Learning). The "L" is what separates good answers from great ones at Groww.
Example behavioral questions Groww loves:
For each story, practice saying: "...and here's what I'd do differently if I faced that situation again." That shows maturity.
arr, temp, x in a live interview signals lazy thinking. Use descriptive names.Here's an example of how a strong candidate opens a live coding problem at Groww:
Interviewer: "Given an array of integers, find two numbers that add up to a target sum."
Strong candidate response:
"Great, before I dive in — a few clarifications. Can the array have duplicates? Can elements be negative? Is there guaranteed to be exactly one solution, or should I handle the case where none exists? And should I return the values or the indices?"
[After clarifications]
"Okay, my initial brute force would be two nested loops — O(n²) time, O(1) space. But I think we can do better. If I use a hash map to store seen values, I can get this down to O(n) time and O(n) space. Let me walk through the logic before I code it..."
That's the energy. Methodical, communicative, thinking about trade-offs.
You've got this. Now close the blog post and go solve 3 LeetCode problems. 🚀