Razorpay vs CRED Software Engineer Interview: Two Fintechs, One Big Difference

You studied sliding window. You practiced LLD. You can implement an LRU cache in your sleep. Then you show up to the CRED machine coding round and they give you two and a half hours, expect you to build something "architecturally sound," and grade you down for submitting working-but-messy code.

That is the trap. Both companies look identical on a job board. Both are high-bar Indian fintechs. Both will ask you to design payment systems and write clean low-level design. Prep for one the way you'd prep for the other and you'll walk out genuinely confused about where you went wrong.

Here is what actually differs, and how to prepare for each one without accidentally building the wrong mental model.

The Companies

Razorpay is India's largest payments infrastructure company, processing hundreds of billions in transactions annually. Its engineering problems are payment-routing problems: distributed systems, consistency under failure, sub-100ms latency at scale. Go is the primary backend language.

CRED is a fintech platform built around creditworthiness, rewards, and financial products for high-trust users. The engineering problems lean toward correctness: idempotency, deduplication, schema design, and making sure a payment that looks like it failed actually did not. The team is deliberately small and selective.

Both are genuinely hard to hire into. The bar they're testing against is just different.

Razorpay vs CRED Interview Rounds, Side by Side

Stage	Razorpay	CRED
Initial screen	Online assessment or recruiter call	Recruiter call
Take-home	None	24-hour assignment
DSA round	Yes (45-90 min)	Yes (90 min, sometimes in Google Docs)
Machine coding	Yes (90 min, full running code)	Yes (2.5 hours, emphasis on design)
System design	HLD round (60-90 min)	Included in final round
Hiring manager	Yes (separate round)	Yes (combined with system design, with Head of Engineering)
Total rounds	4-5	4
Avg. timeline	~16 days	2-3 weeks

Software engineer interview vs regular people interview rake meme

The regular job application has one rake. The software engineering version has dedicated rakes for each of your four to five rounds.

Razorpay: Every Round Decoded

The Online Assessment

Not always present. Candidates with referrals or direct sourcing sometimes skip it. When it appears: 90 minutes, 2-3 problems, arrays, graphs, dynamic programming, tree traversals. Standard LeetCode medium-hard. Nothing exotic.

DSA Round

A single technical interview, 45-90 minutes. Expect two problems, both medium-hard difficulty. The interviewer is watching how you communicate your approach, not just whether you arrive at the answer. Narrate your reasoning from the start, state constraints you are assuming, and walk through a concrete example before touching code.

Common topics: sliding window, graph BFS/DFS, DP with 1D/2D state, binary search on answer. Razorpay interviewers frequently add follow-up constraints after the first solution. Be ready to discuss how your approach changes if the input is a stream, or if memory is bounded.

Machine Coding Round (The One That Trips People)

This is 90 minutes, and you are expected to submit fully working, runnable code. Not pseudocode. Not a skeleton with TODO comments everywhere. Running code.

You use your own local IDE. Recent problems include:

In-memory Splitwise: expense sharing with group management, settle-up calculations
Logger system: route logs to different destinations based on type, with proper abstraction layers
In-memory search engine: indexing blog posts, keyword lookups, relevance scoring

The evaluators look for clean class design and separation of concerns. If you hardcode the settlement algorithm into a main function, you fail regardless of correctness. If your classes are well-named, the logic is obvious, and the code handles basic edge cases, you pass even with a minor bug.

Pingu shocked meme: "Yo lets just compile this 2000 line code I just wrote" then "Runs Without Errors & Warnings First Time"

That moment at minute 88 when your Splitwise implementation actually runs.

HLD Round

System design, 60-90 minutes. Expect a payments-adjacent problem. Past candidates report topics like designing a subscriptions platform, a notification service for payment events, or delivery-plus-payment orchestration.

Razorpay engineers care deeply about what happens when things fail. Idempotency, retries with backoff, event sourcing, and consistency tradeoffs between your database and payment gateway state will all come up. Go deep on one or two components rather than drawing 15 boxes with no substance.

Hiring Manager Round

Behavioral, 45-60 minutes. Past projects, technical decisions you owned, how you handled disagreement. Have three to four concrete stories with outcomes. Know the Razorpay product well enough to talk about what problems interest you there.

CRED: Every Round Decoded

Take-Home Assignment (24 Hours)

This is the round that makes CRED's process unusual. You receive a problem statement and 24 hours to submit a working solution with tests and a README. Recent assignments have involved building small backend systems: a simplified payment processor, a rule engine, a feature-flag system.

The 24-hour window is not a license to over-engineer. Every developer's first instinct here is to spin up microservices, reach for Kafka, and write a fifteen-page design doc. CRED evaluators are reading your judgment. A clean, modular solution that solves the spec is better than a microservices architecture that solves everything except the spec. Write tests. Document your tradeoffs. Explain what you would do differently with more time.

Hiring manager interview meme: "take home test that should only take a few hours" vs candidate internally computing hours of debugging ahead

"Just a few hours" said no developer who has ever touched a payment processor implementation.

DSA Round (90 Minutes, Sometimes in Google Docs)

This catches people off guard. CRED sometimes conducts DSA rounds in Google Docs. No autocomplete. No syntax highlighting. No compiler to catch typos.

This is intentional. They want to see how you think and communicate when the tools abandon you. Write clearly, narrate constantly, and do not panic if you forget exact syntax. The strategy of relying on your IDE to catch mistakes will not save you here. Expect 2-3 medium-difficulty problems. Topics: hash maps, heaps, sliding window, graphs, sorting-based approaches. Nothing esoteric, but the fundamentals need to be clean.

Practicing in Google Docs before CRED stings less than discovering mid-interview that you cannot remember the syntax for a HashMap. Open a blank doc right now and implement binary search without autocomplete. See how quickly "autocomplete crutch" becomes "oh no."

Machine Coding Round (2.5 Hours, Architecture Over Speed)

This is where CRED separates the field. Two and a half hours is a long time. They expect you to use it to build something good, not just something fast.

Recent problems:

Distributed key-value store: thread-safe, eviction policies, TTL support
LRU cache with dynamic capacity or concurrent access constraints
Snake and Ladder game engine with extensible rule system
Payment processor with idempotency guarantees

CRED evaluators want SOLID principles visible in the class design, clear separation between domain logic and infrastructure, tests that cover failure modes, and naming that communicates intent. A working-but-messy solution loses to a nearly-working but well-designed solution. This is not how every company evaluates machine coding, and it will feel backwards if you haven't adjusted your prep.

System Design and Managerial Round (90 Minutes, Head of Engineering)

The final round combines HLD with a hiring manager conversation, often with the Head of Engineering for the relevant area.

The system design portion is fintech-specific: schema design for financial records, handling a double-charge scenario, ensuring a refund is processed exactly once, expiring points in a rewards system. The concepts to internalize: idempotency, at-least-once delivery with deduplication, audit trails.

The managerial portion probes how you operate. CRED values strong opinions, high craft, and low ego. Bring concrete examples of disagreeing clearly and then committing. If your only mode is "I agree with whatever the team decides," that reads as low craft. If your only mode is "I was right and they were wrong," that reads as high ego. The sweet spot is uncomfortably narrow.

The Real Differences

1. Take-home vs no take-home. CRED's assignment round changes the pacing of the entire process. You get time to show judgment, not just reflexes. Razorpay has no equivalent.

2. Running code vs clean architecture. Razorpay's machine coding round explicitly wants runnable software. CRED's 2.5-hour round cares more about how your code is structured than whether it compiles on the first try.

3. DSA depth. Razorpay places heavier emphasis on DSA across multiple rounds. CRED tests it but does not make it the primary signal. If strong algorithms are your edge, that tilts toward Razorpay. If clean software design is your edge, that tilts toward CRED.

4. Domain knowledge. Both reward knowing fintech. CRED's system design goes deeper into financial correctness (idempotency, consistency, audit trails). Razorpay's focuses more on scalability and distributed systems architecture.

5. Difficulty by the numbers. Glassdoor difficulty ratings: Razorpay 2.91/5, CRED 3.06/5. CRED also reports only 43.8% of candidates having a positive experience. The bar is real, and more than half the candidates walking out did not enjoy the trip.

Prep Strategy

For Razorpay:

Solve 40-50 LeetCode medium-hard problems across graphs, DP, binary search, and trees.
Practice machine coding with a timer. Build 2-3 projects from scratch (Splitwise-style, a logger, a simple ORM) and get them to runnable state. Not nearly-runnable. Runnable.
Study how payment systems fail. Know what a circuit breaker is and when to use one.
For HLD, practice drawing payment flows end to end, with all the failure states. Every arrow in your diagram is a failure point waiting to happen.

For CRED:

Nail your SOLID principles. Not the acronym on a flashcard. Refactor real code until it exemplifies each one. Your instincts need to be there at the 2-hour mark, not just in theory.
Practice take-home assignments. Build a small backend system in 4-6 hours, then review it as if you were the interviewer. Be ruthless about over-engineering.
Study idempotency patterns: idempotency keys, at-least-once with deduplication, distributed locks. Financial correctness is not optional here.
For DSA in Google Docs, practice writing code in a plain text editor. The loss of autocomplete stings more than you expect. Every developer thinks they can handle it until they can't remember if HashMap or Hashmap is the right capitalization.

For both:

Running realistic mock interviews out loud is the fastest way to close the gap between "I know how to solve this" and "I can explain my approach in real time under pressure." SpaceComplexity runs voice-based DSA mock interviews with rubric-based feedback on exactly the dimensions both companies score: communication, problem-solving, code quality, and systems thinking.

Prep Timeline

Experience	Razorpay	CRED
SDE-1, strong DSA	3-4 weeks	4-5 weeks
SDE-2, rusty LLD	4-6 weeks	5-7 weeks
After a gap	8-10 weeks	10-12 weeks

CRED takes longer because the machine coding and take-home bars require more deliberate practice than LeetCode grinding alone. You are not just practicing solving problems. You are practicing solving problems elegantly, under time pressure, with someone watching.