Interview experience
CRED Interview Questions and Answers (2026)
Overview
Section titled “Overview”CRED’s fresher loop is unusually design- and craft-heavy for an Indian fintech - alongside DSA and puzzles, it runs an extended machine-coding round and a system-design/managerial round that grade how cleanly and thoughtfully you build, not just whether the solution works.
CRED interview process at a glance
Section titled “CRED interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Take-home assignment | ~24 hours | A small working project, judged on completeness and code quality |
| DSA & Puzzles | 60-90 min | Coding problems + logical/puzzle reasoning |
| Machine Coding | Up to 2.5 hours | Build a working system - clean, extensible OOP design |
| System Design + Managerial | 60-90 min | Scalable design (often with a senior engineering leader) + behavioral fit |
| HR | 20-30 min | Offer, logistics, culture fit |
Take-home assignment
Section titled “Take-home assignment”A roughly 24-hour take-home project rather than a timed quiz - candidates build a small working feature or service on their own time. CRED evaluates the finished code for completeness, structure, and polish, not just whether requirements were met.
Common questions
- Build a small working service or feature end-to-end within the given spec
- Handle edge cases and error states without being explicitly told to
- Structure code so it’s easy to extend, not just easy to demo
DSA & Puzzles
Section titled “DSA & Puzzles”A shorter round mixing coding problems with logical/puzzle-style questions - tests problem-solving speed and reasoning rather than deep, obscure algorithms.
Common questions
- Array/string and data-structure problems at medium difficulty
- Logic puzzles that test structured reasoning under time pressure
- Follow-up questions on time/space complexity and edge cases
Machine Coding
Section titled “Machine Coding”CRED’s signature round - up to 2.5 hours building a working system from scratch (candidates report tasks in the credit-line and bill-payment domain). What’s graded is how clean, extensible, and well-structured the resulting classes and modules are, not just whether the code runs.
Common questions
- Design and build a working credit-line or bill-payment component with clean class boundaries
- Justify your choice of design patterns and why the code is extensible
- Handle a mid-round requirement change without a full rewrite
- Explain trade-offs between your design and a simpler, faster-to-ship alternative
System Design + Managerial
Section titled “System Design + Managerial”Often conducted with a senior engineering leader, this round covers scalable system design - typically scoped to credit lines, reward systems, or bill-payment flows - alongside behavioral and managerial-fit questions.
Common questions
- Design a scalable rewards or credit-line system - data model, consistency, failure modes
- Walk through your machine-coding round design and what you’d change at 10x scale
- A time you pushed back on a “good enough” solution because craft or design mattered
- How you’d prioritize between shipping fast and building it right
Round-by-round narratives are on the CRED interview experience page.
HR round
Section titled “HR round”A closing 20-30 minute conversation on offer logistics and culture fit. Concrete answers with a clear result outperform generic slogans here.
Common questions
- Tell me about yourself?
- Why CRED, and what do you know about the products?
- Walk me through a piece of code or system you’re proud of - what made it clean and worth the extra polish?
- What’s your joining timeline and compensation expectation?
Sample answer frameworks for each of these are on the CRED HR interview questions page.
Why CRED’s bar looks different
Section titled “Why CRED’s bar looks different”CRED has built one of the more design-conscious engineering cultures among Indian fintechs, and its interview process reflects that directly: an extended machine-coding round (up to 2.5 hours) and a dedicated system-design + managerial round together outweigh the DSA & Puzzles stage in most candidate reports. Interviewers are explicitly looking for engineers who “think about solving elegantly” - clean code, extensible architecture, and a defensible design rationale matter as much as a working solution. If your prep is pure LeetCode grinding without practice building and defending small systems end-to-end, CRED’s loop will feel like a different game than most fintech interviews.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: Machine coding - design a credit-line component with clean, extensible classes
Start by separating the domain from the mechanism. A CreditLine holds a limit, an available balance and a currency; a Drawdown and a Repayment are immutable events against it; and a CreditLineService applies events and enforces invariants in one place. Never let callers mutate the balance directly - expose intent-revealing operations like drawdown(amount) and repay(amount) that validate and either succeed or throw a domain-specific exception, because that is what stops an invalid state existing at all. For extensibility, put the interest and fee calculation behind a strategy interface so a new product is a new implementation rather than a new branch in an if-chain, and keep persistence behind a repository interface so the domain logic is testable without a database. Use integer minor units for money, and make every state transition explicit so a mid-round requirement change - say, adding a promotional zero-interest period - lands as one new class.
Q: Explain the SOLID principles and how they show up in a machine-coding round
Single Responsibility means a class has one reason to change - splitting a BillPayment that both computes a fee and writes to the database is the most common easy win. Open-Closed means new behaviour arrives by adding a class rather than editing an existing one, which in practice means a strategy or a polymorphic handler instead of a growing switch statement. Liskov Substitution means any subclass must be usable wherever its parent is, so a subclass that throws on an inherited method has broken the hierarchy. Interface Segregation means many small interfaces beat one fat one, so a read-only consumer does not depend on write methods. Dependency Inversion means depending on abstractions - passing a NotificationSender interface into the constructor rather than instantiating an SmsSender inside, which is also what makes the class unit-testable. CRED’s round grades exactly this: an interviewer adding a requirement mid-round is testing Open-Closed directly.
Q: Which design patterns are worth reaching for, and when are they overkill?
Strategy is the highest-value pattern in a machine-coding round: interchangeable algorithms behind one interface, such as differing reward-accrual rules per card tier. Factory centralises object creation when the concrete type depends on input, keeping the switch in exactly one place. Observer decouples a state change from its side effects, so a successful payment publishes an event that notification and analytics subscribe to independently. Builder tames constructors with many optional parameters, and Repository hides persistence behind an interface. The overkill signal is a pattern that adds indirection without a second implementation ever appearing - a Singleton in particular is usually a global variable in disguise, hurting testability, and interviewers will ask you to justify it. Name the pattern, name the change it makes cheap, and if you cannot name that change, do not use it.
Q: Design a scalable rewards system
Model rewards as an append-only ledger of accrual and redemption events rather than a mutable points balance, so the balance is a fold over events and every dispute is auditable. Make the write path asynchronous: a payment publishes an event to a durable log, a rules engine evaluates accrual policies, and a consumer writes the earned points, with a materialised balance kept for fast reads. Redemption is the part that must be strongly consistent - use a conditional update or a database transaction so two concurrent redemptions cannot both pass a balance check and overdraw, which is the classic lost-update bug. Make every consumer idempotent on the event id, because at-least-once delivery means duplicates are normal and a replay must not double-credit. Expiry is best handled as a scheduled job writing explicit expiry events rather than a timestamp filter at read time, so the ledger stays the single source of truth.
Q: How do you make a bill-payment flow correct when a downstream call times out?
A timeout is genuinely ambiguous - the payment may have succeeded, failed, or still be in flight - so never retry blindly. Give every payment attempt a client-generated idempotency key that the provider honours, so a retry either returns the original result or is rejected as a duplicate. Model the payment as a state machine with an explicit PENDING state, return that to the user rather than guessing, and run a reconciliation job that queries the provider’s status API to settle pending records. Add a circuit breaker so repeated failures fail fast instead of queuing threads, and use exponential backoff with jitter on retries so every client does not retry in lockstep. Where a multi-step flow must be undone, use a saga with compensating transactions rather than a distributed two-phase commit, which does not survive a coordinator failure.
Q: Design an LRU cache
Combine a hash map with a doubly linked list. The map gives O(1) lookup from key to node, and the list maintains recency with the most recently used at the head and the least recently used at the tail. On get, find the node through the map and move it to the head. On put, insert at the head, and if the capacity is exceeded, evict the tail node and delete its key from the map. Both operations are O(1) because a doubly linked list lets you unlink a node without traversing to find its predecessor - which is exactly why a singly linked list fails here. The follow-up is thread safety: a global lock serialises everything, so real caches shard the structure by key hash, and Java’s LinkedHashMap with accessOrder true gives the same behaviour out of the box.
Q: Find the longest substring with at most K distinct characters
Use a variable-size sliding window with a hash map counting character frequencies inside the window. Expand the right pointer, incrementing the count for each new character; while the map holds more than K distinct keys, advance the left pointer, decrementing counts and removing a key when its count reaches zero. Record the maximum window length after each shrink. Each pointer moves forward at most n times, so it is O(n) time and O(K) space. The edge cases interviewers check are K equal to zero, which must return zero, and a string shorter than K, which returns the whole string - and the common bug is forgetting to erase a key at count zero, which silently inflates the distinct count.
Q: A logic puzzle - you have 8 identical-looking coins, one heavier. Find it in two weighings
Split into groups of 3, 3 and 2. Weigh the two groups of 3 against each other. If they balance, the heavy coin is in the remaining pair, and one more weighing of those two identifies it. If one group of 3 is heavier, take that group, weigh any two of its coins against each other, and either one tips - that is the coin - or they balance, leaving the third. The generalisation is the answer interviewers actually want: each weighing has three outcomes, so k weighings distinguish at most 3 to the power k cases, meaning two weighings cover up to 9 coins and three cover 27. Stating that information-theoretic bound before you construct the split shows the structured reasoning the round is scoring.
Frequently asked questions about CRED interviews
Section titled “Frequently asked questions about CRED interviews”What is the CRED interview process for freshers?
CRED’s process typically runs 4-5 stages: 1. A take-home assignment (roughly 24 hours) - a small working project rather than a quiz. 2. DSA & Puzzles round (60-90 min) - coding problems plus logic puzzles. 3. Machine Coding round (up to 2.5 hours) - build a working system from scratch with clean, extensible object-oriented design. 4. System Design + Managerial round (60-90 min), often with a senior engineering leader - covers scalable design plus behavioral fit. 5. HR round (20-30 min) - offer and logistics. Total duration is typically 2-4 weeks.
What questions are asked in CRED interviews?
CRED interviews cover DSA and logic puzzles, but weight machine coding and system design heavily - candidates are commonly asked to design and build something like a credit-line or bill-payment component with clean, extensible classes rather than just get it working. Domain discussions probe credit lines, reward systems, and bill-payment flows in plain language. Managerial/system-design rounds go deep on why you made specific design choices, not just what the design was.
How many rounds are there in the CRED interview?
CRED typically runs 4-5 stages: a take-home assignment, a DSA & Puzzles round, a Machine Coding round, a System Design + Managerial round (frequently with the Head of Engineering or a senior lead), and a closing HR round. Some drives compress or skip the take-home depending on role and college - confirm with your placement cell or recruiter.
What is the CRED technical interview like?
The Machine Coding round (up to 2.5 hours) is CRED’s signature stage - you build a working component from scratch and are judged on how clean, extensible, and well-structured your code is, not just whether it runs. The System Design + Managerial round that follows often includes a senior engineering leader and probes both scalable design (for a credit-line, rewards, or payments-style system) and the reasoning behind your design choices. DSA & Puzzles rounds are shorter and test problem-solving speed plus logical reasoning rather than deep algorithms.
How should I prepare for CRED interviews?
Practice building small systems end-to-end with clean, extensible object-oriented design - CRED’s machine-coding bar is explicitly about code quality and craft, not just a working main(). Revise core DSA and be ready for logic puzzles alongside coding problems. For system design, think in terms of credit-line, rewards, or bill-payment domains rather than generic templates, and be ready to justify every design decision out loud. Prepare one detailed project story and concrete HR answers using STAR.
What mistakes do candidates commonly make in CRED interviews?
Treating the machine-coding round as a race to a working solution instead of a design exercise - CRED interviewers explicitly reward clean, extensible architecture over speed. Other common misses: reaching for system-design jargon without a simple, defensible bottleneck story, and not having a crisp answer for why a specific class or module was structured the way it was. A polished, well-reasoned design consistently beats a fast but messy one.