He got the optimal solution. Sorting, then a two-pointer sweep, O(n log n), clean. The interviewer said "nice" and then asked him to design the class structure for a rewards engine where the rules change weekly, marketing wants to add a rule type without a deploy, and two rules can apply to the same transaction with a defined precedence. He had prepared four hundred LeetCode problems. He had never once written an interface.
CRED backend interview questions are a two-part exam and most candidates prepare only for part one. The algorithm bar is genuinely among the highest of any Indian product company — mediums and hards, with optimality expected rather than praised — and then the loop swings into low-level design, where you are judged on classes, interfaces and whether your design survives a requirement change. Add a culture round that actually rejects people and you have a loop that is harder than its headcount suggests. I built Greenroom after freezing in an interview I had prepared hard for, so this guide covers all three halves.
The CRED backend engineer interview process
- Recruiter screen — level calibration and which pod: payments, rewards, lending, or a platform team.
- DSA rounds — one or two, at LeetCode medium-to-hard. Optimal complexity is the expectation, not the bonus.
- Low-level design round — design the classes for a system, extend it live, and defend your abstractions.
- High-level system design — event-driven flows, idempotency, consistency over money.
- Culture round — craft, ownership and taste. This one rejects people; treat it as technical.
Our CRED interview questions guide covers the company-wide process and the CRED Android engineer guide covers the client side.
The DSA rounds
Expect medium-to-hard: heaps and top-K, graphs including topological sort and shortest path, dynamic programming beyond the standard set, tries, intervals, binary search on the answer, and sliding window with awkward constraints.
Two CRED-specific habits. First, they want the optimal solution and they will keep pushing until you reach it or exhaust the ideas — a working brute force gets acknowledged and then immediately challenged. Second, they expect you to state complexity precisely and to be right about it, including space.
The practical preparation is volume at the right difficulty: mediums until they are boring, then hards in the common categories. Our DSA coding interview preparation guide covers the list and recursion and backtracking questions covers a category CRED asks more than most.
The low-level design round
This is the round that separates CRED from most Indian product interviews, and the one candidates skip in preparation.
Typical prompts: design a rewards engine, a rate limiter as a class library, a notification dispatcher with multiple channels, a parking lot or a splitwise clone, a coupon system with stacking rules, or an offer engine where rules change weekly.
What is graded:
- Interfaces before implementations. Name the abstraction, define the contract, then implement. A strategy interface for rule types is often the whole answer.
- Extensibility under a live change. Halfway through they will add a requirement — a new rule type, a new channel, a precedence conflict. If you have to rewrite, you designed too concretely.
- Correct use of a few patterns. Strategy, factory, observer, chain of responsibility, builder. Use them where they fit and say why; do not recite the catalogue. Our design patterns interview questions guide covers the ones that recur.
- Separation of concerns. Rule evaluation separate from rule storage separate from the transport that applies the result.
- Thread safety and idempotency, where money is involved.
- Testability. How you would unit test a rule without standing up the whole engine. Raising this unprompted lands well.
# a rewards engine that survives "add a new rule type" mid-interview
from abc import ABC, abstractmethod
class Rule(ABC):
priority = 0
@abstractmethod
def applies(self, txn) -> bool: ...
@abstractmethod
def reward(self, txn) -> int: ...
class CategoryCashback(Rule):
priority = 10
def __init__(self, category, percent):
self.category, self.percent = category, percent
def applies(self, txn): return txn.category == self.category
def reward(self, txn): return txn.amount * self.percent // 100
class Engine:
def __init__(self, rules): self.rules = sorted(rules, key=lambda r: -r.priority)
def evaluate(self, txn):
# precedence is explicit, and adding a rule type never touches this method
return [(r, r.reward(txn)) for r in self.rules if r.applies(txn)]Then say the sentence: "adding a rule type is a new class and a registration — Engine never changes. That is the property I was designing for." That is the whole round in one line.
The system design round
Prompts are fintech-shaped: a rewards ledger, a payment reconciliation pipeline, a credit-card bill reminder system, a referral programme, or a notification platform.
- Numbers first. Users, transactions per day, peak concurrency around bill due dates, retention requirements.
- Event-driven flows. CRED's architecture leans on events; be fluent in producers, consumers, ordering guarantees you do and do not get, consumer lag and what happens when a consumer falls behind. Our event-driven architecture questions guide covers the vocabulary.
- Exactly-once is a lie. At-least-once delivery plus idempotent consumers is the correct answer, and saying it precisely is a strong signal.
- Ledger correctness. Append-only records, double-entry thinking, and reconciliation when your ledger disagrees with a bank's.
- Consistency per feature. A reward balance shown in the app can lag by seconds; a redemption cannot double-spend.
- Failure isolation. Timeouts, circuit breakers, and what the app shows when the rewards service is down.
- Observability. What you alert on, and how you detect a silent correctness bug rather than an outage.
The culture round
CRED interviews for craft and taste in a way most companies do not, and this round genuinely produces rejections.
What it probes: something you built that you are proud of and precisely why, a time you pushed back on a requirement, what you consider good code, a product you admire and what you would change about it, and how you decide when something is finished.
What fails: generic answers about impact and scale, describing a project without a single opinion in it, and having no view on quality. What works: specificity, a genuine opinion held for a reason, and honesty about a tradeoff you knowingly accepted.
Where each prep option actually helps
- LeetCode — mediums to fluency, then hards in graphs, DP and heaps. Higher volume than most Indian product loops require.
- Low-level design practice — the highest-yield gap for most candidates. Design a parking lot, a splitwise, a rate limiter and a rewards engine in code, then have someone add a requirement halfway.
- Head First Design Patterns or Refactoring Guru — enough to use five patterns correctly and know when not to.
- Designing Data-Intensive Applications — for the event-driven and consistency vocabulary in the system design round.
- ChatGPT — genuinely useful for generating a mid-interview requirement change to test your design against. It will not judge whether your abstraction was the right one.
- Greenroom — the spoken layer. Ari, the AI interviewer runs the design and culture rounds out loud and pushes on your opinions, which is exactly what the culture round does. Honest tradeoff: Ari will not compile your code, so pair it with real design practice.
How to prepare for the CRED backend interview
- Weeks 1-2 — LeetCode mediums to fluency, then hards. Complexity stated precisely, every time.
- Week 3 — four low-level designs written as real code, each followed by a requirement change you did not plan for.
- Week 4 — design a rewards ledger, a reconciliation pipeline and a notification platform out loud, with idempotency and consumer lag in each.
- Final week — the culture round: write down what you think good code is, one thing you are proud of and why, and one requirement you pushed back on. Say all three out loud until they have opinions in them.
Interviewing across comparable loops? The Razorpay backend engineer guide covers similar payments correctness, the PhonePe backend engineer guide covers UPI-scale systems, and the Flipkart backend engineer guide covers the machine coding variant of the design round.
Frequently asked questions
What is the CRED backend engineer interview process?
Candidates report a recruiter screen, one or two DSA rounds at LeetCode medium-to-hard where optimal complexity is expected rather than praised, a low-level design round where you write class structures and extend them live, a high-level system design round covering event-driven flows and correctness over money, and a culture round on craft and ownership that genuinely produces rejections.
How hard is the CRED DSA round?
It is among the highest algorithm bars of any Indian product company. Expect medium-to-hard problems across heaps and top-K, graphs including topological sort and shortest path, dynamic programming beyond the standard set, tries, intervals, binary search on the answer, and sliding window with awkward constraints. A working brute force is acknowledged and then immediately challenged, and you are expected to state both time and space complexity precisely and correctly.
What is asked in CRED's low-level design round?
Prompts include a rewards engine, a rate limiter as a class library, a notification dispatcher with multiple channels, a coupon system with stacking rules, or a splitwise clone. You are graded on defining interfaces before implementations, on whether your design survives a requirement added halfway through the round, on using a small number of patterns correctly rather than reciting a catalogue, on separating rule evaluation from storage and transport, and on how you would unit test a component in isolation.
What system design questions does CRED ask?
Prompts are fintech-shaped: a rewards ledger, a payment reconciliation pipeline, a bill reminder system, a referral programme or a notification platform. Strong answers begin with numbers including peak concurrency around bill due dates, then cover event-driven producers and consumers with realistic ordering guarantees, at-least-once delivery with idempotent consumers rather than claimed exactly-once, append-only ledger records and reconciliation with a bank, per-feature consistency, failure isolation, and how you detect a silent correctness bug rather than an outage.
What is the CRED culture round and how do you prepare?
It is a round on craft, ownership and taste that genuinely rejects candidates. It probes something you built and precisely why you are proud of it, a time you pushed back on a requirement, what you consider good code, a product you admire and what you would change, and how you decide something is finished. Generic answers about impact and scale fail; specificity and a genuine opinion held for a stated reason are what pass, so prepare it like a technical round rather than as a formality.
Is CRED harder to get into than other Indian product companies?
The loop is harder than the company's size suggests, mainly because it stacks two different exams. The algorithm bar is comparable to or above most Indian product companies, and it is followed by a low-level design round that grinding LeetCode does not prepare you for at all, plus a culture round that filters on whether you can articulate a view about quality.