Interview experience
CRED interview experiences covering Take-home assignment, DSA & Puzzles, Machine Coding, System Design + Managerial, +1 more. Round-wise notes, common questions, and what candidates report clears each stage.
CRED Interview Questions and Answers (2026)
CRED is a fintech startup that rewards users for paying credit card bills on time. Founded in 2018, CRED has built a premium credit card management platform with millions of users. The company focuses on building trust through technology and has a strong engineering team working on payments, gamification, and user experience.
Explore: Interview experience · HR interview questions · Overview · Placement papers · Preparation guide
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.
HR interview questions
CRED HR interview questions with sample answer frameworks - motivation, relocation, STAR stories, and culture-fit prompts.
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 |
CRED online assessment and take-home: quick answers
These answers are compiled from public candidate reports and prep guides, not from an official notice, and drives differ. The instructions in your own invite are the final word.
| Question | Answer |
|---|---|
| Is the first round an OA or a take-home? | It depends on the role. Many SDE loops (including mobile) start with a take-home assignment due within about 24 hours; some fresher roles, such as automation engineer, start with a proctored HackerRank coding test instead. |
| How many questions and how long? | The reported HackerRank OA had 3 DSA coding problems in 105 minutes. The take-home is one small working project, usually due within 24 hours. |
| Does it have negative marking? | No. Reported CRED tests are coding problems scored on test cases, with no MCQ section to penalise. |
| Is there a sectional cutoff? | No. There are no aptitude or MCQ sections in reported CRED first rounds. |
| How much is the cutoff? | Not published. Take-homes are judged on completeness, structure and code quality rather than a score, and CRED does not publish CGPA rules. |
| Which platform is it on? | HackerRank for the proctored OA (GfG automation-engineer report, updated July 2025) and for some machine-coding rounds; a 2021 LeetCode backend report describes a 2.5-hour machine-coding window on HackerRank. |
| Which topics come up in the OA? | Grid connectivity with add and count queries (union-find style), the minimum character substitutions so no two adjacent characters match, and similar medium-hard DSA. |
| Is there a puzzle round? | Yes, usually. The DSA & Puzzles round (about 1.5 hours) is often run in Google Docs rather than an IDE, so explaining your approach matters. |
CRED interview questions by role
These themes come from candidate reports on GfG and the public reports summarised below. They show the level and style, not a fixed list.
| Role | Reported questions and topics |
|---|---|
| Backend SDE | Machine coding a credit-line or bill-payment component, a thread-safe multi-floor parking lot, a payment-method ranking service, a key-value or LRU cache; then design a scalable rewards system. A December 2025 LeetCode SDE-1 report: extend a given boilerplate codebase to compute latency, throughput and error rate over a timestamp range, with p90 latency as a follow-up. The 2021 LeetCode backend report asked for an in-memory database with primary and secondary indexes, and GfG’s 2026 CRED topic list adds a time-based key-value store and an idempotent payment processor. |
| Android / mobile SDE | Take-home: an animation-heavy proof of concept in native Android with Clean Architecture, API calls and view persistence. Then Android lifecycle and Clean Architecture in depth, an app HLD that grows in complexity, and a mobile system design round (design an analytics SDK) with the head of mobile engineering. |
| Automation engineer (fresher) | Proctored HackerRank OA with 3 coding problems in 105 minutes (grid connectivity queries, adjacent-character substitutions). |
| Software developer (general) | An online coding screen, a telephonic round on harder coding plus design patterns and engineering principles, a system design scenario from CRED’s domain, and a culture-fit call. |
Asked across every role: medium DSA explained without an IDE, logic puzzles, why CRED and what you know about its products, and a piece of work you are proud of because of its craft.
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
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
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.
Public reports also cite multi-floor parking lot allocation (thread-safe), payment-method ranking services, flight-booking backends, Snake & Ladder with constraints, and key-value / LRU caches on HackerRank project modules with dozens of hidden tests.
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
- Discuss concurrency, idempotency keys, and unit tests when the prompt touches payments or inventory-style state
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
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
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.
CRED backend vs mobile vs automation loops
CRED’s loop changes with the role, so check which one your invite is for before you prepare.
Backend SDE loops centre on machine coding (up to 2.5 hours) and payments system design. Mobile (Android/iOS) SDE loops swap backend machine coding for a long core-platform round - lifecycle, Clean Architecture, app HLD - and end with mobile system design. Automation engineer fresher loops start with a proctored HackerRank DSA test rather than a take-home.
The DSA & Puzzles round and the culture-fit conversation are common to all three. This page mainly covers the backend SDE loop.
Common question clusters (with frameworks)
Guvi and Medium posts stress machine coding and fintech LLD more than pure LeetCode identity.
1. Take-home or OA when present
Framework: Clean, tested code over clever one-liners. Read the full spec before coding.
2. DSA that maps to payments
Framework: LRU, rate limiter, sliding windows, merge intervals. State complexity and failure modes.
3. Machine coding / LLD
Framework: Payment package, key-value cache, reward flows: modular design, errors, tests. Scope cut to a working core.
4. Fintech system sense + culture
Framework: Idempotency, retries, ledger consistency in plain words. Why CRED beyond brand memes.
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
Does CRED have an online assessment or a take-home?
It depends on the role. Many SDE loops, including mobile, start with a take-home project due within about 24 hours; some fresher roles such as automation engineer start with a proctored HackerRank test of 3 DSA problems in 105 minutes.
Does the CRED online test have negative marking?
No. Reported CRED tests are coding problems scored on hidden test cases, with no MCQ section, so there is nothing to penalise. Take-homes are judged on completeness, structure and code quality rather than a score.
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?
Usually 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?
The biggest one is 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.
Is CRED’s machine coding round the hardest stage?
Yes, in most candidate write-ups: timed implementation with design quality, error handling, and tests. Practise building a small payments or cache package end to end.
Does CRED ask system design for freshers?
Sometimes - managerial or senior-leaning loops may include fintech design (bills, rewards, ledgers). Focus on APIs, consistency, and failure retries rather than buzzword diagrams.
How to prepare for CRED interviews
- Loop map: Take-home assignment; DSA & Puzzles; Machine Coding; System Design + Managerial. Confirm timings from the drive mail.
- Technical depth: Drill the Q&A section until answers are spoken, not read. Know every resume project cold.
- Experiences: Study round-wise notes on the interview experience page - real prompts beat generic lists.
- HR: Three STAR stories + a specific “Why CRED?” on the HR page.
Who usually fits and who struggles
Good fit: You enjoy medium-hard LeetCode-style problems, can talk about idempotent APIs and failure retries without jargon soup, and have one project you can defend for 20 minutes. Comfort with Bengaluru relocation helps.
Harder path: You only practiced aptitude MCQs; you skip system design because “freshers don’t get design”; you cannot explain your own project’s data model. CRED’s OA clear rate is often cited around the mid-teens to ~20% - guessing through edge cases fails quietly.
A practical CRED prep plan
Use this as a default four-week loop before a CRED drive. Adjust to your invite timeline.
- Week 1: Timed aptitude + one easy coding problem a day, plus a one-page cs fundamentals sheet. Open the CRED previous-year sets on this site and mark which sections ate your time. Write the timing on a sticky note. That number is more useful than a 200-problem LeetCode streak you never timed.
- Week 2: Most CRED drives fail people on the first timed paper or OA. Do three timed sits this week. After each one, log every miss in a two-column note: topic and why (slow, wrong formula, bad edge case, panic). The next sit should only add problems from that log.
- Week 3: Technical interviews at CRED usually want a clean project story, one or two CS fundamentals, and (if the process has it) a behavioral or values round. Write STAR stories on paper, not in your head. Practise “Why CRED?” with one concrete product, lab, or business line - not a slogan.
- Week 4: Two full mocks, then only error-log topics - no new patterns. If you still have energy, redo only the questions you failed in week 2.
10-day crash version: Days 1-4 timed DSA, days 5-7 resume projects + CS fundamentals, days 8-9 mock interviews out loud, day 10 HR STAR stories on the HR page.
Compensation notes
Candidate-reported fresher/early-career packages for CRED often cite ₹18-25 LPA for Software Engineer freshers, up to ₹35 LPA for senior roles. Treat forum numbers as ranges, not guarantees - confirm the written offer letter for your team and location.
Sources
Interview process details and sample questions on this site are editorially organized from public candidate reports and hiring write-ups, with round structure, prep notes, and company-specific framing added by our team. For round-by-round stories, see the CRED interview experience page. For OA papers and coding drills, use CRED on placementpapers.app. OA quick answers and role-wise questions draw on GfG’s CRED interview experiences (SDE, software developer, automation engineer online coding round updated July 2025), GfG’s CRED interview-topics list (updated August 2026), and LeetCode Discuss reports from a 2021 backend loop and a December 2025 SDE-1 loop (read via search snippets).