One guide describes Zerodha's engineering hiring as a recruiter call, a small practical task, one to three technical conversations that start from your own projects, and a final fit conversation. First-person engineering reports are scarce, so everything here is secondary and rests mainly on that one guide.
Reported by candidates and, where we found one, the company itself. Each round shows how well it is reported. Processes change by team, level and year.
1
Recruiter call
HR and offerabout 30 min
Prep guides
Call covering background, reason for applying and notice period; a second guide describes an HR or recruiter screen on role fit, location and salary.
The closing conversation: motivation, expectations, notice period, compensation and how the offer is structured. Prepared answers and a clear number help here.
Current and expected compensation, and how to answer without boxing yourself in
Be honest and avoid giving a single number too early. Share your current pay only if you are comfortable, and make clear what is fixed and what is variable. For expectations, say you are flexible for the right role, and offer a researched range based on level and market. If pushed, state a figure you can justify. Never state a number you cannot support, because offers are often checked.
Give the facts exactly as they are in your contract. State the notice period, whether early release or a buy-out is truly possible, and the earliest honest joining date. Do not promise a date your employer has not agreed to. For relocation, say whether you can move, how soon, and whether you would need support. Clear, early information helps the recruiter plan and shows you are reliable.
Keep it positive and forward looking. Talk about what you want more of, such as larger scale, ownership or a stronger team, rather than criticising your current employer. The listener checks that you will not leave this job for the same reason. Opening line: I have learned a lot in the current role, and I now want to work on problems at a bigger scale.
Levels, equity and how the offer is built
Ask for the structure rather than only the total. Find out the level and title, base salary, bonus and whether it is guaranteed, equity amount, vesting schedule and cliff, joining bonus and any clawback. Compare offers on a yearly total with the same assumptions. If equity is in a private company, ask how it is valued and what happens on leaving. Asking calmly is normal and expected.
A small program written on your own time and submitted with a README. Judged on whether it runs, how it is organised and how you explain choices. A guide cites a CSV-processing sample.
working code
code organisation
written explanation
data processing
Varies: One guide describes it for engineering candidates and says an online test appears only in third-party guides, unconfirmed; the other guide describes role-dependent tasks such as support scenarios or data cases.
What can be asked in a take-home or practical task round
A small program or service to build on your own time, reviewed for correctness, clarity, tests and how you explain your choices.
Fetch data over HTTP, process a file and produce a report
Read the brief twice and list what is required and what is optional. Fetch with a timeout and handle failures and bad status codes, stream or read a large file in a way that fits memory, and parse defensively. Keep the report format exactly as requested. Separate fetching, processing and output into small functions so they can be tested, and note your assumptions in the README.
A small API or CLI with a README, tests and sensible error handling
Keep the scope small and the quality high. A clear README should explain how to install, run and test it, and list the decisions you made. Validate input, return helpful errors and use consistent status codes or exit codes. Add tests for the main path and two or three edge cases. A tidy small project is better than a half-finished large one.
Be ready to list your shortcuts yourself, and say what you would do with more time. For example, there is no pagination, the input is fully read into memory, and there are no integration tests, and each shortcut has a reason. This shows judgement rather than weakness. Know every line of your code and be ready to change it live.
One to three video or in-person sessions that start from your resume projects, then cover your daily language, relational databases and how systems behave under load. The guide notes that Zerodha runs Go services and large PostgreSQL deployments.
project depth
relational databases
backend language fluency
system behavior under load
Varies: Guide says some candidates report two technical conversations, others four or five stages in total.
Practise for this round
ReportedPractical task: fetch a zip over HTTP, extract a CSV, process its rows Sample task cited by one guide, not confirmed by a candidate.Prep guide ↗
Reported prompts have no written answer yet. Read the linked page for context.
What can be asked in a role-specific deep dive round
Depth in the skills the job needs: a language or framework, APIs, debugging, cloud basics, or the company's own domain such as payments or trading.
Language and framework internals for the role (JavaScript, React, Node, Java and so on)
Prepare the internals of the stack named in the job, not just usage. For JavaScript, be able to explain closures, the event loop with its microtask queue, and how this is bound. For React, explain rendering, keys, and why state updates are batched. Give a short example with each claim, and say when you do not know a detail rather than guessing. The depth is checked by follow-up questions.
API design, error handling, idempotency and retries
Good API design is predictable. Use clear resource names, correct status codes and a consistent error body with a stable code. A retry is only safe if the operation is idempotent: GET and PUT already are, and for POST accept an idempotency key and return the stored result on repeat. For retries use exponential backoff with jitter and a cap, and only retry errors that can succeed later, such as timeouts or 503.
Work from the user-visible symptom inward. Check whether errors or latency rose, when it started and what changed at that time, such as a deploy. Use metrics to find the failing component, logs with a request id to follow one failing request, and traces to find the slow hop. Form one hypothesis, test it, and roll back if a recent release is the likely cause. Say you would write down what you learned afterwards.
Cloud, containers and deployment basics
Know the basic picture and be honest about your depth. A container packages an app with its dependencies and shares the host kernel, unlike a virtual machine. An image is built from layers and run as a container. For deployment, mention a build in CI, an immutable image, configuration through environment variables, health checks and a rollback path. Name one cloud service you have used and what it does.
Domain scenarios: duplicate callbacks, reconciliation, market data
Think about duplicates, ordering and mismatch. A payment provider may send the same callback twice, so store the event id and process each once, making the handler idempotent. Reconciliation compares your records with the provider's settlement report and flags differences for review. For market data, expect out-of-order or missed ticks, so sequence numbers and a way to request a replay matter. Name what you would alert on.
Video or in person, on working style and expectations; interviewers reportedly explain that much of the work is routine data processing shaped by regulation.
A conversation about your past work and how you would fit the team: depth on projects, ownership, decisions and trade-offs, sometimes a design problem.
Pick a project and go deep: why this design, what broke, what you would change
Choose a project you can discuss at every layer. Explain the problem and who it served, the options you considered, why you chose one, what broke and what you would change now. Be clear which parts you did and which the team did. Admitting a flaw earns trust. Opening line: the main constraint was latency, so I chose a cache in front of the database, and I would now add an invalidation strategy.
A time you disagreed with a teammate or pushed back on a decision
Use situation, task, action, result, and keep the disagreement about the work, never the person. The listener is checking that you can hold a view with evidence, listen, and commit once the decision is made. Describe what you proposed, the data or reasoning you used, how you reached agreement or accepted the other path, and what happened. Do not invent a story: use a real one, even a small one.
Show a method rather than a claim of being busy. Describe how you judge impact and deadline, ask who needs the result and when, and say no or renegotiate scope early when two things clash. Mention communicating the trade-off to stakeholders so nobody is surprised. A sentence you could adapt: I list what is blocking others first, then what has a fixed date, then what moves a metric.
Answer honestly and tie it to what the role offers. Say what you want to learn or own next, such as larger systems, more ownership of design, or mentoring, and what kind of team helps you do it. Then ask what the team is trying to achieve this year and how the work is reviewed. The listener checks that your wishes match the job and that you have thought about it.
The hiring manager, behavioural and offer conversations. Candidate reports shape the themes; the answers and frames are written for this site, so use them as a structure and bring your own stories.
Customer interest over growthDo not nudge or induce people into actions that do not serve them, even when that action would lift a number.
TransparencyDescribed as central to the business, with examples such as an early brokerage calculator and public disclosure of regulatory filings about technical glitches.
No metric-based growth targetsNo targets on accounts opened, app installs, orders or revenue, so employees are not pushed by perverse incentives.
Themes candidates report being probed
Reason for applying and motivation
Notice period and logistics
Simplicity, transparency and ownership
Things you built outside work
Working style and expectation alignment
Regulation-shaped routine work
Questions to rehearse
Describe a time you took something complicated and made it simpler for the people who had to use or maintain it.Prep guides
What is being checked. A prep guide describes a conversational culture round that probes for times you simplified something complex, and the same guide ties Zerodha to simplicity and common sense over coolness.
How to frame it. Name the original complexity, what you removed or merged, and how you knew it was safe to cut. Close with what got easier for the next person. An opening you can adapt: 'The part of [system] that people avoided touching was [thing], so I [removed or merged what], and the result was [measurable or visible change].'
Tell me about a time you pushed back on a feature or change because it would have hurt the people using the product.Prep guides
What is being checked. A prep guide reports this theme, and it lines up with the published principle of not steering customers toward actions that are not in their interest.
How to frame it. Show the harm you saw, the evidence you brought, who you raised it with and what was decided, including if you lost the argument. Keep it about the user rather than about winning. An opening you can adapt: 'We were about to ship [change], and I could see it would [specific harm to users], so I [took this step] before the date.'
Give an example of something you figured out entirely on your own, with no one to show you the way.Prep guides
What is being checked. The same guide lists figuring things out alone as part of the culture conversation, and a Z-Connect post says there are no titles or conventional ladder, so people who can unblock themselves fit that setup.
How to frame it. Say what was unfamiliar, how you broke it down, what you read or tried, and where you decided to stop and ask. Show the habit, not just the result. An opening you can adapt: 'I had no one nearby who knew [area], so I started by [first concrete step] and set myself a limit of [time] before asking.'
Why do you want to work here, and what drew you to this company in particular?Prep guides
What is being checked. A guide reports that the recruiter call covers background and the reason for applying, and a Z-Connect post says hiring looks for people who share the philosophies and are committed for the long term.
How to frame it. Anchor on one or two things from the published philosophy that you can connect to work you have done, rather than on brand or growth. Be honest about what you would give up or change. An opening you can adapt: 'What stood out to me is [specific principle], because in my last role I saw [concrete situation] go the other way.'
There are no metric-based growth targets here. What keeps you doing good work when nobody measures a number against you?Prep guides
What is being checked. The philosophy page describes no metric-driven incentives, so a listener may want to hear what drives you when external targets are absent.
How to frame it. Give your own internal standard, such as correctness, reviews you hold yourself to or user outcomes you track informally, then one habit that proves it. Avoid claiming you dislike all measurement. An opening you can adapt: 'My own bar is [standard], and I check it by [habit], even when nobody else looks at it.'
This company has no conventional titles or ladder. How do you think about growth and responsibility without them?Prep guides
What is being checked. A Z-Connect post sharing the CTO's views says there are no titles or conventional ladder and that growth means being given more responsibility and allowed more risk, so a candidate who needs a title ladder may be a poor fit.
How to frame it. Describe a time you widened your scope without a title change, what you took ownership of and what risk came with it. Say what recognition you do want. An opening you can adapt: 'In [role] I took on [extra responsibility] before anyone assigned it, and what I learned about carrying that risk was [lesson].'
What are you looking for in terms of role, location, working mode and notice period?Prep guides
What is being checked. One guide describes the HR screen as covering fit, location, work mode, salary and notice period, and another mentions background, reason for applying and notice period, so logistics and expectations are checked early.
How to frame it. Have your notice period, any buy-out option and your location and mode preferences ready in two sentences, and state them without hedging. Do not volunteer a figure before you understand the role. An opening you can adapt: 'My notice period is [period], and I can [shorten it or not]; for work mode I am looking for [mode].'
No first-hand offer account was found. The only official description of hiring is a December 2025 Z-Connect post sharing the CTO's views, which describes hiring for long-term commitment and shared philosophies, no titles, and pay growth tied to personal and professional growth rather than hierarchy.
One guide says the HR screen touches on salary and notice period, but neither guide is a first-hand report, so treat the timing as unconfirmed.
As general advice, ask for the complete breakdown in writing, confirm how the notice period or any buy-out is handled, and ask how responsibility and pay change over time given there is no ladder.
What we could not verify. No first-hand Zerodha engineering report was readable, so all behavioural content here is guide-level. One guide says the CTO or senior leadership often runs the culture round, which no other source confirms, and that guide also promotes a mock-interview service. The philosophy page is the only values source; the hiring and no-titles points come from a Z-Connect post by an investments team member, which also says Zerodha was not hiring at the time.
What we could not verify. No first-hand Zerodha engineering report could be read: the Feb 2024 LeetCode backend post (stages: CTO resume talk, DSA, system design, behavioural; ghosted) returned 403 so it is not cited. Prepfully and InterviewPal pages contained no engineering rounds or questions. No coding (DSA) questions are verified. Durations other than the recruiter call are unknown. The second guide (Hyring) describes role tasks and a manager, HR and offer stage and does not mention Go, PostgreSQL or the CSV task, so the engineering details rest on the first guide alone.