Interview experience
Zerodha Interview Questions and Answers (2026)
Overview
Section titled “Overview”Zerodha runs a shorter process than most large tech companies, but its real filter is the tiny, ultra-selective engineering team behind it - one of India’s leanest at its scale - which makes cultural and philosophical fit as decisive as the technical rounds.
Zerodha interview process at a glance
Section titled “Zerodha interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Resume Screening | - | Relevant projects, fit for a lean team |
| Online Assessment | 60-90 min | Aptitude + DSA coding |
| Technical Interview(s) | 45-60 min each | SQL, case studies, problem-solving reasoning |
| HR/Managerial | 30 min | Motivation, fit with a bootstrapped culture |
Resume Screening
Section titled “Resume Screening”Zerodha’s screening stage looks past CGPA and pedigree toward demonstrated interest in fintech and markets - side projects, open-source contributions, or coding-bootcamp work tend to stand out more than a generic resume, since the hiring team is small and reviews applications closely rather than running a bulk campus filter.
Common questions
- Walk through a project that shows genuine interest in fintech, trading, or systems work
- Why are you applying to a company this small rather than a large funded startup?
- What open-source or personal work can you point to beyond coursework?
Online Assessment
Section titled “Online Assessment”A 60-90 minute test covering logical reasoning, quantitative aptitude, and a DSA coding round. It’s a standard screen before the more open-ended technical interviews.
Common questions
- Logical reasoning and quantitative aptitude problems
- Array/string DSA problems at easy-medium difficulty
- Basic debugging or code-tracing questions
Technical Interview(s)
Section titled “Technical Interview(s)”One or more 45-60 minute rounds mixing SQL, debugging, and case-study style problems relevant to trading and fintech products. Interviewers consistently probe how you reason through a problem out loud, not just whether you land the “right” answer. Some roles add a take-home assignment before this stage.
Common questions
- Write and optimise SQL queries against a schema you’re given
- Debug a piece of broken or inefficient code and explain your reasoning
- Case-study problems framed around trading or fintech scenarios - think aloud through assumptions and trade-offs
- Questions on your take-home assignment (where one was given): design choices and what you’d change
Round-by-round narratives are on the Zerodha interview experience page.
HR/Managerial round
Section titled “HR/Managerial round”A closing 30-minute conversation that doubles as Zerodha’s cultural-fit check - candidates consistently describe this as a genuine filter, not a formality, given how small and tight-knit the team is.
Common questions
- Why Zerodha, especially over a VC-funded startup?
- Zerodha runs with a small, lean engineering team - how do you stay productive without a large support structure?
- Tell me about a time you had to make a call with high ownership and little oversight
- What do you know about Zerodha’s bootstrapped, no-external-funding business model?
Sample answer frameworks for each of these are on the Zerodha HR interview questions page.
Why Zerodha’s hiring bar is different
Section titled “Why Zerodha’s hiring bar is different”Zerodha is a genuine outlier among Indian tech employers: its CTO Kailash Nadh has publicly said the company’s tech team hired only about five people over four years, keeping total engineering headcount well under 50 with very low attrition. The stated philosophy is that a small, senior, deeply-aligned team can build and operate large-scale systems without needing to scale headcount the way most funded startups do. Practically, this means Zerodha isn’t running seasonal bulk campus drives - openings are rare, hiring is slow and selective, and the interview process weighs whether you’d genuinely “gel” with a small existing team as heavily as it weighs your DSA and SQL skills. If you’re used to large-company hiring funnels, expect a noticeably more personal, higher-scrutiny process for far fewer seats.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: Write a SQL query to find each user’s most recent trade.
Use a window function: SELECT user_id, trade_id, symbol, traded_at FROM (SELECT t.*, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY traded_at DESC) AS rn FROM trades t) x WHERE rn = 1;. ROW_NUMBER partitions the rows per user and numbers them newest first, so filtering to rn = 1 gives exactly one row per user. The older correlated-subquery form joins trades against a grouped MAX(traded_at) per user, but that returns two rows if a user has two trades at the same timestamp, whereas ROW_NUMBER breaks the tie deterministically. Make sure there is an index on (user_id, traded_at) or the window function forces a full sort of the table.
Q: How do you find the top gainers from a table of daily prices?
Self-join today’s close against yesterday’s, or use LAG, which is cleaner: SELECT symbol, trade_date, close_price, LAG(close_price) OVER (PARTITION BY symbol ORDER BY trade_date) AS prev_close FROM prices;, then wrap it and compute (close_price - prev_close) / prev_close * 100, ordering descending and limiting. The pitfalls Zerodha interviewers look for are integer division truncating the percentage (cast to a decimal type), dividing by a zero or NULL previous close, and correctly skipping non-trading days, since LAG uses the previous existing row rather than the previous calendar day. Storing money as DECIMAL rather than FLOAT matters here too, since binary floating point cannot represent decimal fractions exactly.
Q: How would you debug a query that suddenly got slow in production?
Start with EXPLAIN or EXPLAIN ANALYZE to see the actual plan and row estimates - the usual cause is the optimiser switching from an index scan to a sequential scan because statistics went stale after a bulk load, fixed by running ANALYZE. Next check whether the predicate is sargable: wrapping the indexed column in a function or an implicit type cast disables the index. Then look at whether the data volume itself crossed a threshold, at lock waits from a concurrent long transaction, and at whether an index was recently dropped. Reproduce with the same parameters, because a plan cached for one parameter value can be terrible for another - the classic parameter-sniffing problem.
Q: How do you find the k largest elements in a stream of prices?
Keep a min-heap of size k. Push each incoming price, and whenever the heap size exceeds k, pop the smallest - so the heap always holds the k largest seen so far, with the k-th largest sitting at the root for O(1) access. Each element costs O(log k), so processing n elements is O(n log k) time with O(k) space, which is what makes it viable on an unbounded stream where you cannot store or sort everything. Sorting the whole input would be O(n log n) and needs all the data up front. Use the mirror max-heap if you want the k smallest.
Q: How would you design a schema for an order book and holdings?
Keep three core tables: orders(order_id PK, user_id, symbol, side, quantity, limit_price, status, placed_at), trades(trade_id PK, order_id FK, filled_quantity, fill_price, executed_at) since one order can fill in several partial trades, and holdings(user_id, symbol, quantity, average_price) with a composite primary key. Store all money as DECIMAL, never FLOAT, so rounding does not accumulate. Holdings are strictly derived from trades, so treat trades as the append-only source of truth and update holdings inside the same transaction as the trade insert, or recompute them from the trade log. Index orders on (user_id, placed_at) for the order-history screen and on (symbol, status) for matching queries.
Q: Why should money never be stored as a floating-point number?
IEEE 754 binary floating point cannot represent most decimal fractions exactly - 0.1 plus 0.2 evaluates to 0.30000000000000004 - so repeated addition of prices and fees accumulates drift, and equality comparisons on balances become unreliable. In a trading or brokerage system that drift becomes real money and fails reconciliation. The correct choices are a fixed-point DECIMAL or NUMERIC column with an explicit precision and scale, or storing integer paise and formatting at the display layer. In Java that means BigDecimal constructed from a string rather than a double, and in Python the decimal module rather than the built-in float.
Q: How would you approach a case-study question in a Zerodha interview?
State your assumptions out loud first - the volume of users, the read-versus-write ratio, and what correctness guarantee the feature actually needs - because interviewers here are explicitly grading reasoning rather than a memorised answer. Then narrow the problem to its hardest constraint: for a trading feature that is usually latency during market open and correctness of money movement, not raw storage. Propose the simplest design that satisfies it, name the specific failure mode you are worried about, and only then add complexity to address that failure. Saying what you would deliberately not build, and why, tends to land better at a company that runs a lean team and prizes low overhead.
Q: What is idempotency, and why does it matter for order placement?
An idempotent operation produces the same result whether it is applied once or many times. It matters because a client that times out cannot tell whether the order reached the server, so a naive retry can place a duplicate order and move real money twice. The standard fix is an idempotency key: the client generates a unique request ID, the server stores it with the resulting order in a table with a unique constraint, and a repeat of the same key returns the original stored result instead of creating a new order. Note that GET, PUT, and DELETE are idempotent by HTTP semantics while POST is not, which is exactly why order-placement endpoints need the key made explicit.
Frequently asked questions about Zerodha interviews
Section titled “Frequently asked questions about Zerodha interviews”What is the Zerodha interview process for freshers?
Zerodha’s process typically has 3-5 stages: 1. Resume/profile screening. 2. Online Assessment (60-90 minutes) covering logical reasoning, quantitative aptitude, and a coding round on data structures and algorithms. 3. One or more Technical Interviews (45-60 minutes each), often including SQL and case-study style problem solving. 4. HR/Managerial round (30 minutes) on fit and motivation. Some roles insert a take-home assignment between the OA and the technical rounds.
What questions are asked in Zerodha interviews?
Zerodha interviews cover DSA and debugging problems, SQL queries, case studies relevant to trading/fintech products, and questions about your reasoning process rather than rote answers. Behavioural questions probe why you want to work at a small, bootstrapped, profitable company instead of a large funded startup, and how you’d operate with a lean team and high autonomy.
How many rounds are there in the Zerodha interview?
Zerodha typically runs 3-5 rounds depending on the role: resume screening, an online assessment, one or two technical interviews (sometimes with a take-home assignment), and a final HR/managerial round. Compared to large tech companies the process is shorter, but candidates report it is still rigorous.
How should I prepare for Zerodha interviews?
Practise DSA and SQL fundamentals, be ready to reason through case studies out loud, and read up on Zerodha’s bootstrapped, no-external-funding business model since interviewers often probe whether you understand and want that kind of low-overhead, product-first culture.
Why does Zerodha hire so few engineers?
Zerodha runs one of India’s leanest engineering teams for its scale - its CTO has said the tech team hired only a handful of people over several years and still counts well under 50 engineers total, with very low attrition. The company believes a small, senior, deeply-trusted team can build and run large-scale systems without needing to scale headcount, so every opening is filled slowly and selectively rather than through bulk campus hiring.
What does Zerodha look for beyond technical skill?
Cultural and philosophical fit weighs heavily - Zerodha’s CTO has described wanting people who “gel well” with the existing team and share its low-overhead, ownership-driven philosophy, not just people who clear a DSA bar. Demonstrated passion for fintech and markets (side projects, open-source work, genuine curiosity about trading systems) tends to matter more here than at larger, process-driven companies.