CRED SDE-2 Bangalore 2024: Payment Processor Machine Coding to Offer, Then Comp Failed

TL;DR. Distributed systems engineer, now at Google, previously at Amazon. Interviewed for CRED SDE-2 in Bangalore, July 2024. Four rounds: (1) Machine Coding, 90 minutes, implement a Payment Processing package in Java with LLD patterns, error handling, and test cases; (2) Onsite DSA, 2 medium-difficulty problems using sliding window, maps, sets, and heaps; (3) Onsite HLD, design a Dropbox-like system with dynamic constraints, fault tolerance, and performance tradeoffs; (4) Hiring Manager, HLD problem plus project discussion plus behavioral. Cleared all four rounds. Got the offer. Then compensation negotiations did not work out, and the candidate did not join. Source linked at the bottom.

This is not a "How to crack CRED" overview. This is one specific candidate's specific mid-2024 loop, with the actual machine coding problem, the actual DSA techniques, the actual system design prompt, and the actual outcome where the offer existed but the money did not.

The verified candidate

The candidate, Indraneel Ghosh, is not a junior engineer trying to break into CRED. He was at Amazon at the time of interviewing, and later moved to Google. This is the profile CRED targets for SDE-2: engineers who are already at FAANG-tier companies and might be open to a high-growth startup with strong engineering culture. The bar for this candidate pool is accordingly high.

The fact that he cleared all four rounds and still did not join because comp did not work out tells you something about CRED's negotiation dynamics. CRED's engineering reputation is strong. Their compensation competitiveness against FAANG counter-offers is a different question.

CRED's interview structure for SDE-2 (as of mid-2024)

The critical detail: CRED leads with machine coding, not DSA. Most companies open with an OA or a DSA phone screen. CRED puts the hardest round first. If you fail machine coding, the rest of the pipeline never happens. This is a deliberate filter: CRED values engineers who can write production-quality code under time pressure, not engineers who can solve LeetCode problems in a scratchpad.

Round 1: Machine Coding (90 minutes)

The machine coding round at CRED is the defining round. 90 minutes to build a working system from scratch.

The problem: Payment Processing package. The candidate was asked to implement core features of a payment processing system. While the exact feature list is not fully disclosed, payment processing machine coding problems at this level typically require:

1. Transaction processing: handle payment initiation, validation, execution, and confirmation.
2. Multiple payment methods: credit card, debit card, UPI, net banking. Each has different validation rules and processing flows.
3. Error handling: network timeouts, insufficient funds, invalid credentials, duplicate transactions. Each error type requires a different recovery strategy.
4. Idempotency: the same payment request submitted twice should not result in a double charge.
5. State management: a transaction moves through states (initiated, processing, completed, failed, refunded). Invalid state transitions must be blocked.

What was evaluated.

LLD patterns: the interviewer looked for Strategy pattern (different payment methods), State pattern (transaction lifecycle), and Factory pattern (payment method instantiation). If you wrote a PaymentProcessor class with if-else chains for payment type, you would lose points compared to a candidate who used polymorphism with a PaymentMethod interface and concrete implementations.

Error handling: not just try-catch. The interviewer evaluated whether the candidate designed a retry mechanism with exponential backoff for transient failures, and a dead-letter queue for permanent failures. At SDE-2 level, "catch Exception and log it" is a fail signal.

Test case coverage: the candidate was expected to write tests. Not just happy-path tests, but edge-case tests: what happens when a payment times out mid-processing, what happens when the idempotency key collides, what happens when a refund is requested for a transaction that is still in the "processing" state.

The extension. The initial time allotment was 60 minutes. The candidate requested (or was offered) a 30-minute extension, bringing the total to 90 minutes. This is common at CRED. The machine coding problem is deliberately too large for 60 minutes. The signal is not "can you finish in 60 minutes" but "how much working, tested code can you produce in 90 minutes with a clean design?"

The candidate's assessment: the interviewer was "collaborative," meaning they provided clarifications on ambiguous requirements and engaged in design discussion during the implementation. This is the CRED machine coding style. It is not a silent observation round. The interviewer is an active participant, and how you respond to their suggestions and questions is part of the evaluation.

Round 2: Onsite DSA (60 minutes)

Two medium-level problems that the candidate described as based on "practical real-world applications." This phrasing suggests the problems were not abstract LeetCode variants but were framed in a product context (e.g., "given a stream of user transactions, find the longest window where spending exceeds ₹X" rather than "find the longest subarray with sum greater than K").

The techniques: sliding window, maps/sets for lookups, and heaps for priority-based operations. This combination typically appears in problems like: "find the K most frequent transactions in a sliding window of the last N minutes" (sliding window + heap + map), or "find all users whose spending pattern matches a target within a rolling window" (sliding window + set).

The candidate described this as the "easiest round in the process." For a FAANG-caliber engineer, medium-level DSA problems with real-world framing are warm-up territory. The round exists as a baseline filter, not as the discriminator. At CRED, machine coding and HLD are the discriminators.

Round 3: Onsite HLD (60 minutes)

The HLD problem: design a cloud file storage system like Dropbox. The "dynamic constraints" part is the CRED signature. The interviewer does not give you the full set of requirements upfront. They start with a basic version ("design a system where users can upload, download, and share files") and then add constraints during the discussion: "now make it work with files up to 10 GB," "now add versioning," "now handle 100 million users with 5 nines availability."

Expected design components for a Dropbox-like system:

Key design decisions the interviewer probed:

1. Chunking strategy. Files are split into fixed-size blocks (4 MB typical). Only changed blocks are uploaded on file modification (delta sync). This reduces bandwidth for large files.
2. Deduplication. Content-addressable storage using SHA-256 hash of each block. If two users upload the same file, only one copy is stored. This is a significant cost optimization at scale.
3. Conflict resolution. When two users edit the same file simultaneously on different devices, which version wins? Dropbox uses "last writer wins" with the losing version saved as a conflict copy. The candidate must discuss the tradeoff: simpler semantics vs. potential data loss.
4. Fault tolerance. S3 provides 11 nines durability. The metadata service needs multi-region replication with leader election (Raft or Paxos). The sync service must handle client disconnections and resume sync from the last acknowledged block.

The candidate called this a "fun round." For an engineer who builds distributed ML systems at scale, a Dropbox design discussion is a comfortable domain. The round validated that the candidate could think about large-scale distributed systems with evolving requirements.

Round 4: Hiring Manager (60 minutes)

The Hiring Manager round at CRED is not purely behavioral. It includes another HLD problem (lighter than Round 3), a thorough cross-examination of the candidate's past projects (with adversarial questioning about design decisions), and behavioral questions about leadership, conflict resolution, and technical decision-making under ambiguity.

The candidate received positive feedback. Specific details of the HLD problem and behavioral questions were not disclosed.

The offer and the comp failure

The candidate cleared all four rounds and received a formal offer from CRED for the SDE-2 role. Then "compensation negotiations did not work out."

No specific numbers were disclosed. What we know from market data: CRED SDE-2 total compensation in Bangalore in mid-2024 was typically ₹35 to ₹55 LPA, with a significant ESOP component. The base salary component was ₹20 to ₹30 LPA, with the rest in ESOPs valued at CRED's last valuation round.

For a candidate who was at Amazon and later went to Google, the CRED comp package likely could not match the FAANG liquid compensation. CRED ESOPs are valuable only if you believe in CRED's trajectory to IPO and the IPO valuation being at or above the last private round. An Amazon engineer with ₹50L+ liquid CTC may not accept ₹30L base plus ₹25L in illiquid ESOPs, even if the total "paper CTC" is higher.

This is the structural tension in Indian startup hiring at the senior level. The engineering interview bar is FAANG-equivalent. The compensation is not, especially on the liquid component. Candidates who clear the bar often have FAANG offers on the table, and FAANG offers are liquid.

Real questions asked in this loop

1. Payment Processing package (machine coding): implement transaction processing, multiple payment methods, error handling with retry/backoff, idempotency, state management. Java. LLD patterns evaluated: Strategy, State, Factory.
2. DSA Problem 1: medium-level, practical framing, sliding window plus maps.
3. DSA Problem 2: medium-level, practical framing, heaps plus sets.
4. Dropbox-like file storage (HLD): chunked upload, delta sync, deduplication, conflict resolution, fault tolerance, evolving constraints.
5. Hiring Manager HLD: lighter system design problem (not disclosed).
6. Project deep-dive: architecture decisions in distributed ML systems, adversarial questioning on tradeoffs.

What the comp failure reveals about CRED

1. Machine coding is CRED's hardest round. It comes first, it is 90 minutes, and it requires production-quality code with tests. Practice building complete systems in 90 minutes: payment processor, ride-matching engine, notification dispatcher, URL shortener with analytics. Use Java or Python. Write tests.
2. LLD patterns must be automatic. Strategy, State, Factory, Observer, Builder. If you have to think about which pattern to use for "multiple payment methods," you are 10 minutes behind. These should be reflexive.
3. CRED's HLD rounds have evolving constraints. The interviewer will not give you the full spec upfront. Practice answering "now what if we add X?" for every system you design. The skill is not "design Dropbox." The skill is "adapt your Dropbox design in real-time when the interviewer changes the rules."
4. DDIA and Alex Xu are the named prep materials. Designing Data-Intensive Applications (Kleppmann) for depth, Alex Xu's System Design Interview for breadth. The candidate named both.
5. If you have FAANG offers, negotiate CTC carefully. CRED's ESOP component can be significant. Ask for the latest 409A valuation, the vesting schedule, the cliff, the exercise price, and what happens to your shares if you leave before IPO. The "paper CTC" number in the offer letter is not the number you take home.

Verification and source

This analysis is based on a published interview experience on Medium by Indraneel Ghosh, published December 15, 2024, describing a CRED SDE-2 interview process initiated in July 2024. The source includes: role (SDE-2), location (Bangalore), round structure (4 rounds), specific round types (machine coding, DSA, HLD, HM), named problems (payment processing, Dropbox-like system), techniques evaluated (sliding window, heaps, LLD patterns), outcome (offer extended, comp negotiation failed), and prep resources (DDIA, Alex Xu, LeetCode contests).

Original article: CRED SDE-2 Interview Experience (Offer)

PapersAdda verification standard: publicly accessible URL, per-round detail, named problems, and explicit outcome. This source meets all four criteria.

What candidates ask about CRED SDE-2

What is CRED's engineering reputation? CRED is widely regarded as one of the strongest engineering cultures among Indian startups. Founded by Kunal Shah (Freecharge founder), CRED's engineering team is drawn heavily from FAANG and top-tier product companies. The interview bar reflects this: machine coding rounds, FAANG-level system design, and a strong emphasis on code quality over raw problem-solving speed.

Is CRED's CTC competitive with FAANG? On paper CTC, sometimes yes. On liquid CTC, usually no. CRED's ESOP component can make the total package look comparable to FAANG, but ESOPs are not liquid until IPO. For candidates with FAANG offers that are fully liquid (base + RSU in publicly traded stock), CRED often cannot match on take-home compensation.

How long is the CRED interview process? In this case, the candidate was recruited in July 2024 and the article was published in December 2024. The typical end-to-end timeline for CRED SDE-2 is 2 to 4 weeks from first recruiter contact to offer.

What language should I use for CRED machine coding? Java and Python are the most common choices. CRED's backend is primarily Kotlin/Java, so Java is slightly advantageous for LLD discussions where Spring-specific patterns (dependency injection, repository abstraction) can be referenced naturally.

Also on PapersAdda

• The startup rejection contrast: Swiggy SDE-2 Backend Bangalore 2025: ₹40 LPA Role, Rejected at Train Booking LLD, where design depth was not enough
• FAANG machine coding comparison: Uber SDE-2 L4 India 2025: Job Scheduler Machine Coding in a 6-Round Offer, a similar machine coding challenge at Uber
• Campus-to-FAANG pipeline: Goldman Sachs Engineering Analyst 2025: 10.5-Hour Campus Marathon, finance-adjacent engineering with comparable rigor
• The FAANG lateral baseline: Amazon SDE-2 (L5) 2026: A Tier-3 Engineer's Real 5-Round Loop to ₹60L, the FAANG offer this candidate likely had on the table

Before you rely on this: candidates report these trends, but companies and boards revise rules every cycle. We compile from public preparation resources and official notifications, so always confirm the current pattern on the official portal first.