CRED-Style Machine Coding Round: Format, Tips & Practice Problems
Fintech machine coding rounds are graded differently, and CRED-style rounds are the sharpest example: the code-quality bar is reported to be unusually high, and the domain — money — makes correctness non-negotiable. A working demo with sloppy internals that might pass elsewhere typically does not pass here.
The scenarios are payments-shaped: wallets and ledgers, reward and points engines, subscription billing, referral attribution. What they share is a hidden theme — every operation must survive retries, partial failure, and double-submission without money or rewards being created or destroyed incorrectly. This page covers the format, the evaluation lens, and Gronex problems built in the same style.
What a CRED-style machine coding round looks like
Commonly reported as a take-home or 2-hour live round: build a small payments-adjacent service — a wallet with credits, debits, and refunds; a rewards engine with expiring points; a billing engine with proration. Specs tend to be precise about invariants: a balance can never go negative, a refund can never exceed the captured amount, a reward is granted at most once per qualifying event.
The review then goes deeper than most machine coding rounds. Expect line-level scrutiny: naming, small cohesive classes, immutability where it matters, tests that document behaviour, and honest error handling rather than swallowed exceptions. Rounds in this style often explicitly evaluate your test suite — what you chose to test reveals what you understood about the domain.
Idempotency is the signature topic. Somewhere in the spec or follow-up you will meet the retried request: the client timed out and sent the same debit again. If your design has no idempotency-key story — same key replays the original result, changed payload conflicts — that conversation goes badly. Ledger-style append-only records, rather than mutating a single balance field, is the other pattern reviewers consistently reward.
How you’re evaluated
Invariant preservation
No negative balances, no double refunds, no reward granted twice. Reviewers construct the exact sequence that would violate each and run it.
Idempotency & retry safety
Replayed operations return the original outcome; conflicting reuse is rejected. This is the round’s defining question.
Code quality at line level
Small classes, intention-revealing names, no dead code, meaningful tests. The bar is closer to a strict code review than a typical interview.
Auditability
A ledger or event history that explains every balance, so any state can be reconstructed and disputes resolved from the record.
Common mistakes that fail this round
- Storing only a mutable balance with no transaction history — the first dispute question kills it.
- Treating idempotency as a bolt-on: deduplicating by amount-and-time instead of an explicit key.
- Using floating point for money anywhere in the code.
- Shipping a working demo with no tests, in a round style that explicitly reviews the tests.
- Handling the happy path and throwing generic exceptions for everything else — error semantics are part of the contract.
Quick tips for the room
- Design the idempotency story before writing the first endpoint or method.
- Append ledger entries; derive balances. Never mutate a lone number.
- Use integer minor units (paise) for money — mention it out loud.
- Write the test names first; they become your invariant checklist.
How to prepare
Prepare like you are submitting to a strict code review, not racing a clock. Take one wallet-style problem and polish it fully: ledger entries instead of balance mutation, an idempotency-key mechanism, integer money types, and a test suite that names every invariant. One deeply finished exercise teaches more here than five rushed ones.
The problems below are the round’s greatest hits as real repositories: the wallet system and billing engine are the two most CRED-shaped, the referral and loyalty problems cover reward attribution, and the idempotency debugging problem drills the retried-POST scenario in isolation. All are graded by failing test suites — the same standard the round applies.
Practice problems in the CRED-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Wallet Transaction & Refund System
The signature fintech round: credit/debit/refund rules, idempotency, and ledger consistency.
Open the challenge →Subscription Billing & Proration Engine
Mid-cycle upgrades, proration math, idempotent invoicing, and dunning — recurring-money correctness.
Open the challenge →Referral & Reward Attribution
Reward mechanics with fraud edges: self-referral prevention, attribution windows, one reward per referee.
Open the challenge →Loyalty Points and Tier Management
A points engine with FIFO expiry, oldest-first redemption, and idempotent earn events. Free to try.
Open the challenge →API Contract Debugging: Idempotent POST
The retried-request drill: make a POST honour its Idempotency-Key so replays return the same order.
Open the challenge →FAQ
Were these problems taken from CRED interviews?
No. They are Gronex originals in the style of fintech machine coding rounds — the kind of problem asked in rounds like CRED’s. We never republish company questions, and Gronex is not affiliated with CRED.
Is the CRED-style bar really that different?
The rubric emphasis is different: code quality and invariant safety carry weight that raw feature completion carries elsewhere. Candidates commonly report line-level review of naming, tests, and error handling — prepare for a code review, not just a demo.
How do I show idempotency in a simple in-memory solution?
Keep a map from idempotency key to the stored outcome of the first attempt. Replays return that outcome; the same key with a different payload is a conflict. That in-memory sketch, clearly separated, is exactly what the round wants to see.
Should I write tests during the round?
In this style, yes — a handful of tests that pin the core invariants (no negative balance, refund cap, replay safety) is often weighted as heavily as the implementation itself.
Related
Gronex is not affiliated with, endorsed by, or sponsored by CRED. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from CRED.