Setu-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
API-infrastructure fintechs sell contracts, not screens. Their customers are other engineering teams, so the product is a set of endpoints, status transitions, and webhooks that must behave identically on the thousandth call as on the first. Machine coding rounds in the style of Setu are built around that: you are asked to design and implement a small piece of a public API, and the grading is closer to an API review than a feature review.
The typical domains are collection and payout flows — payment links, bill fetches, mandates, virtual accounts — each of which is a request that goes out, a state that changes asynchronously, and a webhook that tells the customer about it. This page covers the format, the evaluation lens, and Gronex repositories that drill the same contract-level discipline.
What a Setu-style machine coding round looks like
Expect a 90-minute build of a small API surface: create a collection request, query its status, accept an inbound status update, and notify the merchant by webhook. The statement tends to specify the resource lifecycle precisely and leave the contract details to you, which is the actual test — status naming, error envelope, pagination, and what a duplicate create should do are all yours to decide and defend.
Webhook delivery is the part with real depth, and rounds in this style go there. Your delivery must be at-least-once with retries and bounded backoff, must carry an event id the receiver can deduplicate on, and must not let one slow merchant endpoint block every other merchant’s notifications. Candidates who send the webhook inline inside the status-change transaction fail two of those three, and the third question exposes it.
Contract hygiene is graded explicitly: consistent error shapes with machine-readable codes, validation before side effects, cursor pagination rather than offsets on a mutating collection, and versioning that does not break an existing integration. The follow-up is usually additive — add a new event type, add a field, add a new status — checking whether your consumers would survive it.
How you’re evaluated
Resource lifecycle clarity
A named state per resource, legal transitions only, and a terminal state that later updates cannot disturb.
Webhook delivery semantics
At-least-once with event ids, bounded retry and backoff, per-destination isolation, and a dead-letter path once retries are exhausted.
Error envelope and validation
One error shape with stable codes, validation before any mutation, and 4xx-versus-5xx used honestly.
Forward-compatible design
Additive changes — new event types, new fields, new statuses — that do not break a consumer written against the old contract.
Common mistakes that fail this round
- Emitting webhooks inline with the state change, so a slow receiver stalls the request and a retry re-emits.
- Offset pagination over a collection that is being written to, which silently skips and repeats records.
- Free-form error messages with no codes, leaving the integrator with string matching as their only option.
- Unbounded retries with no backoff, turning one failing merchant endpoint into a self-inflicted load problem.
- Making a duplicate create produce a second resource because the create path had no idempotency story.
Quick tips for the room
- Write the webhook envelope — event id, type, resource, timestamp — before any handler.
- Deliver asynchronously from a queue; never inside the transaction that changed state.
- Choose cursor pagination and say why in one sentence.
- Give every error a code the integrator can branch on.
How to prepare
Design the contract on paper before the first class: resources, statuses, error codes, the pagination scheme, and the webhook envelope with its event id. Then implement the delivery queue as a separate component with retries and a dead-letter list, because that separation is the single clearest signal in this round style.
The repositories below cover the contract surface directly: the webhook problem is idempotency and ordering on the receiving side, the pagination problem is the cursor contract, the validation problem (free) is the error envelope, the queue-consumer problem is your retry-and-DLQ machinery, and the multi-tenant API-key problem is the authentication layer such an API needs.
Practice problems in the Setu-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.
Webhook Event Idempotency & Ordering
Both sides of the webhook contract: duplicate deliveries and out-of-order events that must not corrupt state.
Open the challenge →API Debugging: Cursor Pagination
Fix pagination that skips and repeats rows under concurrent writes — the contract bug integrators notice first.
Open the challenge →API Debugging: Validation & Error Envelope
Make a broken API return honest 400s with a stable error shape instead of 200s with garbage. Free to try.
Open the challenge →Queue Consumer Idempotency & Retry
The delivery machinery: at-least-once processing, bounded backoff, and a dead-letter queue that is actually used.
Open the challenge →Multi-Tenant API Key & Scopes
The auth layer for a public API: scoped keys, rotation grace windows, revocation, tenant boundaries.
Open the challenge →FAQ
Are these real Setu interview questions?
No. They are Gronex originals in the style of fintech API-infrastructure rounds — the kind of problem asked in rounds like Setu’s. Gronex is not affiliated with Setu and never republishes company questions.
Should I build an HTTP server for this round?
Only if the statement asks. Service-layer methods with clear request and response objects demonstrate the same contract thinking, and leave you the time to build the webhook delivery component that actually differentiates.
Why is pagination treated as a design question?
Because on a collection that changes while it is being read, offset pagination is provably lossy. Choosing a cursor and explaining the ordering key it depends on is a short answer that signals production experience.
How do I show webhook reliability without infrastructure?
An in-memory delivery queue with per-destination attempt counts, exponential backoff, and a dead-letter list is enough. The reviewer is checking the semantics, not the transport.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Setu. 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 Setu.