Zeta-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Banking-as-a-service platforms run other companies’ banking products, which puts two hard requirements in the same codebase: card-authorisation correctness measured in milliseconds and paise, and tenant isolation strict enough that one bank program can never observe another. Machine coding rounds in the style of Zeta pull from exactly that overlap.
The scenarios are issuing-shaped: authorisation holds against an available balance, spend controls and velocity limits, settlement of a hold into a posted transaction. Underneath, everything is multi-tenant — programs, products, and accounts belong to an issuer. This page covers the format, the grading criteria, and Gronex repositories with the same shape.
What a Zeta-style machine coding round looks like
A representative statement asks for an authorisation service: given an account with a balance, approve or decline a card authorisation, place a hold, and later settle or expire it. Spend controls come as a rule set — daily limit, per-merchant-category restriction, velocity cap of N transactions per hour — and are deliberately written so that two rules can both apply to one transaction.
Available balance is the concept the round is really testing. It is not the posted balance; it is posted minus active holds, and every approval decision must read it under the same rules that the hold lifecycle maintains. The three probes are predictable and still catch people: two authorisations racing the last available rupee, a hold that expires after the authorisation was already settled, and a settlement for less than the authorised amount, which must release the difference.
Because the platform is multi-tenant, expect at least one requirement that scopes everything to a program or issuer, and a follow-up about noisy neighbours — one program’s volume degrading another. You are not asked to shard anything in the room; you are asked to have written lookups that already carry the tenant, and to describe the partitioning you would choose.
How you’re evaluated
Available-balance correctness
Posted minus active holds, computed in one place, and never negative regardless of the order approvals and settlements arrive in.
Hold lifecycle
Authorise, settle in full or in part, expire, reverse — with the unsettled remainder released exactly once on every exit path.
Composable spend controls
Limits and restrictions evaluated as an ordered rule set where multiple rules can apply, with the declining rule named in the response.
Tenant scoping by construction
Program or issuer identity threaded through every lookup and mutation, with no global registries a second tenant could read.
Common mistakes that fail this round
- Approving against the posted balance, so a second authorisation is approved over money already held.
- Settling a partial amount and leaving the rest held forever because release lives only on the expiry path.
- Returning a bare decline without the rule that caused it — the round treats the reason as part of the contract.
- Implementing velocity limits with wall-clock calls, making the rule impossible to test inside the round.
- Keeping accounts in one global map and filtering by tenant at the call site, which is the leak the reviewer looks for first.
Quick tips for the room
- Write availableBalance() first and forbid any other balance read.
- Give every hold an expiry and a single release path used by all exits.
- Make the tenant id a parameter, never an ambient global.
- Return structured declines — code plus the rule that fired.
How to prepare
Implement the hold ledger properly once: posted entries, active holds, and a single available-balance function that both the approval path and the tests use. Then add three spend controls as data and make the decline response name the rule. Finally, walk the partial-settlement case out loud — it is the one that reveals whether your release logic is centralised.
The repositories below map the pieces: the escrow problem is hold-and-release under concurrency, the wallet problem is posted-balance and refund discipline, the multi-tenant API-key problem is isolation as the entire exercise, the rate-limiter problem is velocity control done deterministically, and the hot-partition problem is the noisy-neighbour follow-up as a real database investigation.
Practice problems in the Zeta-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.
Escrow Hold & Release
The authorisation hold in another domain: concurrency-safe held balances released exactly once.
Open the challenge →Wallet Transaction & Refund System
Posted-balance discipline: idempotent credits and debits, refund caps, and a ledger that explains every rupee.
Open the challenge →Multi-Tenant API Key & Scopes
Isolation as the whole problem: tenant boundaries, scope inheritance, rotation windows, revocation.
Open the challenge →Rate Limiter & Quota Enforcement
Velocity limits done right: per-key windows, quota accounting, and correctness under concurrent checks.
Open the challenge →Bank Transfer & Deadlock Prevention
Atomic two-account money movement with ordered locking — the core-banking kata. Free to try.
Open the challenge →FAQ
Were these problems asked at Zeta?
No. They are Gronex originals in the style of card-issuing and banking-as-a-service rounds — the kind of problem asked in rounds like Zeta’s. Gronex is not affiliated with Zeta.
Do I need card-network knowledge?
No. The statement defines the operations you must support. The domain only fixes the standard: available balance is posted minus holds, every hold has exactly one release, and declines are explained rather than implied.
How much multi-tenancy should I actually build?
In-memory scoping is enough. What is graded is that the tenant is part of every signature from the first line, and that you can describe how those boundaries become partitions in real storage.
Is concurrency expected in the build?
Often only in discussion, but the last-rupee race is guaranteed to be raised. Being able to convert a read-then-approve into an atomic check-and-hold — as the escrow problem forces — is what the question is testing.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Zeta. 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 Zeta.