What to Expect in the CRED System Design Interview

At CRED the design assessment comes in two parts, and the first one is a machine coding round. Candidates report a project or machine coding round of about 150 minutes where you build working code, and a separate discussion round covers design at a higher level. Reports from that discussion name idempotency, schema design, de-duplication, and failure handling.

Senior candidates report a final round with an engineering leader that mixes design questions with a managerial conversation. The questions come from CRED's own product areas, which are credit card bill payments, rewards, and UPI payments.

The Machine Coding Round

A machine coding round is a long session where you build a small working program from a written requirement list. It is graded on code that runs, unlike a design discussion, which is graded on what you say. Reports describe about 150 minutes on HackerRank, followed by a code review where the interviewer asks why you structured the classes that way.

Reported problems at CRED include a file manager with insert, delete, move, and exact and pattern search, a payment processor, a cache such as an LRU cache, and a search box with suggestions. The graders look for separated responsibilities, clear interfaces, error handling, and room to add one more requirement without a rewrite. Build a console program rather than a user interface, because the grading covers structure and correctness, not visual design. The difference between this round and the discussion round is explained in system design versus low level design, and the round itself is described in what a machine coding round is.

The Design Topics

Payment correctness. Reports describe idempotency questions, and idempotency means that a repeated request produces one result, not two. A member who taps pay twice must be charged once, so expect follow-up questions on retries, timeouts, and unknown gateway responses.

Ledgers and reconciliation. Money systems record every state change, and reconciliation means comparing your records against the bank or gateway records and fixing the differences. Be ready to describe a daily job that finds payments stuck in a pending state.

Schema design. Reports name schema design directly, so expect to define tables, keys, and the states a payment moves through, and to defend each choice.

Rewards and notifications. A completed bill payment unlocks rewards and sends a message to the member, which is an event-driven problem, so expect questions on queues, ordering, and duplicate events.

Data fetching at scale. CRED reads credit and card data from outside providers, so expect questions on caching that data, refreshing it, and respecting rate limits.

A Walkthrough: Design Bill Payment

Here is a high level plan for the signature question.

1. Requirements (about 5 minutes). A member pays a credit card bill from the app, money must be charged once, the member must see a correct status, and rewards follow a successful payment.

2. The API. The client sends a payment request with an idempotency key it generates, and the server stores the key with the request and returns the same result for a repeat of the same key.

3. The state machine. Define states such as created, submitted, succeeded, failed, and refunded, and write every transition to a ledger table that is never updated in place.

4. The gateway call. Call the payment gateway with the same key on every retry, and treat a timeout as unknown rather than as a failure, so check the status before you retry the charge.

5. Reconciliation. Run a job that polls the gateway for payments stuck in submitted and moves them to a final state, because this job is what protects the member from a wrong balance.

6. Rewards and messages. Publish a payment succeeded event that the rewards service and the notification service consume, and make both consumers safe against the same event arriving twice.

7. Scale and failure. Shard by member, plan for queue spikes on bill due dates, and keep payments working when the rewards service is unavailable.

What the Interviewer Grades

Correctness comes first, then structure, then scale, so state the requirements before you draw anything. Name each trade-off out loud and give the reason, and connect every choice to the member, because a duplicate charge is real money. Reports describe interviewers who ask follow-up questions until they find the limit of your knowledge, and when you reach that limit, say so plainly.

Common Mistakes in This Round

• Treating payment as one write. A payment is a sequence of states across two systems, so a single database row is not a design.
• Skipping the unknown case. Candidates handle success and failure, then stop, but the gateway timeout with no response is the interesting case.
• Unstructured machine coding code. One large file with one class fails this round, even when every test passes.
• No plan for a repeated event. Rewards granted twice for one payment is a visible and expensive bug.
• Designing for scale first. Sharding before correctness is the wrong order in a payment design.

How to Prepare

• Practice building small programs. Grokking the Object Oriented Design Interview teaches the class structure that the machine coding round grades.
• Study the standard parts. Grokking the System Design Interview covers queues, caches, and databases, which every payment design uses.
• Rehearse the walkthrough above. Say the seven steps out loud in under 40 minutes, then repeat the exercise with a stricter requirement.
• Know the order of the rounds. The CRED interview process shows the rounds before and after, and the motivation question uses the same product research.
• Know the wait. Plan the follow-up with how long it takes to hear back after a CRED interview.