slice-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Consumer-credit fintechs turn a single number — an available limit — into a product, and every feature they ship is a way of moving that number safely. Machine coding rounds in the style of slice reflect this: the scenarios are credit lines, spends, repayments, billing cycles, and the rewards layered on top, and the invariant under all of them is that utilisation and limit can never disagree.
What makes the domain interesting as an interview is that credit runs on time as much as money. A billing cycle closes, a due date passes, a repayment lands and frees limit, a minimum-due calculation depends on where in the cycle you are. This page covers the commonly reported format, the evaluation criteria, and Gronex repositories that grade the same mechanics against failing tests.
What a slice-style machine coding round looks like
The usual build is a credit-line service: assign a limit, authorise a spend against available limit, record repayments that restore it, and close a billing cycle into a statement with a total and a minimum due. Rules are stated as absolutes — utilisation never exceeds the limit, a repayment can never make the outstanding negative, a spend after cycle close belongs to the next statement.
Cycle boundaries are where the round has teeth. A spend at 23:59 on the closing day and a repayment at 00:01 the next morning must land in the right statements, which forces you to treat the cycle as an explicit object with a start, an end, and a state rather than deriving it from the current date wherever it is needed. Interviewers reliably test the boundary in both directions, and an injected clock is what makes that testable at all.
The rewards or cashback layer is usually the extension. It arrives as "now give 1% back on this category, credited on statement close, capped monthly" — a rule the follow-up will change. Candidates who built spends as events they can aggregate get this almost free; candidates who mutated a running total have to reconstruct history that no longer exists.
How you’re evaluated
Limit and utilisation integrity
Available limit derived from the limit and outstanding spends, never stored independently and never allowed to drift negative.
Explicit billing cycles
Cycles as first-class objects with boundaries and states, so every spend and repayment lands in exactly one statement.
Repayment allocation
A stated order — fees, interest, principal, or oldest-first — applied consistently, with partial payments handled without loss.
Event-shaped history
Spends and repayments retained as events so statements, rewards, and disputes can all be derived rather than remembered.
Common mistakes that fail this round
- Storing available limit as its own mutable field alongside outstanding, guaranteeing the two disagree eventually.
- Deriving the current cycle from the system clock inline, which makes every boundary test impossible to write.
- Ignoring the allocation order for partial repayments, so the outstanding balance depends on call order.
- Computing interest or cashback in floating point and then defending a rounding discrepancy live.
- Applying a repayment twice because the webhook that carried it had no event-level deduplication.
Quick tips for the room
- Derive available limit; never store it.
- Make the billing cycle an object with an explicit close() step.
- State your repayment allocation order before writing the method.
- Inject the clock immediately — the whole domain is time-shaped.
How to prepare
Build the ledger-and-cycle core: spends and repayments as append-only events, available limit as a derived function, and a cycle object you can close on demand in a test. Then add one capped cashback rule and change it — the exercise that proves whether your rule lives in data. An injected clock is not optional here; add it in the first ten minutes.
The repositories below map the domain: the wallet problem is the event-ledger discipline, the billing engine is cycle and proration math, the loyalty problem is capped rewards with expiry, the webhook problem covers repayments arriving twice from a payment partner, and the bank-transfer problem (free) drills the atomic money movement underneath all of it.
Practice problems in the slice-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
Append-only money events with derived balances, idempotent mutations, and cumulative refund caps.
Open the challenge →Billing & Proration Engine
Cycle-boundary arithmetic: mid-cycle changes, proration, idempotent invoicing, and dunning states.
Open the challenge →Loyalty Points & Tier Management
The rewards layer: FIFO expiry, oldest-first redemption, tier recalculation, idempotent earn events.
Open the challenge →Webhook Event Idempotency & Ordering
Repayment notifications that arrive twice or out of order, and must still leave one correct outstanding balance.
Open the challenge →Bank Transfer & Deadlock Prevention
Atomic, deadlock-free money movement between accounts with ordered locking. Free to try.
Open the challenge →FAQ
Were these problems asked at slice?
No. They are Gronex originals in the style of consumer-credit fintech rounds — the kind of problem asked in rounds like slice’s. Gronex is not affiliated with slice.
Do I need to know lending regulation or interest formulas?
No. Any formula you need will be in the statement. What is graded is whether you apply it in integer minor units with a declared rounding rule, and whether your cycle boundaries put each event in the right statement.
Why is the clock such a big deal in this round?
Because almost every rule references a date — cycle close, due date, cashback month, expiry. If the code calls the system clock directly, none of those rules can be tested inside the round, and the reviewer will ask you to demonstrate exactly one of them.
How does this differ from a wallet-style fintech round?
A wallet round is about money you already have. A credit round adds a limit that must never be exceeded and a cycle that decides which statement an event belongs to, so time handling and derived-state discipline carry more weight.
Related
Gronex is not affiliated with, endorsed by, or sponsored by slice. 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 slice.