What Do Razorpay, Zerodha, and CRED Look For That TCS Doesn’t?
That’s the question most Indian developers never think to ask. They prepare for interviews the same way regardless of whether they’re applying to Infosys or to a Series B startup burning through venture capital. And then they wonder why the startup rejected them after what seemed like a “good” interview.
The hiring philosophy is fundamentally different. Service companies like TCS, Wipro, and Infosys hire in bulk. They need warm bodies who can be trained on a client’s tech stack. The interview is mostly about filtering out people who can’t code at all. Startups hire differently. Razorpay wants someone who can design a payment retry system on a whiteboard and then ship it by next Thursday. CRED wants someone who obsesses over code quality because their engineering team is small enough that every bad commit hurts. Zerodha wants someone who understands why they run their entire stack on a handful of engineers instead of throwing hundreds of bodies at the problem.
This guide breaks down exactly how startup interviews work, what each round tests, and how to prepare for them specifically. I’ve structured it as a Q&A because that’s probably how your brain is processing this anyway — you have questions, and I have strong opinions disguised as answers.
Q: How is the interview process structured at Indian startups?
Most startups run three to five rounds, completed in one to two weeks. Compare that to mass recruiters who might take two months and seven rounds of bureaucracy. The typical structure looks like this:
Round 1: DSA/coding assessment. Usually online, proctored, 60 to 90 minutes. Sometimes a HackerRank or Codility test sent to your email.
Round 2: System design. For mid-level and senior roles. A 45 to 60-minute discussion where you design a real system. Junior candidates might skip this.
Round 3: Machine coding. This is the round that catches corporate developers off guard. You get a problem, an IDE, and 60 to 90 minutes to write working code. Not pseudocode. Not a sketch. Working, runnable, well-structured code.
Round 4: Hiring manager or culture fit conversation. Less technical, more about how you think, how you handle ambiguity, and whether you’d actually enjoy working at a startup.
Some companies combine rounds or add an extra one. Razorpay, for instance, sometimes includes a “bar raiser” round with a senior engineer from a different team. PhonePe might throw in a deep-dive on your past projects. But the four-round structure above covers about 80% of what you’ll encounter.
Q: What kind of DSA questions do startups actually ask?
Here’s my strong take: Indian startups don’t care about obscure competitive programming puzzles. They’re not going to ask you to implement a suffix automaton or solve a problem that requires five nested observations about number theory. That’s a FAANG thing, and even FAANG is moving away from it.
Startups ask practical DSA questions. The kind where the algorithm matters because the feature depends on it. Here’s what shows up most often.
Arrays and Strings: Two-pointer problems, sliding window, prefix sums for subarray queries, and string manipulation (anagram detection, palindrome checking). You should solve these in 15 to 20 minutes comfortably. If you can’t, you haven’t practiced enough.
Hash Maps and Sets: Frequency counting, duplicate detection, two-sum and its fifty variations, grouping problems. Startups love these because they test whether you can pick the right data structure instead of brute-forcing everything. Know when a hash map beats sorting, and be ready to discuss the tradeoffs in time versus space complexity.
Trees and Graphs: BFS, DFS, lowest common ancestor, serialization for trees. For graphs, expect shortest path, cycle detection, topological sorting, and connected components. Most product companies test at least one tree or graph problem.
Dynamic Programming: It appears, but usually at LeetCode medium difficulty. Focus on the classic patterns: 0/1 knapsack, longest common subsequence, coin change, matrix chain multiplication. The key skill here isn’t memorizing solutions — it’s recognizing that a problem has overlapping subproblems and optimal substructure, which tells you DP applies.
For preparation, I think 150 to 200 problems on LeetCode is the right number for most people. Focus on the Blind 75 and NeetCode 150 lists. Dedicate 1.5 to 2 hours daily for 8 to 12 weeks. Practice in the language you’ll use in interviews — startups care about your fluency with the standard library, naming conventions, and idiomatic style. If you solve problems in C++ during practice but interview in Python, you’re going to fumble.
Q: System design at startups seems different from what I’ve read about FAANG. How?
Massively different. At Google, they might ask you to design YouTube’s video processing pipeline for 2 billion users. A startup interview at Razorpay is more likely to ask: “Design a payment processing system that handles retries, idempotency, and partial failures for a few thousand transactions per minute.”
See the difference? Startups want pragmatic decisions appropriate for their actual scale, not theoretical architecture that handles billions of requests. If you walk into a Zerodha interview and propose a microservices architecture with Kubernetes and a service mesh, they’re going to look at you funny. Zerodha runs their entire trading platform with a tiny engineering team. They want simplicity, reliability, and systems that a small team can maintain.
Domain context matters enormously here. Research the company before the interview. If you’re interviewing at a fintech company (Razorpay, Groww, PhonePe), expect questions about transaction consistency, idempotency, eventual consistency patterns, and payment retry logic. For an e-commerce company (Meesho, Flipkart), prepare for inventory management, search and recommendation engines, and order processing. For a social platform (ShareChat), think about feed generation, content moderation, and notification systems.
When you discuss database choices, don’t just say “use PostgreSQL” and move on. Explain why it fits their scale. Mention that managed RDS reduces operational overhead for a small team. Talk about what happens when they outgrow it and how you’d plan the migration. Startups value engineers who make decisions appropriate for their current stage, not engineers who parrot architectural patterns they read in a “System Design Interview” book.
Common questions you should prepare for: design a payment gateway with retry and idempotency handling; design a real-time notification system using WebSockets and push notifications; design a URL shortener (classic warmup); design a rate limiter for an API; design a background job scheduling system. For each of these, be ready to discuss monitoring, alerting, and failure handling. Startups care deeply about operational concerns because they don’t have a separate SRE team to bail them out.
Q: What exactly is a machine coding round, and why does it matter so much?
This is the round that separates startup candidates from service company candidates. It’s also the round most people under-prepare for because LeetCode doesn’t train you for it.
You get a problem statement. Something like: “Build a simplified Splitwise that lets users add expenses, split them among groups, and calculate who owes whom.” You have 60 to 90 minutes. You write code on your own machine or in an online IDE. It needs to work.
Other common problems: implementing an in-memory key-value store with TTL (time-to-live) support, designing a parking lot management system, building a task scheduler, or creating a simple ride-sharing fare calculator.
Here’s what they’re actually evaluating, in order of importance:
Code organization. Do you separate concerns? Do you use classes or modules in a way that makes sense? Or do you dump everything into one giant function?
Clean, readable code. Meaningful variable names. Consistent formatting. Small functions that do one thing. SOLID principles applied where they naturally fit (not shoehorned in to impress).
Edge case handling. What happens when the input is empty? What if someone tries to split an expense among zero people? Basic error handling instead of letting exceptions crash silently.
Extensibility. Can you add a new feature without rewriting half the codebase? This is where good interface design shines.
My advice: practice by setting a 90-minute timer and building small systems from scratch. Seriously, set a timer. Identify the core entities first. Define the interfaces between components. Implement the core logic. Handle edge cases if time allows. Websites like Workat.tech and CodeZinger have curated machine coding problems that Indian startups actually use. I’d recommend doing at least five to six of these before your interview.
Q: How should I handle the behavioral/culture fit round?
Don’t underestimate this round. I’ve seen strong coders get rejected here because they couldn’t articulate how they think or why they want to work at a startup.
Indian startup founders and hiring managers care about three things: ownership, communication, and comfort with ambiguity. They want developers who don’t wait to be told what to do, who communicate proactively, and who can function without a detailed spec for every feature.
Prepare stories using the STAR method (Situation, Task, Action, Result). You’ll need at least four or five good ones. Here are the questions that come up in almost every startup behavioral round.
“Tell me about a time you shipped something under a tight deadline.” Startups move fast. They need to know you can deliver under pressure without writing terrible code. Describe the specific situation, the constraints, the technical decisions you made to meet the deadline (what you cut, what you kept, why), and the outcome. Don’t just say “I worked extra hours.” That’s not the point. They want to hear about your judgment.
“Describe a disagreement with a teammate about a technical decision.” This tests collaboration. Show that you can argue for your position with technical reasoning, genuinely listen to the other perspective, and reach a resolution that’s best for the project. Avoid stories where you were just overruled and quietly complied. Also avoid stories where you steamrolled someone. Both are red flags.
“Why a startup instead of a bigger company?” Be genuine. Talk about wanting direct impact on the product, learning across the full stack, the pace of shipping, and growing with the company. But also mention something specific about their company. Read their tech blog. Try their product. Reference a specific feature or technical choice they’ve made. Generic answers get generic rejections.
“Tell me about a project you’re proud of.” Pick something where you had significant ownership. Walk through the problem, your approach, the challenges, and the result. Quantify the impact if you can — “reduced API latency by 40%” is more memorable than “improved performance.”
Q: What does a realistic two-week preparation plan look like?
Here’s what I’d do if I had two weeks before an interview at a company like Razorpay or CRED. This assumes you already have a decent foundation — if you’re starting from zero with DSA, you need more like two to three months.
Week 1:
Solve two DSA problems daily from company-tagged questions on LeetCode. If the company doesn’t have tagged questions, stick with the NeetCode 150 in order of topic. Do one system design problem every other day — sketch it on paper, talk through it out loud, time yourself to 35 minutes. Research the company’s product, tech blog, and engineering culture. Use their product. Read their engineering blog posts. Check their GitHub for open-source projects. Know what stack they use.
Week 2:
One machine coding practice session (90 minutes, timed) every other day. Prepare four to five behavioral stories using STAR. Do at least one mock interview with a friend or on platforms like Pramp or Interviewing.io. Revisit your weakest DSA topics. Review your system design notes. Get your development environment set up and comfortable — you don’t want to be fiddling with your IDE during a machine coding round.
Q: Let’s talk money. How much do Indian startups actually pay?
More than most people expect, especially at well-funded companies. For a developer with 3 to 5 years of experience, startups in Bangalore currently offer INR 18,00,000 to INR 35,00,000 total compensation depending on the company’s funding stage and your skill level. Early-stage startups tend toward the lower end but compensate more with ESOPs. Late-stage startups and those approaching IPO can match or exceed FAANG-India compensation.
Research before you negotiate. Platforms like Levels.fyi, AmbitionBox, and Glassdoor give you ballpark numbers, though they’re often slightly outdated. Talk to people who work there or recently left. The Indian tech community on Blind and certain Twitter/X circles is surprisingly open about compensation data.
A few things to watch out for with startup compensation. ESOPs sound exciting, but understand the details before you accept them. What’s the vesting schedule? (Standard is four years with a one-year cliff.) What’s the exercise price? What happens to your vested options if you leave? Is there a buyback policy, or are your shares locked until an IPO or acquisition that might never happen? I’ve seen developers take a significant cash pay cut for ESOPs at a startup that never went public. The ESOPs expired worthless.
Don’t undersell yourself. Indian developers have a tendency to accept the first offer because negotiation feels uncomfortable. Every startup expects negotiation. Counter with data: “Based on my research on Levels.fyi and conversations with engineers at similar-stage startups, the market rate for this role and experience level is X to Y. I’d like to discuss closing that gap.” Worst case, they say no and you still have the original offer.
Q: Any final tips that might actually make a difference?
A few things that seem minor but aren’t.
Speed matters in DSA rounds. Practice with a timer. If you can solve LeetCode mediums in 20 to 25 minutes consistently, you’re in good shape. If you need 45 minutes, you’re probably going to run out of time in an actual interview.
Communicate your thinking out loud during technical rounds. Interviewers can’t read your mind. Narrate your approach before writing code. Discuss tradeoffs. Mention alternatives you considered and why you rejected them. A candidate who talks through their process is always rated higher than one who silently codes, even if both arrive at the same solution.
Ask good questions at the end. “What does the engineering team look like?” is okay. “I noticed your tech blog mentioned migrating from a monolith to services — how far along is that, and which team would I be contributing to?” is much better. Good questions signal genuine interest and research.
Don’t fake enthusiasm for a company you haven’t researched. Startup hiring managers can smell it instantly. They’ve been pitched by hundreds of candidates who “love the product” but can’t describe what it does. Either genuinely learn about the company or be honest: “I’m drawn to the technical challenges at this stage, and I’d love to learn more about the product from the team’s perspective.” Honesty beats rehearsed flattery every time.
Approach each interview as a technical conversation between potential colleagues, not as an exam you need to pass. The best startup interviews feel like collaborative problem-solving. Ask clarifying questions. Propose alternatives. Push back respectfully if you think the interviewer’s suggestion has issues. That’s exactly the kind of interaction they want from someone they’ll work with daily.
Startups don’t hire resumes. They hire people who can think, build, and communicate — usually in that order.
