Site Reliability Engineer Interview Experience at Zerodha – 2025

This initial HR round covers background and motivation. Given Zerodha's known preference for engineers who are comfortable admitting uncertainty, the HR interviewer tends to ask less about the resume line by line and more about how a candidate typically reacts when given a task they don't immediately know how to solve — specifically asking for the last time a candidate told a manager 'I don't know yet, let me find out' rather than guessing. This framing question is consistent with what real candidates describe as setting the tone for the rest of Zerodha's process.

This online test blends stock market fundamentals with SQL, a genuinely distinctive part of Zerodha's process. The market section asks basic conceptual questions — what a mutual fund is, how a limit order differs from a market order, what happens to open positions at circuit limits — since Zerodha expects engineers to understand the domain they are building for, not just the technology. The SQL section gives a simplified trades table and asks candidates to write a query computing the running total of trade volume per customer per day using a window function, then a second query to find customers whose trade count in the current month exceeded double their trailing three-month average.

This is the core technical round, and the longest of the loop at 90 minutes. It begins with Linux networking internals: candidates are asked to explain, in detail, what actually happens at the kernel level during a TCP three-way handshake, and then what happens to the connection backlog queue when incoming connections arrive faster than the application can accept() them. From there candidates are given a genuinely slow Postgres query against a large trades table and asked to diagnose it using EXPLAIN ANALYZE — the root cause is typically a missing index on the join column between trades and instruments, and candidates need to justify why a composite index would help more than two single-column indexes given the actual filter pattern in the query. The round closes with Kafka: what happens to in-flight messages when a consumer in a group dies mid-processing before committing its offset, and how consumer group rebalancing handles that gracefully without message loss, assuming at-least-once delivery semantics.

This closing management round focuses on real incidents rather than hypothetical scenarios. Candidates are asked to walk through a production incident they were personally on-call for, specifically what the very first thing checked was upon getting paged, how the decision to escalate or handle it solo was made, and what changed in alerting or runbooks afterward. A direct question on alert-fatigue philosophy also comes up — whether a candidate would rather have more alerts that occasionally fire on non-issues, or fewer alerts with a higher risk of missing something real — with the interviewer pushing on the reasoning rather than accepting either answer at face value.