Navi-Style Machine Coding Round: Format, Tips & Practice Problems
Digital-lending and insurance companies interview for a specific kind of engineer: one who treats correctness in regulated domains as the job, not a nice-to-have. Machine coding rounds in the style of Navi and similar fintech lenders reflect that — banking transfers, loan and claim workflows, and strict validation, usually under a famously tight time box.
These rounds are commonly reported as shorter and more pace-sensitive than the classic e-commerce format — sometimes 60–90 minutes — which changes the strategy: scope ruthlessly, nail the invariants, and keep the design conversation in your back pocket. This page covers the format, the grading lens, and Gronex problems in the same style.
What a Navi-style machine coding round looks like
The typical statement is a banking or insurance slice: an account service with deposits, withdrawals, and transfers; a loan or claim workflow with eligibility rules and approval limits; an EMI or interest calculator with rule tiers. Requirements arrive as hard rules — a withdrawal cannot exceed the balance, a claim cannot pay out more than remaining coverage, an approver cannot sign off beyond their limit.
Transfers are the classic core. A correct solution debits and credits atomically — both legs or neither — and can explain what happens when two transfers touch the same accounts in opposite directions. Even without writing threads, you are expected to name the deadlock and the fix (a stable lock ordering). Workflow problems swap concurrency for authorization: who may act on this claim, at this state, up to what amount — enforced in the domain layer, not assumed from the caller.
Because the window is tight, evaluators watch prioritisation explicitly. Candidates who implement account creation UIs or CSV importers before the transfer invariant tend to run out of time; candidates who stub everything but the money path tend to pass. The follow-up discussion then extends the domain: add a daily withdrawal limit, add a second approver above a threshold — testing whether your rules were data, or code.
How you’re evaluated
Atomic money movement
Transfers are all-or-nothing, balances never go negative, and failure leaves no half-applied state or phantom history.
Rule and limit enforcement
Eligibility, coverage, and approval limits enforced centrally in the domain layer — with clear, specific errors when a rule blocks an action.
Authorization as logic
Ownership and role checks are part of the model: a customer sees only their accounts, an adjuster approves only within their limit.
Prioritisation under a tight clock
The core invariant works and is demoed; the periphery is honestly stubbed. Time discipline is graded, not just observed.
Common mistakes that fail this round
- Building account CRUD and input parsing first, leaving the transfer invariant for the final 20 minutes.
- Debiting one account and crediting the other in two independent steps with no failure story between them.
- Scattering limit checks across call sites so the follow-up ("add a daily cap") requires touching everything.
- Ignoring authorization because "it’s just an interview" — in lending-style rounds it is usually an explicit requirement.
- Using floats for interest and EMI math, then debugging rounding drift on stage.
Quick tips for the room
- Implement the transfer invariant first; demo it before touching anything else.
- Centralise every limit and rule check into one policy point per entity.
- Return specific errors — "insufficient balance" and "over approval limit" are different failures.
- When time runs short, cut features, never invariants.
How to prepare
Drill the transfer kata until it is automatic: atomic two-account mutation, balance invariants, deterministic failure behaviour, and the lock-ordering answer for the deadlock follow-up. Then practise one workflow problem — claims or approvals — focusing on encoding rules as data and enforcing them in one place.
The repositories below map directly: the bank-transfer problem is the round’s centrepiece including the deadlock dimension; insurance claim adjudication and expense approvals cover the regulated-workflow variant; and the two API-contract problems drill validation and authorization — the request-level rules a lending backend lives by. One is free, so you can start without an account.
Practice problems in the Navi-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.
Bank Transfer & Deadlock Prevention
The centrepiece: deadlock-free, atomic money transfers with ordered per-account locking.
Open the challenge →Insurance Claim Adjudication
Coverage checks, deductibles, adjuster approval limits, and one-time coverage decrement — the claims workflow round.
Open the challenge →Expense Approval & Reimbursement
Threshold-routed sequential approvals with atomic budget decrement — approval-workflow mechanics under invariants.
Open the challenge →API Debugging: Authorization Leak
Fix an IDOR: enforce ownership and role rules so no user can read another’s accounts or transactions.
Open the challenge →API Debugging: Validation & Error Envelope
Make a broken API honour its contract: 400s with a standard error envelope instead of 200s with garbage. Free to try.
Open the challenge →FAQ
Are these real Navi interview questions?
No. They are Gronex originals in the style of banking and insurance machine coding rounds — the kind of problem asked in rounds like Navi’s. Gronex is not affiliated with Navi and never republishes company questions.
How long is a Navi-style round?
Reports vary, but this round style is frequently described as tighter than the classic 2-hour format — plan for 60–90 minutes of effective build time and practise scoping accordingly.
Will I be asked about concurrency?
Very likely at the discussion stage, even if the build is single-threaded: what happens when two transfers cross the same accounts in opposite directions is the standard follow-up. Know the lock-ordering answer and be able to implement it.
What if I have no fintech background?
The domain rules are always stated in the problem; nothing relies on insider knowledge. What is graded is whether you enforce stated rules exactly — which the repository problems above train directly, since their test suites encode the rules.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Navi. 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 Navi.