Jupiter-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
A neobank does not hold the money — a partner bank does — which means its backend is mostly an ingestion and reconciliation system wearing a beautiful app. Transactions arrive as a feed, get enriched and categorised, drive savings goals and rewards, and must agree with the bank’s view at the end of the day. Machine coding rounds in the style of Jupiter draw on that pipeline.
That gives the round a different centre of gravity from a wallet round: less balance arithmetic, more "this feed is at-least-once, unordered, and occasionally corrects itself, now build something correct on top of it". This page covers the reported format, what evaluators look for, and Gronex repositories that train the same ingestion discipline.
What a Jupiter-style machine coding round looks like
Typical statements ask for a transaction ingestion and categorisation service: consume account transactions, deduplicate them, apply categorisation rules, aggregate per category and month, and expose a summary. Or a goal-based savings service: create goals, route round-ups or recurring debits into them, and track progress with withdrawal rules. Either way the input is a stream you do not control.
Duplicates and corrections are the designed difficulty. The same transaction can arrive twice with the same reference, and a pending transaction can later arrive settled with a different amount — the classic card-hold-then-clearing pattern. A correct design keys on the external reference, treats an update as an upsert with a version or status check, and never double-counts an aggregate. A design that appends everything it receives produces a spend summary that is quietly wrong, which is the failure the round is built to expose.
Categorisation rules are the extensibility surface. Merchant-pattern rules, amount rules, and user overrides must compose with a defined precedence, and the follow-up adds a rule type. The strong answer is an ordered list of rule objects with a first-match or highest-priority policy stated out loud; the weak answer is a long if-else the interviewer then asks you to reorder.
How you’re evaluated
Idempotent ingestion
The same transaction reference processed repeatedly leaves one record and one contribution to every aggregate.
Correction handling
Pending-to-settled updates adjust amounts and aggregates instead of creating a second transaction.
Rule precedence
Categorisation as an ordered rule set with user overrides winning, extendable without touching the ingestion path.
Aggregate derivability
Summaries recomputable from stored transactions, so a reprocessed feed converges instead of drifting.
Common mistakes that fail this round
- Appending every received message, so a redelivered feed inflates the user’s monthly spend.
- Treating a settled update as a new transaction and leaving the pending one counted as well.
- Maintaining only incremental aggregate counters with no way to recompute them after a correction.
- Hard-coding categorisation as nested conditionals that the "add a user override" follow-up breaks.
- Ignoring the sign convention, so refunds increase spend in the category summary.
Quick tips for the room
- Key everything on the external transaction reference from the start.
- Make ingest() idempotent before adding a single feature on top of it.
- Recompute aggregates from records; do not nudge counters.
- Fix a sign convention for debits and credits and write it in the README.
How to prepare
Write an ingestion method that is safe to call twice with the same payload, then extend it to handle a status change on an existing reference, then add aggregates that you recompute rather than nudge. Once those three behave, the categorisation rules are a small addition — and that ordering is also the order in which you should build during the round.
The repositories below train the pipeline: the webhook problem is the deduplication and ordering core, the duplicate-side-effects problem (free) is redelivery made concrete, the connector reconciliation problem is agreeing with an external system’s records, the SQL window problem is the aggregation bug that hides inside per-account history, and the loyalty problem covers the goals-and-rewards layer.
Practice problems in the Jupiter-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
The ingestion core: duplicate and out-of-order account events that must produce one correct state.
Open the challenge →Duplicate Effects After a Restart
What a redelivered feed does to a side effect, and how to make the effect happen exactly once. Free to try.
Open the challenge →Connector Record Reconciliation
Agreeing with someone else’s system of record: matching, drift detection, and safe resync.
Open the challenge →SQL Window Partition Bug
The aggregation bug that leaks across accounts when the window partition is wrong. Free to try.
Open the challenge →Loyalty Points & Tier Management
The rewards and goals layer: expiry ordering, redemption rules, and idempotent earn events.
Open the challenge →FAQ
Are these actual Jupiter interview questions?
No. Every problem is a Gronex original in the style of neobanking rounds — the kind of problem asked in rounds like Jupiter’s. Gronex is not affiliated with Jupiter.
Why is ingestion weighted so heavily?
Because a neobank’s correctness is inherited from a feed it does not control. If the pipeline double-counts or misses a correction, every downstream number the user sees is wrong, so reviewers test redelivery and pending-to-settled updates first.
Should I build a real queue consumer?
No. A method that accepts a batch of events, called twice with the same batch in a test, demonstrates everything the round cares about.
What if the statement is about savings goals instead?
The core does not change: contributions arrive as events, must be idempotent, and progress must be derivable. Add the withdrawal and target rules and the round is the same exercise in different clothing.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Jupiter. 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 Jupiter.