Zerodha Software Engineer Interview: The Full Process, Decoded

- Zerodha's machine coding round is the differentiator: build a working feature from a product requirement, not a LeetCode problem
- The stack is Go and Python — knowing basic Go gives you a visible edge over other candidates
- Open-source contributions are read carefully; a strong GitHub profile can skip you past the online assessment
- Over-engineering is penalized on a 30-person team; clean, maintainable code beats clever code every time
- Domain knowledge matters — use Kite, understand market vs limit orders, and read the Zerodha Tech Blog before your interview
- Six weeks is enough for most candidates; budget ten to twelve if returning after a long gap
The Zerodha software engineer interview is not a FAANG process with an Indian address. The rounds, the culture, and what actually gets you hired are different in ways that catch candidates off-guard. Know that before you open LeetCode and start grinding hard DPs.
This Company Is Not What You Think
Zerodha is India's largest retail stockbroker, running roughly 15 to 20 percent of daily trading volume with a tech team of about 30 engineers. That ratio is extraordinary. Most companies with that market share have engineering orgs in the hundreds. Zerodha does it with a team that could fit into a conference room. With seats to spare.
Small teams mean nowhere to hide weak engineers, and the interview is calibrated accordingly.
The stack is almost entirely Go for performance-critical services and Python for backoffice work. Zerodha co-founded FOSS United and commits $1 million annually to open-source projects globally. Open-source contributions are not a footnote on your resume here. They are a signal that gets read carefully, probably more carefully than your college GPA.
The CTO Kailash Nadh talks openly about hiring people who build things for fun, not people who prepared by grinding 400 LeetCode problems. If you have read one of his talks, the hiring philosophy is consistent: find engineers who are genuinely curious, give them autonomy, let them build. That preference shapes the entire process, from the machine coding round to the culture conversation at the end.
So if you have spent three months memorizing red-black tree rotations: good for you, honestly. But that is not what is getting you this job.
How the Process Runs
Two to four rounds, depending on role and level. Timeline from application to offer is usually two to six weeks.
| Round | Format | Focus |
|---|---|---|
| Online assessment | HackerRank, 60-90 min | DSA, algorithms, debugging |
| Machine coding | 90-120 min live or take-home | Build a working feature end-to-end |
| Technical interview | 45-60 min live | System design, code review, domain knowledge |
| HR and culture | 30-45 min | Motivation, projects, collaboration |
Some candidates skip the online assessment entirely with strong open-source work or a referral. Senior roles sometimes add an extra technical round.
Round 1: Can You Code Under Pressure?
The first filter is a timed coding test on HackerRank. Two to four problems, LeetCode medium difficulty with occasional hard problems mixed in.
The test checks whether you can produce clean, working code under time pressure, not whether you memorized an obscure algorithm. Expect arrays, strings, linked lists, and trees. Debugging challenges appear sometimes: broken code, find and fix the issue.
Patterns that come up repeatedly:
- Subarray and substring problems (sliding window, prefix sums)
- Linked list manipulation: reverse, detect cycles, merge two sorted lists
- Tree traversals and BST operations: LCA, validate a BST, level order traversal
- Sorting and binary search variants
- Basic graph problems: BFS, DFS, connected components
Go is preferred but not required at this stage. If you know it, write in it. The team reads Go every day.

The spirit of every "what LeetCode did they ask" reply. Zerodha wants to know if you can build things, not recite trivia.
Round 2: The Machine Coding Round
This is the round that separates Zerodha from a standard LeetCode loop. You are given a product requirement in plain English and you have to design and build it.
A classic prompt: implement a simple order management system. Handle market orders, limit orders, partial fills, and order cancellation. Or: build a rate limiter for burst traffic from thousands of concurrent WebSocket connections.
Think of it as the difference between being asked to solve a crossword puzzle and being handed raw lumber and asked to build a chair. Both involve words and wood, respectively. One will actually sit in.
The problems are deliberately domain-adjacent. You do not need to know the FIX protocol, but you should understand what a buy order means. If you have never opened Zerodha's Kite app, do that before your interview.
What the panel is watching:
- Do you ask clarifying questions before writing a single line?
- Can you model the problem with the right data structures?
- Is your code readable and are your abstractions clean?
- Can you reason about edge cases: what happens if an order is partially filled twice?
- How do you handle concurrency if throughput comes up?
Over-engineering is penalized. A 30-person team maintains everything they ship. Complexity without a concrete requirement is a red flag, not a green one. If you find yourself reaching for a segment tree when a hash map will do, pause. Nobody on that team wants to wake up at 2am to debug your custom load-balancing skip list.
Round 3: Systems, Past Work, and Trade-offs
The technical round covers two things: a discussion of your past work and a system design problem.
The past-work discussion is not a formality. You will be asked about a project you built, the decisions you made, the trade-offs you navigated. Be ready to defend your schema choices, your API design, your concurrency model. Pick a project you actually drove. Picking a project where you "contributed to a feature" and then getting interrogated about why the team chose Postgres over MySQL is a bad time.
The system design problem will be fintech-flavored. Common prompts:
- Design the real-time tick data pipeline that powers Zerodha's charting platform
- Design a system that processes millions of trade events per day
- Design Zerodha's alerting system for price triggers
Show comfort with distributed systems: message queues, event streaming, horizontal scaling, and consistency trade-offs. Kafka and WebSocket architecture come up because that is Zerodha's actual infrastructure. You do not need to have built these systems. You need to reason about them.
System design here is practical, not theoretical. The panel wants to know what you would actually build, not what you read on a system design prep website at midnight.
Round 4: Do You Actually Build Things?
This round matters more at Zerodha than at most companies, and it is the one that trips up the most candidates.
The interviewer wants to know whether you build things for fun. They will ask about hobby projects, open-source contributions, what you are learning right now. They will probe your motivation for joining a fintech company and ask how you handle ambiguity, since engineers here define their own requirements.
The answer they are not looking for is "I want to work at Zerodha because it is well-known." They want someone who finds high-throughput systems and small teams genuinely exciting, who has read the tech blog, who has opinions about the engineering problems in financial systems.
If your hobby is grinding LeetCode, that is honestly not the answer they want. Solving algorithmic puzzles and building systems are different skills. Zerodha wants the builder.
The good news is they are not asking you to have shipped a billion-dollar product. A working Go HTTP router you built over a weekend counts. A parser for an obscure data format you reverse-engineered counts. An open-source library with twelve stars and two contributors counts. The signal they are looking for is whether engineering is what you do, not just what you claim to be.
Honesty works better here than polish. Say you do not know something when you do not. The team is small enough that they can tell when someone is performing versus thinking, and they have been burned enough times by polished candidates who couldn't write a goroutine without Stack Overflow.
Know These Patterns, Skip the Rest
The range is narrower than FAANG prep would suggest. These are the patterns worth your time:
- Sliding window and prefix sums for subarray and substring problems
- Two pointers for sorted array and linked list problems
- Trees and BSTs: traversals, construction, validation, LCA
- Graphs: BFS and DFS for connected components and shortest path
- Heaps and priority queues for streaming problems (top K, running median)
- Hash maps for frequency counting and lookup acceleration
Segment trees, Fenwick trees, and advanced DP are probably not on the agenda for most roles. Data engineering or algorithmic trading roles raise the bar.
Practice explaining your reasoning out loud while you code. Zerodha's machine coding round is conversational, and silence is not neutral. SpaceComplexity runs voice-based mock interviews with rubric-based feedback across exactly these dimensions, which matters a lot when the interview is a live conversation and not a judge that accepts solutions.
The Mistake Most Candidates Make
They prepare for a FAANG interview.
Three months of LeetCode grinding, mastering hard-level DP, rehearsing STAR answers. Then they walk into the machine coding round, get a product requirement they have never seen, and produce a beautifully optimized O(n log n) solution to a subproblem while ignoring the architecture entirely.
Zerodha cares more about whether you can build a working, maintainable system than whether you can invert a binary tree in four lines. The machine coding round is designed to catch exactly the candidates who are good at interview prep but not at engineering.

The average tech job interview. Zerodha's machine coding round is the deliberate opposite of this.
The second mistake is not knowing the product. Use Kite. Understand the difference between CNC and MIS orders. Know what a watchlist is and how real-time quotes work. This context shapes how you approach the machine coding problem and signals that you are genuinely interested in what Zerodha does. Showing up without this is the equivalent of interviewing at Stripe without knowing what a payment intent is.
Six Weeks Is Enough
Weeks 1 to 2: DSA fundamentals. Cover the patterns above. Work LeetCode mediums on arrays, linked lists, trees, and graphs. Time yourself. Aim for a working solution within 25 minutes on a medium.
Weeks 3 to 4: Machine coding. Build open-ended backend systems. A parking lot. A basic order book with match logic. A rate limiter. Focus on clean interfaces and correct concurrency. If you do not know Go, start learning it now. You do not need fluency, but reading and writing basic Go will help you significantly in both the assessment and the machine coding round.
Week 5: Systems and domain knowledge. Study Kafka architecture, WebSocket handling, and event sourcing. Read two or three posts on the Zerodha Tech Blog. Use Kite for a week. Yes, actually use it, not just install it.
Week 6: Mock interviews. Run timed full-loop simulations. Practice explaining design decisions aloud, including the dead ends. Narrating your thinking is a skill, and it degrades badly under pressure if you have not practiced it.
Switching from a non-engineering role or returning after a long gap? Budget ten to twelve weeks.
Further Prep
- Zomato Software Engineer Interview
- Swiggy Software Engineer Interview
- DSA for Backend Engineers
- Startup Coding Interviews
Further Reading
- Zerodha Tech Blog: the engineering team's own writing on systems, Go, and open source
- Zerodha FOSS Stack: the full open-source technology stack
- Zerodha Careers: current openings and how Zerodha describes what it wants
- Zerodha Recruitment Process, GeeksforGeeks: candidate-reported interview experiences
- Software at Scale 37: Building Zerodha with Kailash Nadh: the CTO on engineering philosophy, team structure, and how the tech organization works