Zerodha Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Zerodha. It is a profitable, bootstrapped, product-and-engineering-led company, not a VC-fueled growth machine. That single fact drives the whole culture.

• Lean teams of generalists who own things end to end, not big specialized orgs.
• The scale-to-headcount ratio is the tell: 1.6 crore-plus clients and a very large share of India's retail equity volume, run by an engineering org in the low hundreds, not thousands.
• They weight solid engineering judgment and maintainable software far above how many hard graph problems you can recite.
• When two candidates are close, the one who writes readable code wins.

2Getting the call (the part most guides skip)#

Zerodha does not run the usual high-volume campus-plus-recruiter funnel. The path in looks different, so play it differently.

• Where hiring happens. The careers page (careers.zerodha.com and the Zerodha/Rainmatter tech hiring posts) and, heavily, their open-source footprint.
• The strongest signal: public work. A GitHub with real projects, contributions to Go/Python/JS tooling, or anything in the markets/fintech space.
• Why it matters. They ship a surprising amount of their own tooling in the open under the zerodha and knadh (their CTO) GitHub orgs, so showing up with real code is the native language here.

Referrals help, but are not the dominant path the way they are at larger firms. What lands better is an application that proves you looked at their actual stack.

• Their stack: Go, Python, PostgreSQL, Redis, Kafka, plus their own open-source libraries.
• stuffbin embeds static assets into a single Go binary.
• goyesql keeps SQL out of your Go code and in named .sql files.
• listmonk and dungbeetle are their open mailer and async job-server.
• A cover note that shows you understood why they built one of these this way separates you from the stack of generic applications.

Resume rules.

• One page. Lead with impact, not responsibilities.
• Every bullet: action plus what you built plus a measurable result.
• Weak: "Worked on backend APIs for a trading feature."
• Strong: "Built an order-status polling service in Go that cut average API latency from 420ms to 95ms and handled 12k requests/sec during market open."
• Show ownership of a full slice (design, build, ship, monitor). One bullet should prove you watched your own code run in production and reacted: a dashboard you built, an alert you tuned, a regression you caught.

ATS / keyword hygiene.

• Mirror the posting. If it says Go, PostgreSQL, Redis, REST, concurrency, and Linux, those exact words should appear naturally in your bullets.
• They value deep knowledge of one backend language over shallow exposure to five.
• Listing Go, Rust, Java, Node, and Python all as "proficient" reads as a red flag here, not a strength.
• Pick your real primary language and make the depth obvious.

How people actually get shortlisted. A focused application plus visible proof of craft.

• Written a blog post explaining how you built something? Link it.
• Their own team blogs in a plain, technical, no-hype style, and they respect people who write that way.
• A post that says "here is the bug, here is why it happened, here is the fix, here is the trade-off I accepted" tells them more than any list of skills.

3The loop at a glance#

The exact names and count vary by team and level. The shape is consistent though: fewer, deeper rounds than a big-tech loop, quality of thinking over volume of puzzles.

• A common early-SDE shape: take-home, then one live walkthrough plus coding round, then a fundamentals round, then the hiring manager.
• No 6-round gauntlet. The depth hides inside each round instead.
• One interviewer will keep asking "and why?" until you hit bedrock. A shallow answer costs you more here than a wrong answer would at a puzzle-heavy company.

4The coding / technical rounds, patterns, not problems#

Zerodha leans toward practical coding over competitive-programming puzzles. You will more often build something small and correct than solve an obscure DP problem. You still need solid DSA fundamentals for the shorter technical round.

The patterns that actually recur.

• Hash maps and frequency counting. Dedup, grouping, counting, two-sum-style lookups. The everyday tool. Expect a follow-up on what happens on collision and what a resize really costs.
• Two pointers and sliding window. Substring/subarray problems, rate windows, "max orders in any 1-second window."
• Stacks and queues. Parsing, matching, order-book-ish simulations, BFS.
• Sorting plus binary search. Including "search on the answer" and interval problems (merge intervals, meeting rooms). They may hand you a sorted stream and ask you not to sort it again.
• Trees and recursion. Traversals, path sums, occasionally a lightweight graph (BFS/DFS, topological order).
• Concurrency basics. Because they build in Go, expect goroutines/channels, mutexes vs channels, or "process these tasks in parallel safely." A favorite: fan out N jobs to a worker pool, bound the parallelism, collect results, do not leak a goroutine. If you reach for a channel where a mutex is simpler, be ready to defend it.

The real bar. Easy-to-Medium LeetCode, graded on clean, correct, readable code and clear reasoning, not clever one-liners. A correct, boring solution you can explain line by line beats a slick solution you half understand.

How to win the round.

1. Clarify first. Restate the problem, confirm inputs/outputs, ask about constraints and edge cases (empty input, duplicates, huge N, concurrency). Thirty seconds here prevents solving the wrong problem.
2. State your approach out loud before coding. "I'll use a hash map keyed by order ID so lookups are O(1); the trade-off is extra memory." They grade your thinking, not just the final answer.
3. Write code you'd be comfortable committing. Meaningful names, small functions, no dead code, errors returned not swallowed. This company reads a lot of code, so write it like someone will.
4. Talk complexity. Give time and space, and say whether it can be improved. If it is already optimal, say so and say why. Do not fish for a better answer that is not there.
5. Test it yourself. Walk through one normal case and one edge case before saying "done." Catching your own bug out loud is one of the strongest signals in this loop.

Practice by building, not grinding.

• A small LRU cache.
• A rate limiter.
• A simple in-memory key-value store with TTL.
• A mini order-matching simulator (doubles as proof you took an interest in the domain).

5Machine-coding / low-level design (the round that decides it)#

For product/startup engineering, the machine-coding / LLD round is often the most important. You get a loosely specified problem and 60 to 90 minutes to produce running, tested, extensible code, not a diagram. This is where the offer is won or lost, so treat it as the main event.

A framework that works.

1. Clarify scope (5 min). Nail down must-haves vs nice-to-haves. Agree out loud on what you will not build: "I'll build place and cancel and status, I'll skip persistence and auth unless there's time." That sentence alone earns trust.
2. Model the domain (10 min). Identify the core entities and relationships. Sketch the classes/structs and the one or two key interfaces. Keep it minimal. Resist adding a layer you have no concrete use for yet.
3. Build the happy path first (25-30 min). Get an end-to-end working slice before adding features. Working-and-simple beats clever-and-broken, every time. A program that runs and does one thing at the 30-minute mark buys you calm for the rest.
4. Handle edge cases and invalid input (10 min). Null/empty, duplicates, concurrency, boundary values. In a money problem, name the ones that matter: double-submit, cancel-after-fill, negative quantity.
5. Make it extensible (remaining time). Use interfaces/strategy so a new rule or type can be added without rewriting. Add a few tests or a small main() that demonstrates it runs. If you only have time for one test, make it the one that proves the tricky edge case is handled.

Classic prompts in this style.

• Design an order management system: place, modify, cancel; track status; validate.
• Design a rate limiter (token bucket / sliding window) as a reusable component.
• Design an in-memory key-value store with TTL and eviction.
• Design a split-the-bill / wallet ledger with balances and transaction history.
• Design a parking lot / elevator / library: the canonical OOP warm-ups, where they watch your class design and extensibility.

What they grade.

• Does it compile and run?
• Are responsibilities cleanly separated (single responsibility, clear interfaces)?
• Did you handle errors?
• Is it easy to extend?
• Did you manage your time to a working deliverable?

For senior candidates, system design. Expect to design a real service relevant to a brokerage: a notification/alerts pipeline, an order-ingestion gateway, a market-data fan-out, or a reporting/ledger system. Use a clear flow.

• Requirements. Functional plus non-functional: throughput at the 9:15 AM market open, latency, consistency, durability. Money systems prize correctness and auditability over raw speed.
• High-level components. API, queue/stream like Kafka, workers, PostgreSQL, Redis cache.
• Data model and the hot path.
• Scale and failure. What happens at 10x load, on a crash, on a duplicate message. Idempotency matters, and you should say the word before they ask.
• Trade-offs, stated explicitly. Favoring a simple, debuggable design over a trendy distributed one is a plus here. If you propose Kafka, be ready to answer "why not just Postgres and a cron" and mean it.

A simple end-to-end order flow you can sketch and defend:

6Behavioral & culture fit#

Zerodha's culture is unusually distinct for an Indian company: bootstrapped, profitable, long-term, anti-hype, customer-first. They spend almost nothing on advertising and win through product and trust, growing to tens of millions of clients largely on word of mouth. The behavioral round screens for whether you'll thrive on a small, high-ownership, low-drama team where no one hands you a ticket and watches over you.

Values and traits they consistently look for.

• Ownership. You drive things to done without being managed. The real test: when something broke at 11 PM, did you own it or wait for morning?
• Simplicity. You reach for the simplest thing that works and resist over-engineering. Bonus if you can name a time you deleted code or said no to a feature.
• Honesty and transparency. You say "I don't know" and surface problems early. In a money company, hiding a bug is worse than causing one.
• Long-term thinking. You optimize for maintainability and the customer, not resume-driven tech choices. They would rather you pick the boring, well-understood tool.
• Genuine interest in the domain. Curiosity about markets, fintech, and building tools people rely on with their money. You do not need to be a trader. You do need to care why a wrong number here hurts a real person.

Prep your stories. Write 5-6 STAR stories (Situation, Task, Action, Result) covering: a hard bug you owned end to end, a time you chose the simple solution over the fancy one, a disagreement you handled well, a failure and what you learned, and something you built from scratch.

One full worked STAR example.

• Situation: Our payments reconciliation job silently double-counted some refunds during a month-end spike, and finance flagged a ₹2L mismatch.
• Task: I owned reconciliation and had to find the root cause and prevent it, without blocking the month-end close.
• Action: I traced it to non-idempotent retries, a webhook could fire twice and we processed both. I added an idempotency key on the transaction ID with a unique DB constraint, made the handler safely re-runnable, backfilled the affected rows with a verified script, and added an alert for any future count drift.
• Result: The mismatch dropped to ₹0 that cycle and stayed there, reconciliation now runs unattended, the idempotency pattern was adopted by two other services, and close time dropped by about half a day each month.

Why this story lands:

• It ends on a number. Always land a measurable outcome.
• It is about money being wrong and you making it right, which is the exact instinct this company is hiring for.

7Your prep plan#

4-week plan.

• Week 1. Revise core DSA (arrays, strings, hash maps, two pointers, stacks/queues, sorting, binary search). Solve ~5 Easy-Medium problems a day, writing clean code each time, not just passing the test.
• Week 2. Trees, recursion, light graphs (BFS/DFS, topological sort), and intervals. Add concurrency basics in your target language (Go goroutines/channels or threads), and write one real worker-pool from scratch.
• Week 3. Machine-coding/LLD. Build 4-5 small systems end to end (rate limiter, KV store with TTL, order manager, parking lot) with tests. Time yourself to 75 minutes and stop when the timer stops, so you learn what fits.
• Week 4. System design for your level, mock interviews, and writing out your STAR stories. Re-read your own past projects so you can explain every decision, including the ones you would make differently now.

2-week plan.

• Days 1-4. DSA patterns, 6 problems/day, focus on clean code plus complexity.
• Days 5-9. Machine-coding, build 3 small systems end to end, timed.
• Days 10-12. System design fundamentals plus one real brokerage-flavored design.
• Days 13-14. STAR stories, two mock rounds, rest.

2-day crash plan.

• Day 1 morning. Drill hash map, two-pointer, sliding-window, stack problems. Afternoon: build one timed machine-coding problem (rate limiter or KV store) with tests.
• Day 2 morning. One system design walkthrough plus review Go/DB/OS fundamentals. Afternoon: write 4 STAR stories, re-read your resume, prep 3 questions to ask them.

8Why people get rejected at Zerodha#

1. Framework knowledge without fundamentals. They probe why: how a map resolves collisions, how a B-tree index speeds up a query and when it does not, what a goroutine costs in memory. Shallow answers end it, and here the follow-up always comes.
2. Over-engineering the machine-coding problem. An elaborate abstraction and nothing that runs at the buzzer. Simple and working wins. This is the single most common reason strong-on-paper candidates fail this loop.
3. Can't explain your own resume. If you can't walk through a listed project and defend its decisions, trust evaporates. Do not list anything you cannot defend under three "why"s.
4. Buzzword behavioral answers. Generic "I'm passionate and a team player" with no concrete story and no number. They have heard it, it tells them nothing.
5. No sense of the domain. Zero curiosity about markets, money correctness, or why reliability matters in fintech reads as a poor fit. You do not need jargon, you need to show you understand the stakes.
6. Messy code. Bad names, giant functions, no edge-case handling, errors ignored. This company lives in its codebase, so sloppiness is disqualifying even when the logic is right.

9The offer, comp & negotiation#

Zerodha pays competitively and fairly for the Indian market, with a structure that leans toward cash and clarity rather than large equity grants. It is bootstrapped and privately held, so there is no stock-option lottery to dangle.

• Base plus a performance component.
• Benefits and a genuinely humane culture are a real part of the package, not a line in a brochure.

Rough ranges (vary by level, skill, and team):

• Early-career SDE: ~₹18-35L total.
• Senior SDE: ~₹35-60L+ total.
• Lead/architect: higher, negotiated case by case.

Negotiation tips.

1. Anchor on scope and proof, not tenure. Point to what you shipped and owned. They respect demonstrated craft over years served.
2. Have a competing data point. A real market benchmark or another offer moves cash more than "I'd like more." Bring the number, not the wish.
3. Negotiate the whole package honestly. This is a culture that values transparency, so an inflated number or games will backfire and can sour the whole thing. Ask clearly, give your reasoning, be reasonable. If a round number matters to you, say exactly that and why.

Want this turned into a personalized, dated prep schedule around your actual interview date? Build one so every day between now and your loop has a clear focus.