Skip to content
Interview Questions

CRED Interview Experience 2026

How CRED fresher interviews usually run, campus and off-campus. Patterns shift by year and role, so treat this as a prep map, not a script.

CRED placement process includes: 1. Online Assessment (OA) - 90 minutes with 2-3 medium to hard coding problems, 2. Technical Interview Round 1 - 45 minutes focusing on data structures and algorithms, 3. Technical Interview Round 2 - 45 minutes covering system design for FinTech systems, 4. Managerial Round - 45 minutes with behavioral questions and technical discussions, 5. HR Round - 30 minutes for general discussion. Total duration: 2-3 weeks from application to offer.

Eligibility (from student reports): 7.0+ CGPA in 10th, 12th, and graduation.

Fresher package ballpark (from student reports): ₹18-25 LPA. Confirm on your offer letter.

Round-wise process

Round Duration What they test
Online Assessment 90 min Coding (DSA) + sometimes MCQs
Technical Round 1 45-60 min DSA + backend / payments concepts
Technical Round 2 45-60 min System design (payments / ledger)
HR / Culture 20-30 min Motivation, integrity, relocation

Real interview experiences

Experience 1: SDE (Android), fresher with heavy internship background

Published GeeksforGeeks write-up. The candidate was a recent graduate but had roughly two years of Android and backend internships, including one at a unicorn startup.

Round 1: take-home assignment (24-hour window)

  • Build a proof of concept for an animation-heavy feature in native Android, following Clean Architecture properly - including API handling and view-state persistence.

Round 2: DSA and puzzles (~1.5 hours)

  • Medium-difficulty data-structure problems, plus puzzles.
  • Notably, code was written in a Google Doc, not an IDE. Nothing compiles or runs, so the explanation of your approach is being assessed as much as the code.

Round 3: core domain depth (~2.5 hours)

  • Started at basics (lifecycle questions) and escalated into Clean Architecture in detail.
  • Design the app’s high-level architecture, with the interviewer progressively adding complexity to the requirements.

Round 4: system design + managerial (~1.5 hours, with the Head of Engineering)

  • Design an analytics SDK.
  • Cultural fit and career goals.

Result: Selected - HR confirmed the same day as the final round.

What the candidate highlights: the loop tested development skill rather than grinding DSA, and most rounds had two interviewers, which made them feel like discussions rather than interrogations.

Takeaways

  • What decided it: Clean Architecture take-home plus explainable Google-Doc DSA, then defending escalating Android architecture and an analytics SDK with the Head of Engineering
  • Common fail: Treating CRED like a pure LeetCode screen, or shipping a take-home that ignores Clean Architecture / state persistence
  • How to practise: One 24-hour Android POC with Clean Architecture; medium DSA written without an IDE; design an analytics SDK aloud with progressive constraints

Experience 2: the machine-coding round is where most candidates are filtered

Consolidated from public prep write-ups and candidate reports on the SDE loop, since individual accounts vary by track (backend, Android, automation).

  • The structure is broadly consistent: take-home assignment → DSA and puzzles → machine coding / low-level design → system design plus managerial with a senior engineering leader.
  • Machine coding is the CRED-specific round and the one most often described as decisive. Reported themes: implement an LRU cache, design a key-value store, apply SOLID principles and design patterns, reason about idempotency, and justify a schema.
  • Idempotency comes up because of the domain. In a payments and credit-card-bill product, a retried request must not double-charge. Being able to explain why an operation needs an idempotency key is a genuine differentiator here, not a buzzword.
  • DSA is medium, not hard. Multiple reports put the problems at LeetCode-medium. The differentiator is clean, explainable code under whiteboard-like conditions.
  • The final round is fit-heavy but still technical. Expect to defend design choices from earlier rounds.

Takeaways

  • What decided it: Machine coding that shows SOLID, schema justification, and idempotency reasoning for payments retries
  • Common fail: Passing initial tests then failing when requirements change mid-round, or treating idempotency as a buzzword
  • How to practise: Build LRU / key-value store / parking-lot LLD with tests; add one extension live; explain idempotency keys for double-charge prevention

Sources for this section

Experience 3: Backend intern - machine coding (parking lot LLD)

Public Medium report (Dec 2025 backend intern loop). Candidate cleared screening into a 2.5-hour machine coding slot.

Problem theme: Multi-floor parking lot with vehicle types, spot sizes, best-fit allocation, deterministic priority rules, and thread-safe park/exit in memory (no external DB).

What interviewers graded: Separation of domain vs allocation service, extensibility when requirements shift, concurrency correctness, and production-shaped code - not clever one-liners.

Outcome: Rejected after round, but report highlights CRED’s bar on LLD + thread safety as the real filter.

Source: CRED Backend Intern Machine Coding Experience - Medium (Tushar Bhardwaj)

Experience 4: SDE intern + FTE backend - flight booking project round

Medium write-up from a CodeChef-contest shortlist path.

Round 1: Competitive coding / contest performance plus resume screen.

Round 2 (project / machine coding): Implement flight booking backend core flows - no UI, no database - with modular, SOLID code.

Round 3 (technical): Deep review of Round 2 implementation, extension feature added live, then DBMS / CAP theorem fundamentals.

Round 4: Managerial / culture (CRED Mark style in some loops).

Result: Rejected - author notes failing to refactor cleanly when new functionality landed mid-round.

Lesson: CRED expects you to extend LLD under pressure, not only pass initial test cases.

Source: CRED SDE Intern + FTE Backend Experience - Medium (Dheeraj Bhagchandani)

Experience 5: On-campus internship - HR as conversation

Nybles / Medium campus intern report.

Prior rounds: DSA-heavy prep (InterviewBit standard questions, contests, GFG last-minute notes).

HR (~30 min): Introduction, teamwork, time management, skills you want to learn - structured as dialogue, not a memorized monologue.

Takeaway: Strong communication and honest curiosity outperform scripted answers after technical clearance.

Source: CRED Internship Interview Experience - Medium (Nybles)

Questions that come up often

Coding / technical

  1. Design an LRU cache. Usually expects HashMap + doubly linked list
  2. Implement a rate limiter. Usually expects sliding window / token bucket
  3. Merge overlapping time intervals. Usually expects sort + sweep
  4. Discussion on credit lines and reward systems, bottlenecks, failure modes, simple APIs
  5. Detailed project discussion, architecture, hardest bug, what you would change

HR / behavioural

  1. Why fintech / payments?
  2. A production bug or outage you helped with
  3. An integrity / pressure scenario
  4. Joining timeline

Practical tips for CRED

  • Clear the screening round first. Timed practice beats last-minute topic hopping.
  • For domain questions, explain credit lines in plain language, inputs, outputs, what breaks at scale.
  • OOPs and SQL still open a lot of CRED panels. Do not skip fundamentals.
  • HR answers should be concrete. One story with a result beats five slogans.
  • If you do not know something, say so and outline how you would find out.

HR interview

After technical rounds, CRED usually closes with a short HR / hiring-manager conversation: motivation, location, notice period, and a couple of behavioural stories. Prepare those answers on the dedicated page rather than cramming them into this hub.

Sample answers for high-frequency questions

Use these as frames, not scripts - interviewers probe follow-ups.

Q. Machine coding - design a credit-line component with clean, extensible classes
A. 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
A. 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?
A. 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
A. 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. 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.

Tips from successful candidates

Assessment tips

  • Confirm the current CRED pattern from the drive mail before practising old papers
  • Finish one problem or section fully before starting the next
  • Revise the fundamentals listed in the round table on this page

Interview tips

  • Narrate trade-offs; expect “why” after every answer
  • Only list projects you can defend under follow-ups
  • Prepare 3-4 STAR stories for behavioural prompts

HR tips

  • Know why CRED, not just why the industry
  • Be clear on location / notice period / higher studies
  • Practise answers on the dedicated HR page

Sources

These links are research inputs used to map CRED take-homes, machine coding, and senior design rounds - not copied page mirrors. We reorganized reports into process tables, outcome notes, and prep takeaways.

Cross-check the current drive mail for timings and track (Android vs backend vs automation). For OA practice, see CRED placement papers.

CRED hub

HR interview questions

Placement papers

Preparation guide

Similar companies

Razorpay · PhonePe · Paytm · Flipkart · Swiggy · Zomato