CRED Software Engineer Interview: Questions & Prep (2026)

CRED software engineer interviews test whether you can build systems where being wrong costs money. The product moves credit card payments, rent, and lending flows for members who expect both bank-grade correctness and consumer-app polish — so the loop probes payment reliability (idempotency, retries, exactly-once effects), reconciliation and ledger thinking, security posture, and mobile-first performance in the same conversation. The process typically runs recruiter screen → one or two DSA/problem-solving rounds → a system design round (machine coding or low-level design for some backend and mobile roles) → a hiring manager/behavioral round. Candidates report the bar leans toward depth over breadth: interviewers pick one thread — a failure mode, a data-model choice, a line of your code — and pull until they find where your understanding ends. Code quality is treated as a first-class signal, not a tiebreaker; sloppy naming, missing edge cases, or untested error paths reportedly cost candidates offers even when the algorithm is right. If you're earlier in the funnel, start with the broader guide on [how to get hired at CRED](/company_guide/how-to-get-hired-at-cred.html).

1. Design a payments system where a member pays a credit card bill through CRED: money leaves their bank, the card issuer must be credited, and any step can fail. Guarantee the member is never double-charged and never silently unpaid.
2. What is idempotency, how would you implement idempotency keys for a payment API, and what are the corner cases (key reuse, partial failures, concurrent retries)?
3. Design a double-entry ledger service for a fintech: schema, immutability, how you post reversals, and how you answer "what was this account's balance at 11:59 pm on March 31".
4. Design a reconciliation system that compares CRED's internal ledger against bank and payment-gateway settlement files arriving hours late, in different formats, with occasional missing rows.
5. A payment gateway returns a timeout — you don't know if the debit succeeded. Walk through exactly what your system does next.
6. Implement a rate limiter (token bucket or sliding window) in clean, tested code, then extend it to be distributed across nodes.
7. Given a stream of transactions, detect duplicates within a time window under memory constraints — discuss exact versus probabilistic (Bloom filter) approaches.
8. How would you store and protect card data and tokens? Discuss encryption at rest and in transit, tokenisation, secrets management, and least-privilege access.
9. Design the backend for CRED's rewards flow: a payment completes, coins are credited, and a member redeems them — with concurrency safety when two redemptions race for the last unit of a reward.
10. The app's home screen must render fast on mid-range Android devices over patchy networks. What do you optimise across API design, payload shape, caching, and image delivery?
11. Two services must update state atomically but share no database. Compare distributed transactions, sagas, and the outbox pattern — when would you choose each?
12. Tell me about the highest-quality codebase you've worked in. What made it that way, and what did you personally do to keep it that way?

Q: Detect duplicate transactions in a stream within a time window (DSA walkthrough).

Clarify first: what defines a duplicate (same transaction ID, or same card + amount + merchant within N minutes?), what's the stream rate, and is a rare false positive acceptable? Start with the exact solution: a hashmap from transaction key to last-seen timestamp, plus a min-heap or deque to evict entries older than the window — O(1) amortised per event, memory proportional to events in the window. Then address the constraint the interviewer actually planted: at high volume that map may not fit in memory. Offer the probabilistic upgrade — a Bloom filter (no false negatives for "definitely new", tunable false-positive rate) or, better for windowed semantics, rotating a pair of filters so old entries age out. State the trade-off explicitly: in payments, a false positive means blocking a legitimate transaction, so you'd use the filter as a cheap first pass and confirm suspected duplicates against the database before rejecting. Code the exact version cleanly with eviction handled, and say how you'd test it: boundary timestamps, concurrent inserts, and clock skew. Connecting the structure to the money-movement consequence is what separates a good answer here.

Q: Design the bill-payment flow so a member is never double-charged and never silently unpaid (system design outline).

Requirements first: correctness over latency, full auditability, and a clear member-facing state at every moment. Model the payment as a state machine (INITIATED → DEBIT_PENDING → DEBITED → CREDIT_PENDING → COMPLETED, with explicit FAILED and REFUND states) persisted before any external call. Every external call carries an idempotency key derived from the payment ID, so retries are safe. The dangerous case is the ambiguous timeout — the gateway didn't answer, and the debit may or may not have happened. Never guess: park the payment in a PENDING_VERIFICATION state, run a status-inquiry/reconciliation job against the gateway, and only then either advance or refund. Use an outbox pattern so state transitions and outgoing events commit atomically, and a double-entry ledger as the source of truth rather than mutable balance columns. Reconciliation against settlement files closes the loop on anything both sides disagree about. Volunteer the member experience too: show "payment processing" honestly with a commitment on resolution time — silent limbo is the real product failure. Close with metrics: payment success rate, time-in-pending, reconciliation break count.

Q: Tell me about a time you raised the quality bar (behavioral).

*Situation:* At my previous company, our payments-adjacent service had flaky integration tests and a habit of hotfixing in production; two minor incidents in a quarter traced back to untested error paths.

*Task:* I wasn't the team lead, but I decided to own improving reliability rather than just my own tickets.

*Action:* I introduced contract tests against the gateway sandbox, added an error-path test requirement to our definition of done, and refactored the retry logic into one audited module instead of five copies. I got buy-in by presenting the incident cost in engineer-hours, not by mandate.

*Result:* Escaped defects in that service dropped from roughly one per month to one in the following two quarters, and the error-path test rule spread to two other teams. I'd bring the same instinct to CRED: quality is a system property you engineer deliberately, not a code-review vibe.

For DSA rounds: clarify constraints, state the brute force and complexity, improve, then write genuinely clean code — meaningful names, handled edge cases, and a quick verbal test pass — because candidates report code quality is scored, not just correctness. For system design: requirements → state machine and data model → external-call safety (idempotency, retries with backoff, timeout handling) → consistency strategy (sagas or outbox over two-phase commit, and say why) → observability and reconciliation as the final correctness net. In fintech design answers, always name the ambiguous-timeout case before the interviewer does; it's the canonical probe. For security questions, structure as data classification → encryption and tokenisation → access control and secrets → audit trail. For behavioral rounds, use STAR with one quantified result, favouring stories about correctness, quality advocacy, and incidents over pure feature delivery.

Candidates report CRED interviewers optimise for depth and craft. In design rounds, the signal is whether you reason about failure as the default — idempotency, reconciliation, and audit trails offered unprompted — and whether you can defend each choice one level deeper (why outbox over a distributed transaction, why append-only ledger over balance mutation). In coding rounds, they watch how you write, not just what: structure, naming, error handling, and whether you test your own code before declaring done. Mobile and frontend loops add performance literacy — render budgets on mid-range Android hardware and resilience on flaky networks are treated as core competence, not polish. In behavioral rounds, they look for engineers who have personally raised a quality bar somewhere and can prove it with outcomes. Breadth without depth reportedly fails here; a candidate who knows one system cold beats one who name-drops ten.

Weeks 1–2: DSA reps with a quality twist. Do 40-odd problems across hashmaps, heaps, sliding windows, trees, graphs, and concurrency basics — but treat every solution as production code: name well, handle edges, and verbally test before finishing. Practise one machine-coding exercise (rate limiter, parking lot, or a mini-ledger) end to end with tests. Weeks 3–4: fintech system design. Design a payment flow with idempotency and an ambiguous-timeout path, a double-entry ledger, and a reconciliation pipeline — write out the state machines by hand until they're automatic. Review security fundamentals: tokenisation, encryption at rest/in transit, secrets management, and least privilege. Week 5: behavioral and depth prep — six STAR stories (an incident, a quality-bar story, a hard trade-off, a failure, a scaling story, a conflict), each with a number, plus two mocks with a senior engineer, ideally from fintech. Alongside prep, keep your pipeline warm: [knok](https://knok.work/) searches 150+ job boards overnight, surfaces only high-fit engineering roles, and drafts hiring-manager outreach, so practice doesn't come at the cost of applications.

Designing payment flows for the happy path — no idempotency keys, no plan for the gateway timeout where you don't know if money moved, no reconciliation to catch what slips through. Storing balances as mutable columns instead of reasoning from an append-only ledger. Reaching for two-phase commit across services without acknowledging why fintech systems typically prefer sagas and outbox patterns. Writing interview code with single-letter variables and unhandled edge cases — candidates report this costs offers at CRED even when the algorithm is correct. Treating security as a checklist recital instead of reasoning about what data you hold and who can touch it. Ignoring mobile reality: designs that assume fast networks and flagship devices. Behavioral answers that show delivery speed but no evidence you've ever fought for quality. And asserting how CRED's internals work — hedge with "I'd expect, and would validate with your team."