Zerodha Phone Screen Interview: What It Covers and How to Pass

Most software engineer phone screens are a standardized 45-minute DSA session. The Zerodha phone screen interview isn't. The first call is a two-part filter: fintech domain knowledge plus technical depth. Miss either half and you're out before the onsite even starts.

This guide covers exactly what the phone screen tests, how it's scored, and what to do to pass it. For what comes after, the Zerodha onsite guide covers each subsequent round and the complete Zerodha interview guide maps the whole process.

Why the Zerodha Bar Is Unusually High for Its Size

Zerodha runs India's largest brokerage on roughly 35 engineers. CTO Kailash Nadh has said publicly the team hired five people in four years. Five. Total. In four years.

That number tells you everything you need to know about this process. They're not filtering 500 mediocre candidates down to 50. They're finding the two or three people who fit technically and culturally, and they have time to be extremely picky about it.

At larger companies, an interviewer who likes you can paper over a weak answer. At Zerodha, there are no padding rounds. One weak signal and the loop stops. The phone screen is that first cut.

The Format: Two Parts, One Call

The phone screen typically runs 45 to 60 minutes and splits into two distinct sections.

Section	Duration	What It Tests
Domain and background	15-20 min	Fintech knowledge, SQL, motivation
Technical coding	30-40 min	DSA, Go or Python, systems thinking

Some candidates report the domain section arrives as a timed online test before the live call. Others skip straight to a combined session. Assume both land in the same call and prepare accordingly. Getting surprised by the fintech questions is a great way to come across as someone who didn't read the job description.

Part One: The Domain Round

Fintech knowledge is non-negotiable

Zerodha doesn't hire engineers to write generic CRUD services and call it a day. They build trading infrastructure, risk systems, and clearing engines. The phone screen filters out candidates who treat the business like a side note.

Expect questions like:

What is a futures contract and how does it differ from an options contract?
What is SEBI and what does it regulate?
What is a limit order versus a market order?
What is intraday trading and what happens at end-of-day if positions aren't squared off?
Explain order matching at a basic level.

You don't need to be a trader, but you need basic financial literacy. An engineer who can explain margin trading and why settlement cycles matter will stand out from one who has only ever opened the Zerodha app to check if their portfolio is still hurting.

Spend two or three hours on SEBI's investor education portal and Zerodha's own Varsity before the call. Varsity is free, covers everything from equity basics to derivatives, and was literally built by the company interviewing you. Reading it signals domain interest and product familiarity at once.

SQL for non-ML roles

For backend and full-stack roles, SQL comes up more than candidates expect. Common shapes:

-- Find the top 5 customers by trade volume in the last 30 days
SELECT customer_id, SUM(trade_value) AS total_volume
FROM trades
WHERE trade_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY customer_id
ORDER BY total_volume DESC
LIMIT 5;

Be comfortable with window functions, GROUP BY aggregates, and JOINs. Index behavior and query optimization are fair game for senior roles. If you've been living purely in ORM land, this is the week to revisit raw SQL.

Part Two: The Coding Round

What Zerodha actually tests

Zerodha's backend stack is primarily Go, with some Python and JavaScript. They rewrote core services from Python to Go specifically for throughput and concurrency at scale. If you're applying for a backend role, Go is a real advantage, not a box you can leave unchecked.

The DSA difficulty sits at LeetCode medium, occasionally drifting harder for senior candidates. The raw algorithmic work is comparable to mid-tier product companies, but with a practical twist: many problems arrive dressed in financial or trading context.

Common categories:

Arrays and sliding window: order book operations, rolling volume windows, moving averages
Hash maps and sets: portfolio aggregation, duplicate trade detection
Graphs and BFS/DFS: dependency resolution in clearing systems
Concurrency primitives: goroutine safety (if you're interviewing in Go), race conditions in order processing

A realistic example

You might be asked to implement a rate limiter for trading API requests, or find the maximum drawdown in a stock's price history. These aren't abstract riddles. They test whether you can apply patterns you should already know to a domain you've hopefully prepared for.

// Maximum drawdown: largest peak-to-trough decline
func maxDrawdown(prices []float64) float64 {
    if len(prices) == 0 {
        return 0
    }
    maxPrice := prices[0]
    maxDraw := 0.0
    for _, p := range prices[1:] {
        if p > maxPrice {
            maxPrice = p
        }
        draw := (maxPrice - p) / maxPrice
        if draw > maxDraw {
            maxDraw = draw
        }
    }
    return maxDraw
}

Go, financial framing, simple O(n) traversal. That's the whole pattern.

Concurrency matters more here than elsewhere

Zerodha's systems handle millions of WebSocket connections delivering live market data. Concurrent access to shared state is not a trivia topic here. It's a daily production concern.

Be prepared to talk about mutexes, channels in Go, and when one is preferable to the other. If you're using Python, know the GIL and why it matters for I/O-bound versus CPU-bound work. If Go, understand goroutines and when a sync.RWMutex is the right call versus a channel.

Saying "I'd just use a goroutine" without explaining the synchronization story is roughly equivalent to saying "I'd just write some code" and leaving the room.

How the Phone Screen Is Scored

Interviewers at Zerodha are evaluating three things at once.

Can you actually build something? Technical correctness on the coding problem is table stakes. Partial credit exists but won't carry you past a peer who shipped clean code.

Do you understand the context? A candidate who implements a rate limiter without being able to explain why trading APIs need rate limits at all sends a weak signal. Domain answers don't have to be expert-level, but they have to show genuine curiosity about the business.

Would you thrive on a 35-person team? Every hire matters when your whole engineering team fits in a conference room. The interviewer is listening for intellectual honesty (saying "I don't know" clearly beats bluffing), directness, and low-ego pragmatism. Answers that over-engineer problems, or that spend five minutes on framework choices instead of first-principles reasoning, tend not to pass.

Common Mistakes That End Candidacies Here

Treating domain questions as warmup. The fintech section is not small talk before the real interview. Candidates who give vague answers ("I know Zerodha is a brokerage") instead of showing they've read Varsity or can distinguish equity from derivatives get dinged before the coding starts.

Using Python when Go is preferred. If a job description mentions Go, writing Python in the coding round signals you didn't read the role. It's not instantly disqualifying, but it removes your chance to show Go-specific knowledge (goroutines, error handling patterns, interfaces) that the team actually values.

Going silent during coding. Communicating your reasoning out loud matters in any loop. It matters more at a small company where the person evaluating you is the person you'd share a Slack channel with every day. Silence while you think reads as uncertainty.

Reaching for Kafka before a database. Zerodha's tech blog explicitly favors simplicity. A candidate who immediately proposes Kafka, Redis, and a microservices mesh for a problem solvable with a single Go server and a Postgres table looks like they're padding a resume, not solving a problem.

Skipping the clarifying questions. Asking good clarifying questions before writing code is a baseline signal. For a fintech problem especially, this matters: what happens on market close, what's the expected QPS, do prices include fees?

How to Prepare for the Zerodha Phone Screen Interview

Three to four weeks out:

Work through Zerodha's Varsity modules on equity, derivatives, and mutual funds. Not every chapter. Chapters 1-4 of each module cover roughly 90% of what you'd face. Build a list of 15-20 fintech terms you can define and explain out loud.

Refresh SQL. Window functions, query planning basics, indexing. Two or three LeetCode SQL problems a day for a week is enough. If you haven't written a window function in six months, now is the time.

If you're applying for a Go role and don't know Go, start now. You won't become fluent in a month, but you can learn enough to read, modify, and write basic idiomatic Go. Sufficient is fine. Pretending you know it when you don't is not.

One to two weeks out:

Focus on medium-difficulty DSA in the categories above. Sliding window, graphs, and hash map problems are the most common. Practice explaining your approach as you code, not after. Out loud. Alone in a room if necessary. It feels weird. Do it anyway.

Work one or two problems in a financial context to get comfortable with that framing. Maximum subarray profit, rate-limiting windows, portfolio aggregation from a trades table.

Day before:

Read Zerodha's engineering blog at zerodha.tech and skim two or three recent posts. You'll absorb their actual engineering philosophy: small team, pragmatic tools, Go, PostgreSQL. Knowing they have a public FOSS stack and care about open source is worth mentioning naturally if it comes up.

Where Mock Interviews Help

The domain knowledge and coding are both learnable from a book. The hard part to train solo is the combined pressure of fintech questions followed immediately by live coding, without losing composure or narrating your panic.

SpaceComplexity runs voice-based mock interviews with rubric-based feedback that mirrors this structure, including problem types similar to what fintech companies test. Running three or four sessions before the actual call will make the real thing feel familiar rather than like a pop quiz you forgot was scheduled.

Key Takeaways

Zerodha's phone screen is two rounds in one: fintech domain knowledge plus coding.
The team is 35 engineers. Every hire is deliberate. The bar is high relative to headcount.
Learn basic stock market concepts from Varsity before the call. It is not optional.
Go is the primary backend language. If the role lists Go, code in Go.
Concurrency knowledge (goroutines, mutexes) comes up more here than at most companies.
SQL is tested for backend and analytics roles. Window functions and aggregates, not just SELECT *.
Zerodha values simplicity and directness. Overengineered answers are a red flag.
Saying "I don't know" clearly is preferred over bluffing. They can tell.